Einheit 3.6: Hybridverbindung: VPN, NAT und Cross-Connect

Einführung

Drei der anspruchsvollsten Netzwerk-Anforderungen von FinCorp betreffen das Überqueren einer Grenze: eine verschlüsselte Site-to-Site-Verbindung vom Unternehmens-Rechenzentrum in die Cloud während der Migration, eine Möglichkeit für private Cloud-Server, Patches abzurufen und SaaS-Endpunkte zu erreichen, ohne jemals eine öffentliche IP zu besitzen, sowie ein privater Pfad mit niedriger Latenz zwischen zwei eigenen VDCs von FinCorp. Die Plattform beantwortet jede Anforderung mit einem eigenen Produkt, und die Produkte überschneiden sich nicht: Ein VPN Gateway verschlüsselt den Verkehr über das öffentliche Internet, ein NAT Gateway ermöglicht privaten Servern nur ausgehenden Datenverkehr, und ein Private Cross-Connect verbindet VDCs über ein privates LAN. Diese Einheit legt fest, wann jedes Produkt zum Einsatz kommt und welche unverhandelbaren Einschränkungen gelten. Anschließend werden die beiden Komponenten aufgebaut, die die Migration tragen: ein VPN-Tunnel und ein NAT Gateway für privaten ausgehenden Datenverkehr.

1. Die drei Hybrid-Primitiven und wie man sie auswählt

Die Auswahl reduziert sich auf eine Frage pro Anforderung: Überqueren Sie das öffentliche Internet verschlüsselt, verlassen Sie ein privates Netzwerk ausgehend, oder verbinden Sie zwei private Netzwerke privat?

VPN Gateway stellt eine sichere, verschlüsselte Site-to-Site-Verbindung zwischen einem On-Premises-Netzwerk und Ihren VDC-privaten LANs über das Internet her, entweder über IPSec-Tunnels oder WireGuard-Peers. Es ist das Arbeitspferd für Migrationen: Es verbindet ein Unternehmens-Rechenzentrum oder eine Außenstelle mit Cloud-Ressourcen für die Dauer eines Cutover und darüber hinaus. Seine definierenden Einschränkungen sind fest. Die IPSec-Implementierung unterstützt ausschließlich IKEv2; IKEv1 wird nicht unterstützt, daher muss jeder Legacy-Peer, der für IKEv1 konfiguriert ist, neu konfiguriert werden. Die Authentifizierung für IPSec erfolgt über einen vorab geteilten Schlüssel (ein 32-stelliger PSK wird empfohlen). Hochverfügbarkeit ist eine Active-Passive-Option, die Sie mit dem Tarif koppeln: Wenn Sie sie aktivieren, läuft das Gateway im Active-Passive-Modus, sodass ein redundanter Tunnel bei einem Ausfall automatisch übernimmt, und dieses HA-Paar stellt eine einzelne öffentliche IP bereit, sodass der On-Premises-Peer immer eine Adresse anspricht. Tunnel- und Gateway-IP-Adressen sind ausschließlich IPv4, obwohl die über den Tunnel übertragenen Nutzlasten dual-stack IPv4 und IPv6 sein können. BGP wird nicht angeboten; die Routing-Konfiguration ist statisch und wird durch die Netzwerk-CIDRs definiert, die Sie auf jeder Seite des Tunnels auflisten. Die Durchsatzrate pro Tunnel beträgt bis zu 1 Gbps, und der Tarif setzt die Obergrenzen für LANs und Tunnels.

