Einheit 3.6: Hybrid-Konnektivität: VPN, NAT und Cross-Connect

Einführung

Drei der härtesten Netzwerkanforderungen von FinCorp sind mit dem Überschreiten einer Grenze verbunden: eine verschlüsselte Site-to-Site-Verbindung vom firmeneigenen Rechenzentrum in die Cloud während der Migration, eine Möglichkeit für Private Cloud-Server, Patches zu beziehen und SaaS-Endpunkte zu erreichen, ohne jemals eine öffentliche IP zu besitzen, und ein privater Pfad mit niedriger Latenz zwischen zwei von FinCorps eigenen virtuellen Rechenzentren. Die Plattform beantwortet jede dieser Anforderungen mit einem bestimmten Produkt, und die Produkte überschneiden sich nicht: ein VPN Gateway verschlüsselt den Datenverkehr über das öffentliche Internet, ein NAT-Gateway ermöglicht privaten Servern nur ausgehenden Datenverkehr, und ein privater Cross-Connect verbindet virtuelle Rechenzentren über ein privates LAN. Diese Einheit legt fest, wann jedes Produkt anwendbar ist und welche nicht verhandelbaren Einschränkungen es gibt, und baut dann die beiden auf, die die Migration tragen: ein VPN-Tunnel und ein NAT-Gateway für privaten 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 in Richtung Außen oder verbinden Sie zwei private Netzwerke privat?

VPN Gateway etabliert eine sichere, verschlüsselte Site-to-Site-Verbindung zwischen einem lokalen Netzwerk und Ihren VDC-privaten LANs über das Internet, entweder mit IPSec-Tunneln oder WireGuard-Peers. Es ist das Migration-Workhorse: Es verbindet ein Unternehmens-Rechenzentrum oder eine Filiale mit Cloud-Ressourcen für die Dauer eines Cutover und darüber hinaus. Seine definierenden Einschränkungen sind fest. Die IPSec-Implementierung ist nur IKEv2; IKEv1 wird nicht unterstützt, sodass jeder Legacy-Peer, der für IKEv1 konfiguriert ist, neu konfiguriert werden muss. Die Authentifizierung für IPSec erfolgt durch einen gemeinsam genutzten Schlüssel (ein 32-zeichenlanger PSK wird empfohlen). Hochverfügbarkeit ist eine aktive-passive Option, die Sie mit der Ebene kombinieren: Wenn Sie sie aktivieren, läuft das Gateway im aktiven-passiven Modus, sodass ein redundanter Tunnel automatisch bei einem Ausfall übernimmt, und dieses HA-Paar präsentiert eine einzelne öffentliche IP, sodass der lokale Peer immer auf eine Adresse abzielt. Tunnel- und Gateway-IP-Adressen sind nur IPv4, obwohl die über den Tunnel transportierte Nutzlast eine dual-stack-IPv4- und IPv6-Nutzlast sein kann. BGP wird nicht angeboten; die Routing-Definition ist statisch und wird durch die Netzwerk-CIDRs bestimmt, die Sie auf jeder Seite des Tunnels auflisten. Die Durchsatzrate pro Tunnel beträgt bis zu 1 Gbps, und die Ebene legt die Obergrenzen für LANs und Tunnel fest.

NAT-Gateway ist der Egress-Pfad für private Workloads. Es ermöglicht es virtuellen Maschinen innerhalb eines VDC, auf das Internet zuzugreifen, ohne dass eine öffentliche Netzwerkschnittstelle erforderlich ist: Das Gateway führt eine Quell-NAT durch, sodass private virtuelle Maschinen ausgehende Verbindungen initiieren und 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: Das NAT-Gateway ist nur SNAT, ohne DNAT und daher ohne eingehende Portweiterleitung. Wenn Sie eine eingehende Verbindung benötigen, ist das die Aufgabe eines Load Balancer und 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, da es über mehrere Verfügbarkeitszonen in einer Region ausgeführt wird. Seine dokumentierten Verwendungen sind genau die Fälle privater Server mit ausgehender Verbindung: Abrufen von OS- und Software-Updates, Erreichen von NTP, Ermöglichen des Zugriffs des Backup Service auf private virtuelle Maschinen und Einschränken des ausgehenden Zugriffs auf bestimmte vertrauenswürdige Endpunkte.

