Planungsaspekte für VPN-Gateways

Bevor Sie ein VPN-Gateway einrichten, sollten Sie die geltenden Planungsüberlegungen, Konfigurationsanforderungen und sonstigen Richtlinien prüfen.

Allgemeine Aspekte

Prüfen Sie die folgenden allgemeinen Überlegungen, bevor Sie ein VPN-Gateway erstellen:

  • Stellen Sie sicher, dass in dem Teilnetz genügend Platz für das Gateway ist. Um sicherzustellen, dass VPN-Management-und Failover-Funktionen ordnungsgemäß funktionieren, erstellen Sie das VPN-Gateway in einem Teilnetz ohne weitere VPC-Ressourcen. Dieses Verfahren gewährleistet, dass genügend private IP-Adressen für das Gateway verfügbar sind. Für ein VPN-Gateway sind vier private IP-Adressen erforderlich, um Hochverfügbarkeit und schrittweise Upgrades zu ermöglichen. Da maximal fünf private IP-Adressen in einem Subnetz reserviert sind, ist die Mindestgröße des Subnetzes, das für ein VPN-Gateway verwendet werden kann, /28 (16 IP-Adressen oder Netzmaske 255.255.255.240).
  • Standardmäßig ist PFS (Perfect Forward Secrecy) für IBM Cloud VPN für VPC deaktiviert. Einige Anbieter erfordern die PFS-Aktivierung für Phase 2. Prüfen Sie die Anweisungen Ihres Anbieters und verwenden Sie benutzerdefinierte Richtlinien, wenn Sie PFS benötigen.
  • Das IBM VPN-Gateway verwendet seine öffentliche IP-Adresse als lokale IKE-Identität und legt die öffentliche IP-Adresse des Peers standardmäßig als IKE-Peeridentität fest. Sie können die lokale Identität und die Peer-IKE-Identität angeben, um dieses Standardverhalten zu überschreiben, wenn Sie eine VPN-Verbindung erstellen. In Fällen, in denen sich das Peer-VPN-Gateway hinter einer NAT-Firewall befindet und die öffentliche IP-Adresse der Gegenstelle nicht mit der Schnittstelle des Peer-VPN-Gateways verbunden ist, können Sie die Konfiguration des Peer-VPN-Gateways anpassen. Diese Konfiguration stellt sicher, dass die öffentliche IP-Adresse der Gegenstelle als IKE-Identität verwendet wird. Sie können die Peer-IKE-Identität auch angeben, wenn Sie eine VPN-Verbindung erstellen, um die reale IKE-Identität Ihres Peer-VPN-Gateways zu verwenden.
  • Wenn sich Ihr Peer-VPN-Gateway hinter einem NAT-Gerät befindet und keine öffentliche IP-Adresse hat, können Sie der NAT-IP-Adresse einen FQDN zuordnen. Sie können dann diesen FQDN anstelle einer IP-Adresse verwenden, wenn Sie eine VPN-Verbindung herstellen. Auf diese Weise ist die Standard-Peer-IKE-Identität der FQDN. Sie können die IKE-Identität der Gegenstelle angeben, um diese Vorgabe beim Erstellen der VPN-Verbindung zu überschreiben, wenn die Vorgabe nicht mit der tatsächlichen IKE-Identität des VPN-Gateways der Gegenstelle übereinstimmt.
  • Beim Aufbau einer VPN-Verbindung können Sie einen Aufbaumodus (bidirektional oder nur Peer) wählen. Wenn Ihr Peer-VPN-Gateway beim Erstellen einer VPN-Verbindung keine öffentliche IP-Adresse hat, müssen Sie für das VPN-Gateway den Modus Nur Peer festlegen. In diesem Fall ist das Peer-VPN-Gateway dafür verantwortlich, die Verbindung wiederherzustellen, wenn eine Verbindung ausfällt.
  • Nachdem Sie eine VPN-Verbindung eingerichtet haben, können Sie den Adresstyp des Peer-Gateways nicht mehr von IP-Adresse auf FQDN oder von FQDN auf IP-Adresse ändern.
  • IBM Cloud VPC unterstützt die FQDN-Auflösung durch DNS Services. Wenn die VPC, in der sich das VPN-Gateway befindet, im zulässigen Netzwerk einer privaten DNS-Instanz liegt, dann sind DNS-Einträge, die in diesem privaten DNS hinzugefügt werden, im VPN-Gateway auflösbar.

Überlegungen zu richtlinienbasierten VPN-Gateways

Beachten Sie die folgenden Punkte, bevor Sie ein richtlinienbasiertes VPN-Gateway erstellen:

  • Das richtlinienbasierte VPN-Gateway wird in der Zone erstellt, die mit dem von Ihnen ausgewählten Subnetz verbunden ist. Das VPN-Gateway kann nur zu virtuellen Serverinstanzen in dieser Zone eine Verbindung herstellen. Dies hat zur Folge, dass Instanzen in anderen Zonen dieses VPN-Gateway nicht zur Kommunikation mit dem anderen Netzwerk nutzen können. Stellen Sie für die Fehlertoleranz in der Zone ein VPN-Gateway pro Zone bereit.
  • Bei policybasierten VPN-Gateways werden Routen nicht automatisch erkannt. Die Routing-Tabelle muss so konfiguriert sein, dass sie Routen vom VPN-Gateway akzeptiert, und weitergeleitete Routen sind auf die in der VPN-Richtlinie definierten CIDR-Präfixe beschränkt. Siehe Werbepfade.

Überlegungen zu routenbasierten VPN-Gateways

Prüfen Sie die folgenden Überlegungen, bevor Sie ein routenbasiertes VPN-Gateway erstellen:

Überlegungen zu VPN-Verbindungen auf Basis statischer Routen