NAT Gateway ist der Ausgangspfad für private Workloads. Es ermöglicht VMs innerhalb eines VDC, das Internet zu erreichen, ohne eine öffentliche Netzwerkschnittstelle zu benötigen: Das Gateway führt Source NAT durch, sodass private VMs ausgehende Verbindungen initiieren und die Antworten empfangen können, während eingehende Verbindungen, die vom Internet initiiert werden, abgelehnt werden. Dies ist die ehrliche Form des Produkts und der häufigste Punkt der Verwirrung: NAT Gateway ist ausschließlich SNAT, ohne DNAT und daher ohne eingehende Portweiterleitung. Wenn Sie eingehenden Verkehr benötigen, ist das Aufgabe eines Load Balancers, nicht des NAT Gateways. Es erfordert eine reservierte öffentliche IPv4-Adresse (es kann mehrere tragen), unterstützt bis zu sechs private Netzwerke pro Gateway und ist hochverfügbar, ausgelegt über mehrere Verfügbarkeitszonen in einer Region. Seine dokumentierten Verwendungszwecke sind genau die Fälle des ausgehenden Zugriffs privater Server: Abrufen von Betriebssystem- und Software-Updates, Erreichen von NTP, Ermöglichen, dass der Backup Service private VMs erreicht, und Beschränken des ausgehenden Zugriffs auf bestimmte vertrauenswürdige Endpunkte.

Private Cross-Connect verbindet mehrere VDCs über ein privates LAN ohne öffentliche Exposition, für eine sichere Datenübertragung mit niedrigerer Latenz und besserer Leistung als das Routing zwischen ihnen über das öffentliche Internet. Seine Einschränkungen sind kategorisch: Die beteiligten VDCs müssen in der gleichen Region und unter dem gleichen Vertrag liegen; Cross-Region und Cross-Contract werden nicht unterstützt. Alle NICs auf allen verbundenen VDCs müssen denselben IP-Bereich teilen, eine Adresse darf nicht in mehr als einer Instanz verwendet werden, und jedes LAN kann nur einem Cross-Connect zugewiesen sein. Die Bandbreite ist vergleichbar mit einer normalen privaten NIC, und die Funktion selbst ist kostenlos. Ein LAN wird in einen Cross-Connect eingebunden, indem der Bezeichner der Verbindung auf der LAN-Ressource gesetzt wird, und ein Cross-Connect kann nur gelöscht werden, wenn er von allen LANs und VDCs getrennt wurde. Wenn zwei Standorte eine dedizierte, von einem Carrier bereitgestellte Leitung benötigen, anstatt einer VDC-zu-VDC-Verbindung innerhalb derselben Region, handelt es sich um einen separaten Cloud Connect dedizierte-Leitung-Service, der sich vom Private Cross-Connect unterscheidet; die Builds in dieser Einheit verwenden die VPN- und NAT-Primitiven.

Während eines Migrations-Cutover spielen diese drei komplementäre Rollen: Das VPN Gateway trägt die verschlüsselte Brücke zwischen On-Premises und Cloud, während Workloads migriert werden; das NAT Gateway ermöglicht es migrierten, aber noch nicht öffentlichen privaten Servern, das Internet für Agenten, Patches und Sicherungen zu erreichen; und ein Cross-Connect verbindet VDCs privat, die innerhalb der Region Daten austauschen müssen. Keines ersetzt das andere.

Durchführungsanleitung für die DCD-Implementierung

Sie erstellen die beiden Grundbausteine, die den Cutover von FinCorp tragen: ein IKEv2 IPSec VPN Gateway mit einem Tunnel zurück zum unternehmensinternen Rechenzentrum und ein NAT Gateway, das dem privaten Anwendungslan nur ausgehenden Datenverkehr (outbound-only egress) ermöglicht. Beide Komponenten verwenden das VDC mit drei LANs aus Einheit 3.1.

Bauziel: Bereitstellung eines VPN Gateway-Tunnels; Bereitstellung eines NAT Gateways für privaten ausgehenden Datenverkehr.

Voraussetzung: Öffentliche IPs zuerst reservieren

Beide Gateways verbrauchen eine reservierte öffentliche IPv4-Adresse, und die Adresse muss am selben Ort reserviert werden wie das Gateway, bevor Sie es erstellen. Verwenden Sie IP Management, um eine IPv4-Adresse für das VPN Gateway und eine für das NAT Gateway in der Region zu reservieren, in der sich das VDC befindet. Eine per DHCP zugewiesene Adresse funktioniert nicht; diese Gateways wählen ausschließlich aus reservierten Adressen.