Private Cross-Connect verbindet mehrere VDCs über ein privates LAN ohne öffentliche Exposition, für einen sicheren Datenaustausch mit geringerer Latenz und besserer Leistung als das Routing zwischen ihnen über das öffentliche Internet. Seine Einschränkungen sind kategorisch: Die teilnehmenden VDCs müssen in der gleichen Region und unter dem gleichen Vertrag sein; Cross-Region und Cross-Vertrag werden nicht unterstützt. Alle Netzwerkkarten auf allen verbundenen VDCs müssen den gleichen IP-Bereich teilen, eine Adresse darf nicht in mehr als einer Instanz verwendet werden, und jedes LAN kann nur einem Cross-Connect angehören. Die Bandbreite ist vergleichbar mit einer normalen privaten Netzwerkkarte, und die Funktion selbst ist kostenlos. Ein LAN wird in einen Cross-Connect einbezogen, indem die Verbindungs-ID auf der LAN-Ressource festgelegt 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 in der gleichen Region, ist das ein separates Cloud-Connect-Dedicated-Line-Service, das sich von Private Cross-Connect unterscheidet; die Builds dieser Einheit verwenden die VPN- und NAT-Primitiven.

Während einer Migration können diese drei eine komplementäre Rolle spielen: Das VPN Gateway überbrückt die verschlüsselte Verbindung zwischen lokalen und Cloud-Ressourcen, während die Workloads migriert werden; das NAT-Gateway ermöglicht es migrierten, aber noch nicht öffentlichen, privaten Servern, auf das Internet zuzugreifen, um Agents, Patches und Backups zu erhalten; und ein Cross-Connect verbindet VDCs privat, die Daten innerhalb der Region austauschen müssen. Keines ersetzt das andere.

DCD Implementierung Schritt-für-Schritt

Sie werden die beiden Grundelemente erstellen, die den Cutover von FinCorp tragen: ein IKEv2-IPSec-VPN Gateway mit einem Tunnel zurück zum Firmen-Rechenzentrum und ein NAT-Gateway, das der privaten Anwendungs-LAN einen ausgehenden Egress ermöglicht. Beide verwenden das dreifache LAN-VDC aus Einheit 3.1.

Ziel: Bereitstellen eines VPN Gateway-Tunnels; Bereitstellen eines NAT-Gateways für privaten Egress.

Voraussetzung: Öffentliche IPs zuerst reservieren

Beide Gateways verbrauchen eine reservierte öffentliche IPv4-Adresse, und die Adresse muss in demselben Standort wie das Gateway reserviert werden, bevor es erstellt wird. Mithilfe von IP-Verwaltung reservieren Sie eine IPv4-Adresse für den VPN Gateway und eine für das NAT-Gateway, in der Region, in der das VDC existiert. Eine DHCP-zugewiesene Adresse funktioniert nicht; diese Gateways wählen nur aus reservierten Adressen aus.

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