Bevor Sie eine auf einer statischen Route basierende VPN-Verbindung erstellen, sollten Sie die folgenden Punkte beachten:

  • Wenn Sie eine Standardroute (0.0.0.0/0) in einer VPC-Routing-Tabelle festlegen möchten, damit der ausgehende Datenverkehr von Ihren VPC-Ressourcen durch ein VPN-Gateway geleitet wird, erstellen Sie Ihr VPN-Gateway in einem anderen Subnetz als dem, das mit der Routing-Tabelle verbunden ist. Andernfalls verursacht diese Standardroute einen Routing-Konflikt für das VPN-Gateway und kann die VPN-Verbindung zum Erliegen bringen.
  • IBM Cloud VPN for VPC unterstützt nur ein einzelnes routenbasiertes VPN pro Zone und VPC.

Überlegungen zu dynamischen routenbasierten VPN-Verbindungen

Prüfen Sie die folgenden Überlegungen, bevor Sie eine dynamische, routenbasierte VPN-Verbindung erstellen:

  • Um ein dynamisches Routing zwischen dem VPN-Gateway und den lokalen Geräten zu ermöglichen, müssen Sie ein Transit-Gateway erstellen und es mit dem VPN-Gateway verbinden. Bei dieser Einrichtung verwaltet und verteilt das Transit-Gateway automatisch den Datenverkehr zwischen Ihren Geräten. Siehe Überlegungen zur VPN-Gateway-Verbindung mit Transit Gateway. Beachten Sie, dass statisches Routing diese Art von Anhängen nicht unterstützt.
  • Sie können jederzeit dynamische VPN-Verbindungen erstellen, auch bevor das VPN-Gateway mit dem Transit-Gateway verbunden ist. Der Verkehr fließt jedoch nur, wenn das VPN-Gateway mit dem Transit-Gateway verbunden ist.
  • Ein lokaler und ein Peer-ASN-Wert sind für ein dynamisches routenbasiertes VPN erforderlich. Die lokale ASN identifiziert Ihr lokales Netzwerk für BGP-Peering, während die Peer-ASN das entfernte Peer-Netzwerk identifiziert, mit dem das VPN Routen austauscht. Wenn Sie den lokalen ASN-Wert nicht angeben, wird das VPN-Gateway mit der Standard-ASN 64520 erstellt.
  • Bestimmte ASN-Werte sind beim Erstellen eines VPN-Gateways eingeschränkt und können nicht als lokale oder Peer-ASNs verwendet werden. Dazu gehören 0, 13884, 36351, 64512, 64513, 65100, 65200–‍65234, 65402‍–‍65433, 65500 oder 4201065000‍–‍4201065999. Diese Werte sind entweder reserviert oder Teil privater ASN-Bereiche und können Routing-Konflikte verursachen.
  • Wenn Sie ein Transit-Gateway mit einem VPN verbinden, können Sie den ASN-Wert erst ändern, wenn Sie die Dienstverbindung aufheben.
  • Mehrere VPN-Gateways können sich mit demselben Transit-Gateway verbinden, aber jedes VPN-Gateway kann sich nur mit einem Transit-Gateway verbinden.
  • Wenn Sie für Ihre Transit-Gateway-Verbindung einen Nicht-RFC 1918-CIDR verwenden möchten, der nicht innerhalb der standardmäßigen privaten IP-Bereiche (10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16) liegt, müssen Sie eine Delegate-VPC-Route in die Egress-Routing-Tabelle Ihrer VPC hinzufügen. Diese Route muss auf den von Ihnen gewählten CIDR verweisen und mit dem VPN-Subnetz in derselben Zone verbunden sein. Siehe Überlegungen zur VPN-Gateway-Verbindung für Transit-Gateway.
  • Jedes IBM VPN unterstützt maximal 120 Routen für jeden VPN-Peer in einem dynamischen Routing-Setup. Wird diese Grenze überschritten, wird die BGP-Sitzung für diesen Peer automatisch beendet. Um die Sitzung wiederherzustellen, reduzieren Sie die Anzahl der Routen, die von Ihrem lokalen Peer-Netzwerk beworben werden, auf 120 oder weniger, und schalten Sie dann die Verbindung auf IBM Cloud um, um die BGP-Sitzung wiederherzustellen. Weitere Informationen finden Sie unter Wie viele Routen unterstützt VPN for VPC pro VPN-Peer für eine dynamische, routenbasierte Verbindung?

IBM Power Virtual Servers automatisieren Sie die Bereitstellung Ihres Arbeitsbereichs

Es ist ein Site-to-Site-VPN-Automatisierungsprojekt verfügbar, das ein Terraform-Modul zum Erstellen eines Site-to-Site-VPN-Gateways bereitstellt. Es ermöglicht auch eine sichere Verbindung über das Internet von Ihrem lokalen Netzwerk vor Ort zu privaten Ressourcen in einem Power Virtual Server Arbeitsbereich. Dieses Terraform Infrastructure as Code ( IaC ) Modul erstellt ein richtlinienbasiertes VPN-Gateway und eine Verbindung mit lokalen und Peer-Richtlinien. Standardmäßig werden die Arbeitsbereiche Transit Gateway und IBM Power Virtual Server erstellt, aber Sie können den Standard überschreiben, indem Sie vorhandene Arbeitsbereiche angeben.

Das Repository GitHub für dieses Automatisierungsprojekt befindet sich im Verzeichnis IBM / power-vpn-gateway- GitHub-Repository. In der README-Datei des Projekts wird ein VPN-Gateway erstellt und an einen neuen oder bestehenden Power Virtual Server Arbeitsbereich angehängt, um einen sicheren Zugang zur IBM Cloud Power-Infrastruktur zu ermöglichen.