Schritte - VPN Gateway und IPSec-Tunnel (im Data Center Designer):

1. Klicken Sie auf der Seite VPN Gateways auf Create VPN Gateway.
2. Setzen Sie in Properties einen Namen, den Location (entsprechend der reservierten IP und dem VDC) und wählen Sie die reservierte öffentliche IP Address aus dem Dropdown-Menü. (Die IP und das Rechenzentrum müssen sich am selben Ort befinden.)
3. Wählen Sie in Tier die Stufe, die zu Ihren LAN- und Tunnelanforderungen passt (Standard erlaubt bis zu 5 LANs und 10 Tunnels/Peers; Enhanced bis zu 10 LANs und 20; Premium bis zu 15 LANs und 30). Wählen Sie die High Availability-Variante der Stufe, um aktiv-passiv zu arbeiten: Redundante Tunnels übernehmen automatisch bei einem Ausfall und minimieren so die Ausfallzeit hinter der einzelnen Gateway-IP.
4. Wählen Sie in Protocol IPSec. Die IKE Version ist standardmäßig IKEv2 (es gibt keine Option zur Auswahl von IKEv1; dies ist die einzige unterstützte IKE-Version).
5. Fügen Sie in LAN Connections das private LAN hinzu, das das Gateway nutzen soll. Wählen Sie eine private IP für das Gateway aus dem CIDR des LANs; der empfohlene Bereich ist .2 bis .9, und die Adresse darf im VDC noch nicht verwendet werden. (Hinweis: Ein VPN Gateway kann nicht an ein direkt von Managed Kubernetes verwaltetes LAN angeschlossen werden; fügen Sie ein zusätzliches Node-Pool-LAN hinzu, wenn dies Ihr Ziel ist.)
6. Klicken Sie auf Save. Der STATE des Gateways zeigt PROVISIONING, dann AVAILABLE. Sie können mit der Erstellung des Tunnels beginnen, während er noch provisioniert wird.
7. Klicken Sie auf der Seite VPN Gateways für dieses Gateway auf Create Tunnels. Geben Sie einen Tunnel-Name, den Remote Host (die öffentliche IPv4 oder FQDN des On-Premises-Peers) und die PSK unter Authentication (Methode PSK; verwenden Sie einen starken 32-Zeichen-Schlüssel) ein.
8. Setzen Sie die Initial Exchange (IKE_SA_INIT)-Phase: Wählen Sie eine Diffie-Hellman-Gruppe, einen Encryption Algorithm und einen Integrity Algorithm aus den angebotenen Listen (zum Beispiel DH group 16-MODP4096, AES256, SHA256), mit einer IKE-Lebensdauer zwischen 3600 und 86400 Sekunden.
9. Setzen Sie die Child SA (ESP)-Phase: Wählen Sie die entsprechende Diffie-Hellman-Gruppe, den Encryption Algorithm und den Integrity Algorithm, mit einer ESP-Lebensdauer zwischen 600 und 14400 Sekunden.
10. Definieren Sie die gerouteten Netzwerke: Cloud Network CIDRs (die Subnets auf der IONOS CLOUD-Seite, die über den Tunnel erlaubt sind) und Peer Network CIDRs (die On-Premises-Subnets). Diese statischen CIDR-Listen sind das Routing; es gibt kein BGP. Speichern Sie den Tunnel, konfigurieren Sie dann das On-Premises-Gerät mit identischen Parametern und stellen Sie sicher, dass der Tunnel einen aktiven Zustand erreicht.

Schritte - NAT Gateway für privaten ausgehenden Datenverkehr (im Data Center Designer):