1. Von der VPN-Gateways-Seite aus, klicken Sie auf VPN Gateway erstellen.
2. In Eigenschaften, setzen Sie einen Namen, den Standort (entsprechend der reservierten IP und dem VDC), und wählen Sie die reservierte öffentliche IP-Adresse aus dem Dropdown-Menü. (Die IP und das Rechenzentrum müssen sich im selben Standort befinden.)
3. In Stufe, wählen Sie die Stufe, die Ihren LAN- und Tunnelanforderungen entspricht (Standard erlaubt bis zu 5 LANs und 10 Tunnel/Peers; Erweitert bis zu 10 LANs und 20; Premium bis zu 15 LANs und 30). Wählen Sie die Hochverfügbarkeits-Variante der Stufe, um aktiv-passiv zu betreiben: redundante Tunnel übernehmen automatisch während eines Ausfalls, minimieren die Ausfallzeit, hinter dem einzelnen Gateway-IP.
4. In Protokoll, wählen Sie IPSec. Die IKE-Version ist IKEv2 standardmäßig (es gibt keine IKEv1-Option zum Auswählen; dies ist die einzige unterstützte IKE-Version).
5. In LAN-Verbindungen, fügen Sie die private LAN hinzu, die das Gateway verwenden wird. Wählen Sie eine private IP für das Gateway aus dem LAN-CIDR; der empfohlene Bereich ist .2 bis .9, und die Adresse darf nicht bereits im VDC verwendet werden. (Hinweis: Ein VPN Gateway kann nicht direkt an ein von Managed Kubernetes verwaltetes LAN angehängt werden; hängen Sie ein zusätzliches Node-Pool-LAN an, wenn das Ihr Ziel ist.)
6. Klicken Sie auf Speichern. Der Gateway-Zustand zeigt PROVISIONIERUNG an, dann VERFÜGBAR. Sie können mit der Erstellung des Tunnels beginnen, während er noch provisioniert wird.
7. Auf der VPN-Gateways-Seite, klicken Sie auf Tunnel erstellen für dieses Gateway. Geben Sie einen Tunnel-Namen, den Remote-Host (die öffentliche IPv4-Adresse oder den FQDN des lokalen Peers), und den PSK unter Authentifizierung (Methode PSK; verwenden Sie einen starken 32-zeichenlangen Schlüssel) ein.
8. Setzen Sie die Initialisierungsphase (IKE_SA_INIT): Wählen Sie eine Diffie-Hellman-Gruppe, einen Verschlüsselungsalgorithmus und einen Integritätsalgorithmus aus den angebotenen Listen (zum Beispiel DH-Gruppe 16-MODP4096, AES256, SHA256), mit einer IKE-Lifetime zwischen 3600 und 86400 Sekunden.
9. Setzen Sie die Child-Sicherheitsphase (ESP): Wählen Sie die entsprechende Diffie-Hellman-Gruppe, den Verschlüsselungsalgorithmus und den Integritätsalgorithmus, mit einer ESP-Lifetime zwischen 600 und 14400 Sekunden.
10. Definieren Sie die gerouteten Netzwerke: Cloud-Netzwerk-CIDRs (die IONOS-seitigen Subnetze, die über den Tunnel zugelassen sind) und Peer-Netzwerk-CIDRs (die lokalen Subnetze). Diese statischen CIDR-Listen sind die Routing-Informationen; es gibt kein BGP. Speichern Sie den Tunnel, dann konfigurieren Sie das lokale Gerät mit identischen Parametern und überprüfen Sie, ob der Tunnel einen aktiven Zustand erreicht.

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

1. Öffnen Sie das VDC und bestätigen Sie, dass ein privates LAN mit mindestens einem VM existiert (das private Anwendungs-LAN aus Einheit 3.1).
2. Fügen Sie ein NAT-Gateway zum Arbeitsbereich hinzu und verbinden Sie dessen Schnittstelle (Quellnetzwerk) mit diesem privaten LAN.
3. Wählen Sie das NAT-Gateway und öffnen Sie dessen Eigenschaften im Inspector > Einstellungen. Setzen Sie einen Namen und fügen Sie eine öffentliche IP-Adresse aus den reservierten Adressen hinzu (eine ist genug; mehrere können hinzugefügt werden).
4. Erstellen Sie eine NAT-Regel. Setzen Sie einen Namen und ein Protokoll (TCP, UDP, ICMP oder ANY). Für Quelle > Öffentliche IP wählen Sie eine der öffentlichen IPs des Gateways (dies maskiert die ausgehende Quelladresse). Für Quelle > Subnetz geben Sie das private VM oder Subnetz in CIDR-Notation ein (zum Beispiel 10.10.10.0/24). Optional können Sie Ziel > Subnetz auf bestimmte externe Ziele beschränken, um nur Egress zu vertrauenswürdigen Endpunkten zu ermöglichen.
5. Setzen Sie die LAN-Standardroute auf das Gateway. Auf den privaten VMs muss die Routing-Tabelle den Internet-verkehr auf das NAT-Gateway umleiten: zeigen Sie die Standardroute (0.0.0.0/0) auf es hin, oder fügen Sie eine dedizierte Route pro externem Ziel hinzu, wenn eine Standardroute nicht akzeptabel ist. Ohne diese Routing-Änderung existiert das Gateway, aber kein Verkehr verwendet es.
6. Wenn diese privaten VMs DNS-Auflösung benötigen, während sie die NAT-Standardroute verwenden, stellen Sie sicher, dass eine SNAT-Regel UDP abdeckt, sonst 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 nur aus reservierten Adressen aus, 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). Phase-1- und Phase-2-Parameter müssen auf beiden Seiten exakt übereinstimmen, oder der Tunnel wird nicht hergestellt.
• Das VPN-HA-Paar teilt eine öffentliche IP; konfigurieren Sie den lokalen Peer, um auf diese einzelne Adresse zu zielen, nicht auf zwei.
• Das NAT-Gateway ist SNAT-only: Es gibt keinen Eingangs-/DNAT-Pfad. Versuchen Sie nicht, einen Dienst über es zu veröffentlichen; verwenden Sie ein Load Balancer für Eingang.
• Stellen Sie das NAT-Gateway und dessen Regeln vor der Erwartung von Egress bereit, dann ändern Sie die LAN-Standardroute auf das Gateway; die Routing-Änderung ist der Schritt, den die Leute vergessen, und der Verkehr verlässt stillschweigend nie, bis er vorgenommen wird.
• Ein fehlendes UDP-SNAT führt zu einem Fehler bei der DNS-Auflösung für VMs, deren Standardroute das NAT-Gateway ist.

Die Tunnelparameter tragen einen echten architektonischen Punkt: Die gerouteten Subnetze sind statische CIDR-Listen auf jeder Seite, kein dynamisches Protokoll. Ein kurzer API-Überblick über den gleichen Tunnel macht die unveränderliche Form explizit (die Phaseneinstellungen und die beiden 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

Hybride Konnektivität bei IONOS besteht aus drei nicht überlappenden Produkten. Das VPN Gateway transportiert verschlüsselten Site-to-Site-Datenverkehr über das Internet mit IKEv2 (oder WireGuard), statischer CIDR-basierter Routing und einer aktiven-passiven Hochverfügbarkeits-Option, die eine einzelne öffentliche IP präsentiert. Das NAT-Gateway bietet privaten Workloads ausgehenden Internetzugang über SNAT, ohne eingehenden Pfad, und erfordert eine reservierte öffentliche IP und eine bewusste Änderung der LAN-Standardroute. Private Cross-Connect verbindet virtuelle Rechenzentren privat, aber nur innerhalb der gleichen Region und des gleichen Vertrags. Die Wahl zwischen ihnen hängt davon ab, welche Grenze Sie überqueren, und während einer Migration transportieren die VPN- und NAT-Primitiven, die hier erstellt werden, den Umstellungsdatenverkehr.

Wichtige Punkte:

• VPN Gateway ist IKEv2/WireGuard ohne IKEv1; die Routing-Liste ist statisch CIDR (kein BGP); die Hochverfügbarkeit ist aktiv-passiv auf einer gemeinsamen öffentlichen IP; bis zu 1 Gbps pro Tunnel.
• Reservieren Sie die öffentliche IPv4-Adresse (gleicher Standort wie das virtuelle Rechenzentrum) vor der Erstellung eines Gateways; DHCP-Adressen können nicht verwendet werden.
• Das NAT-Gateway ist SNAT-only (kein eingehender/DNAT-Verkehr), benötigt eine reservierte öffentliche IP, unterstützt bis zu sechs private LANs und leitet den Datenverkehr nur weiter, wenn die LAN-Standardroute auf es verweist.
• Für virtuelle Maschinen, deren Standardroute das NAT-Gateway ist, ist eine UDP-SNAT-Regel erforderlich, oder die DNS-Auflösung funktioniert nicht.
• Private Cross-Connect ist nur innerhalb der gleichen Region und des gleichen Vertrags möglich, erfordert einen gemeinsamen IP-Bereich, ermöglicht eine Cross-Connect-Verbindung pro LAN und ist kostenlos; es handelt sich nicht um eine cross-regionale oder cross-vertragliche Verbindung.

Wichtige Begriffe:

• SNAT (Quell-NAT): Die Quelladresse von ausgehenden Paketen wird so umgeschrieben, dass private Hosts Internetverbindungen initiieren können; das NAT-Gateway tut dies und lehnt unerwünschten eingehenden (DNAT)-Datenverkehr ab.
• IKEv2: Das Schlüsselaustauschprotokoll, das das IPSec-VPN Gateway verwendet; die einzige unterstützte IKE-Version, IKEv1 ist nicht verfügbar.
• Vorher gemeinsam genutzter Schlüssel (PSK): Der gemeinsam genutzte geheime Schlüssel, der einen IPSec-Tunnel authentifiziert; ein 32-zeichenlanger Schlüssel wird empfohlen und muss auf beiden Peers übereinstimmen.

Weiterführende Literatur

• Einheit 3.1, VDC-Topologie und Segmentierung, für die reservierten-IP und drei-LAN Grundlagen, die dieser Aufbau wiederverwendet.
• Einheit 3.3 und 3.4 für die Lastverteilung bei eingehenden Anfragen, die Funktion NAT Gateway, die absichtlich nicht bereitgestellt wird.
• Einheit 6.3, Bereitstellung eines privaten Cluster, wo NAT Gateway und Cross-Connect zu harten Voraussetzungen für private Node Pools werden.