1. Öffnen Sie das VDC und bestätigen Sie, dass ein private LAN mit mindestens einer VM existiert (das private Anwendungslan aus Einheit 3.1).
2. Fügen Sie ein NAT Gateway zum Workspace hinzu und verbinden Sie dessen Schnittstelle (Quellnetzwerk) mit diesem privaten LAN.
3. Wählen Sie das NAT Gateway aus und öffnen Sie seine Properties in Inspector > Settings. Setzen Sie einen Namen und fügen Sie eine öffentliche IP-Adresse aus den reservierten Adressen hinzu (eine reicht aus; mehrere können hinzugefügt werden).
4. Erstellen Sie eine NAT rule. Setzen Sie einen Namen und ein Protocol (TCP, UDP, ICMP oder ANY). Wählen Sie für Source > Public IP eine der öffentlichen IPs des Gateways (dies maskiert die ausgehende Quelladresse). Geben Sie für Source > Subnet die private VM oder das Subnetz in CIDR-Notation ein (zum Beispiel 10.10.10.0/24). Beschränken Sie optional Target > Subnet auf bestimmte externe Ziele, um ausgehenden Datenverkehr nur zu vertrauenswürdigen Endpunkten zu erlauben.
5. Setzen Sie den Standard-Route des LANs auf das Gateway. Auf den privaten VMs muss die Routing-Tabelle den internetgebundenen Datenverkehr zum NAT Gateway senden: Zeigen Sie die Standard-Route (0.0.0.0/0) darauf, oder fügen Sie eine dedizierte Route pro externem Ziel hinzu, wenn eine Standard-Route nicht akzeptabel ist. Ohne diese Routing-Änderung existiert das Gateway, aber kein Datenverkehr nutzt es.
6. Wenn diese privaten VMs DNS-Auflösung benötigen, während sie die NAT-Standard-Route verwenden, stellen Sie sicher, dass eine SNAT-Regel UDP abdeckt, andernfalls schlägt die Standard-DNS-Auflösung fehl.

Häufige Fehler:

• Reservieren Sie die statische öffentliche IP vor der Erstellung des Gateways; beide Gateways wählen aus reservierten Adressen, und eine DHCP-Adresse kann nicht verwendet werden.
• Suchen Sie nicht nach einer IKEv1-Option, es gibt keine; der Peer muss IKEv2 sprechen (oder WireGuard verwenden). Die Phase-1- und Phase-2-Parameter müssen auf beiden Seiten exakt übereinstimmen, sonst wird der Tunnel nicht aufgebaut.
• Das VPN HA-Paar teilt sich eine öffentliche IP; konfigurieren Sie den On-Premises-Peer, um diese einzelne Adresse anzuzielen, nicht zwei.
• NAT Gateway ist nur SNAT: Es gibt keinen eingehenden/DNAT-Pfad. Versuchen Sie nicht, einen Dienst darüber zu veröffentlichen; verwenden Sie einen Load Balancer für eingehenden Datenverkehr.
• Stellen Sie das NAT Gateway und seine Regeln vor der Erwartung von ausgegendem Datenverkehr bereit, ändern Sie dann die LAN-Standard-Route auf das Gateway, die Routing-Änderung ist der Schritt, den Menschen vergessen, und der Datenverkehr verlässt sich stillschweigend nicht, bis dies geschehen ist.
• Eine fehlende UDP-SNAT-Regel bricht DNS für VMs, deren Standard-Route das NAT Gateway ist.

Die Tunnelparameter tragen einen echten architektonischen Punkt: Die gerouteten Subnets sind statische CIDR-Listen auf jeder Seite, kein dynamisches Protokoll. Eine kurze API-Ansicht desselben Tunnels macht die unveränderliche Form explizit (die Phaseneinstellungen und die zwei CIDR-Arrays sind der gesamte Routing-Vertrag):

curl -X POST 'https://vpn.de-fra.ionos.com/ipsecgateways/{gatewayId}/tunnels' \
  -H 'Authorization: Bearer <token>' -H 'Content-Type: application/json' \
  --data '{ "properties": {
    "name": "to-fincorp-dc",
    "remoteHost": "vpn.fincorp.example",
    "auth": { "method": "PSK", "psk": { "key": "<32-char-psk>" } },
    "ike": { "diffieHellmanGroup": "16-MODP4096", "encryptionAlgorithm": "AES256", "integrityAlgorithm": "SHA256", "lifetime": 86400 },
    "esp": { "diffieHellmanGroup": "16-MODP4096", "encryptionAlgorithm": "AES256", "integrityAlgorithm": "SHA256", "lifetime": 3600 },
    "cloudNetworkCIDRs": [ "10.0.0.0/24" ],
    "peerNetworkCIDRs":  [ "198.51.100.0/24" ] } }'

Zusammenfassung

Die hybride Konnektivität in IONOS CLOUD besteht aus drei sich nicht überschneidenden Produkten. Das VPN Gateway überträgt verschlüsselten Standort-zu-Standort-Verkehr über das Internet mit IKEv2 (oder WireGuard), statischer CIDR-basierter Routing-Konfiguration und einer Active-Passive-HA-Option, die eine einzelne öffentliche IP darstellt. Das NAT Gateway ermöglicht privaten Workloads ausschließlich ausgehenden Internetzugang über SNAT, ohne einen eingehenden Pfad, und erfordert eine reservierte öffentliche IP sowie eine bewusste Änderung der Standard-Route im LAN. Private Cross-Connect verbindet VDCs privat, jedoch nur innerhalb derselben Region und desselben Vertrags. Die Auswahl unter diesen Produkten hängt davon ab, welche Grenze überschritten wird, und während einer Migration tragen die hier aufgebauten VPN- und NAT-Bausteine den Cutover-Verkehr.

Wichtige Punkte:

• VPN Gateway verwendet IKEv2/WireGuard ohne IKEv1; das Routing erfolgt über statische CIDR-Listen (kein BGP); HA ist Active-Passive auf einer gemeinsamen öffentlichen IP; bis zu 1 Gbps pro Tunnel.
• Die öffentliche IPv4-Adresse (am selben Standort wie das VDC) muss vor der Erstellung eines der Gateways reserviert werden; DHCP-Adressen können nicht verwendet werden.
• Das NAT Gateway unterstützt ausschließlich SNAT (kein eingehender Verkehr/DNAT), benötigt eine reservierte öffentliche IP, unterstützt bis zu sechs private LANs und leitet erst dann Verkehr weiter, wenn die Standard-Route des LAN auf es zeigt.
• Für VMs, deren Standard-Route das NAT Gateway ist, ist eine UDP-SNAT-Regel erforderlich, da sonst die DNS-Auflösung fehlschlägt.
• Private Cross-Connect ist nur innerhalb derselben Region und desselben Vertrags möglich, erfordert einen gemeinsamen IP-Bereich, erlaubt ein Cross-Connect pro LAN und ist kostenlos; es handelt sich nicht um eine verbandsgrenzen- oder vertragsgrenzenüberschreitende Verbindung.

Wichtige Begriffe:

• SNAT (Source NAT): Umstellung der Quelladresse ausgehender Pakete, damit private Hosts Internetverbindungen initiieren können; das NAT Gateway führt dies aus und lehnt ungefragten eingehenden (DNAT-)Verkehr ab.
• IKEv2: Das Schlüsselaustauschprotokoll, das das IPSec VPN Gateway verwendet; die einzige unterstützte IKE-Version, IKEv1 ist nicht verfügbar.
• Pre-shared key (PSK): Das geteilte Geheimnis, das einen IPSec-Tunnel authentifiziert; ein 32 Zeichen langer Schlüssel wird empfohlen und muss auf beiden Peers übereinstimmen.

Weitere Lektüre

• Einheit 3.1, VDC Topologie und Segmentierung, für die Grundlagen zu reservierten IP-Adressen und drei LANs, die in diesem Aufbau wiederverwendet werden.
• Einheit 3.3 und 3.4 für eingehende Lastverteilung, eine Funktion, die das NAT Gateway bewusst nicht bereitstellt.
• Einheit 6.3, Bereitstellung eines privaten Clusters, bei der NAT Gateway und Cross-Connect zu zwingenden Voraussetzungen für private Node-Pools werden.