Informationen zu Site-to-Site-VPN-Gateways
Mit dem Service IBM Cloud VPN for VPC können Sie Ihre Virtual Private Cloud (VPC) sicher mit einem anderen privaten Netz zu verbinden. Verwenden Sie ein routenbasiertes VPN oder ein richtlinienbasiertes VPN, um einen IPsec-Site-to-Site-Tunnel zwischen Ihrer VPC und Ihrem lokalen privaten Netzwerk oder einer anderen VPC einzurichten.
Funktionen von VPN for VPC
Der IBM Cloud-Site-to-Site- VPN for VPC-Dienst umfasst die folgenden Funktionen:
-
Authentifizierung - IBM Cloud VPN for VPC unterstützt einen vorab verteilten Schlüssel für die Peerauthentifizierung der Phase 1. Zu den unterstützten Authentifizierungsalgorithmen für beide Phasen gehören
SHA-256,SHA-384, undSHA-512. -
Hochverfügbarkeit - IBM Cloud VPN for VPC basiert auf zwei VPN-Einheiten, um Redundanz auf Appliance-Ebene zu ermöglichen. Ein richtlinienbasiertes VPN arbeitet im Aktiv-Standby-Modus mit einer einzigen VPN-Gateway-IP-Adresse, die von allen Mitgliedern gemeinsam genutzt wird, während ein routenbasiertes VPN sowohl den Aktiv-Backup- als auch den Aktiv-Aktiv-Redundanzmodus mit zwei VPN-Gateway-IP-Adressen bietet.
Im Active-Backup-Modus für ein routenbasiertes VPN werden zwei Tunnel zwischen dem Gateway IBM und dem Peer-VPN-Gateway eingerichtet. Das Gateway IBM verwendet jedoch immer den Tunnel mit der kleineren öffentlichen IP als primären Egress-Pfad. Der andere Tunnel mit der größeren IP dient als sekundärer Egress-Pfad. Solange beide Tunnel aktiv sind, läuft der Verkehr von der IBM VPC zum On-Premise-Netzwerk über den primären Egress-Pfad. Fällt der primäre Egress-Pfad aus, wechselt der Verkehr automatisch auf den sekundären Egress-Pfad. Diese Einstellung wird verwendet, wenn die Funktion "Verkehr verteilen" nicht aktiviert ist. Das lokale VPN-Gateway muss ebenfalls dieselbe Konfiguration verwenden, um denselben bevorzugten Pfad auszuwählen. Weitere Informationen
-
Erkennung inaktiver Peers – Konfigurierbarer Mechanismus zur Überprüfung der Verfügbarkeit eines IPsec-Peers.
-
Diffie-Hellman (DH) - Schlüsselaustauschprotokoll, das in Phase 1 verwendet wird, um einen gemeinsam von den VPN-Peers genutzten geheimen Schlüssel zu generieren. Optional können Benutzer PFS (Perfect Forward Secrecy) und eine DH-Gruppe für Phase 2 der IPsec-Vereinbarung aktivieren. IBM Cloud VPN für VPC unterstützt die DH-Gruppen
14-24und31. -
Verschlüsselung – IBM Cloud VPN für VPC unterstützt
AES-128,AES-192, und zurAES-256Datenverschlüsselung sowohl während der IKE-Phase 1 als auch während der IKE-Phase 2. -
Internet Key Exchange (IKE) - IKE ist Teil des IPsec-Protokolls, das zum Herstellen von VPN-Verbindungen verwendet wird. In der IKE Phase 1 verwenden VPN-Peers den Diffie-Hellman-Schlüsselaustausch, um einen sicheren, authentifizierten Kommunikationskanal zu erstellen. In IKE Phase 2 verwenden die Peers den sicheren Kanal aus Phase 1, um Parameter für IPsec-Tunnel zu vereinbaren. IBM Cloud VPN for VPC unterstützt sowohl IKEv1 (Hauptmodus) als auch IKEv2. Informationen zu den unterstützten Kombinationen finden Sie im Abschnitt Informationen zur Richtlinienvereinbarung.
-
IPsec - Protokollsuite, die eine sichere Kommunikation zwischen Geräten bereitstellt. IBM Cloud VPN Für VPC wird UDP verwendet, bei dem IPsec-ESP-Pakete (Encapsulating Security Protocol) im Tunnelmodus gekapselt werden, was Authentifizierung und vollständige Paketverschlüsselung bietet.
-
VPN-Gateway-Modi- IBM Cloud VPN für VPC bietet richtlinienbasierte und routenbasierte VPN-Gateway-Modi.
- Richtlinienbasiertes VPN- Bei einem richtlinienbasierten VPN wird der Verkehr, der den ausgehandelten CIDR-Bereichen auf der Grundlage definierter Sicherheitsrichtlinien entspricht, durch das VPN geleitet.
- Routenbasiertes VPN – Bei einem routenbasierten VPN werden virtuelle Tunnelschnittstellen auf der Grundlage von Einträgen in der Routing-Tabelle erstellt, und der gesamte Datenverkehr, der über benutzerdefinierte Routen
zu diesen logischen Schnittstellen geleitet wird, durchläuft das VPN. Beide VPN-Optionen stellen die gleichen Funktionen. Routenbasierte VPNs unterstützen außerdem statische und dynamische VPN-Verbindungen.
- Statische VPN-Verbindung- Bei der auf statischen Routen basierenden Verbindung müssen die Benutzer manuell Routen in der Routing-Tabelle definieren und konfigurieren. Wählen Sie zunächst beim Erstellen eines VPN-Gateways den Modus Static aus und legen Sie Routen mithilfe des VPN-Verbindungstyps an.
- Dynamische VPN-Verbindung- Bei der dynamischen, routenbasierten Verbindung werden die Routen zwischen den Netzwerken mit Hilfe von BGP automatisch ermittelt und verwaltet, im Gegensatz zum statischen Routing, das eine manuelle Konfiguration erfordert. Die dynamische Konfiguration bietet bessere Skalierbarkeit, Netzwerkverwaltung und hohe Verfügbarkeit. Wählen Sie bei der Erstellung eines VPN-Gateways als Verbindungstyp dynamisch aus, um loszulegen. Beachten Sie, dass Sie diese Verbindung zusammen mit einem Transit-Gateway verwenden müssen. Siehe Überlegungen zur Planung eines dynamischen routenbasierten VPN.
-
Perfect Forward Secrecy (PFS) - PFS stellt sicher, dass DH-generierte Schlüssel während der IPsec-Neuaushandlung nicht erneut verwendet werden. Wenn ein Schlüssel beeinträchtigt wird, kann während der Lebensdauer der geschützten Sicherheitszuordnung nur auf Daten bei der Übertragung zugegriffen werden.
Einführung in VPN-Gateways
Bevor Sie ein VPN erstellen, müssen Sie für Ihr VPN und andere Ressourcen zunächst eine VPC und mindestens ein Teilnetz erstellen.
Obwohl dies nicht erforderlich ist, wird empfohlen, ein Subnetz mit mindestens 16 IP-Adressen (Präfix /28 oder niedriger) für Ihr VPN-Gateway vorzusehen. Falls Sie sich für die Einrichtung zusätzlicher Ressourcen im VPN-Teilnetz
entscheiden, stellen Sie sicher, dass für Wiederherstellungs- und Wartungstasks immer mindestens 4 IP-Adressen zur Verwendung durch das VPN-Gateway verfügbar sind. Neben den 4 vom VPN-Gateway benötigten IPs werden bis zu 5 IPs in einem Teilnetz
für die interne Netzvernutzung reserviert. Achten Sie daher darauf, dass das Teilnetz groß genug ist.
Mit den folgenden generellen Schritten können Sie ein VPN-Gateway erstellen:
-
Stellen Sie sicher, dass die Netzwerk-ACLs so konfiguriert sind, dass der VPN-Datenverkehr zwischen Ihrem lokalen Netzwerk und dem Gateway IBM Cloud VPN fließen kann.
-
Stellen Sie sicher, dass Ihre Peereinheit die NAT-Traversierung unterstützt und dass diese Funktion auf der Peereinheit aktiviert ist. Weitere Informationen finden Sie unter Bekannte Probleme für VPN-Gateways.
-
Überprüfen Sie die Planungsüberlegungen und erstellen Sie Ihr VPN-Gateway.
-
Erstellen Sie VPN-Verbindungen, um eine Verbindung zwischen Ihrem VPN-Gateway und Ihrem lokalen Netzwerk herzustellen.
IBM Cloud VPN for VPC unterstützt nur ein einzelnes routenbasiertes VPN pro Zone und VPC.
-
Für eine VPN-Verbindung mit statischen Routen wählen Sie eine Routingtabelle für statisches Routing aus oder erstellen Sie eine solche und erstellen Sie anschließend Routen mithilfe des VPN-Verbindungstyps.
-
Um eine dynamische, routenbasierte VPN-Verbindung einzurichten, erstellen Sie ein Transit-Gateway und ordnen Sie es dem VPN-Gateway zu. Wenn Sie ein bestehendes Transit-Gateway haben, können Sie es auch an das VPN-Gateway anschließen. Siehe „ Verbindung hinzufügen “. Informationen zum Einrichten einer dynamischen, routenbasierten Verbindung mit einem Transit-Gateway finden Sie in den folgenden Anwendungsfällen:
-
Stellen Sie eine Verbindung zu einem lokalen Netz über einen VPN-Tunnel her.
-
Überprüfen Sie, ob Ihre VPN-Verbindung verfügbar ist, indem Sie einen Ping senden oder Datenverkehr über den Tunnel an Geräte im Peer-Netzwerk leiten.
Architektur
Dieses Diagramm veranschaulicht ein Beispiel für eine VPN-Konfiguration mit mehreren lokalen Netzen. Das VPN ist in einem Teilnetz innerhalb einer VPC eines Benutzers konfiguriert, kann aber von Instanzen auf allen Teilnetzen innerhalb der Zone gemeinsam genutzt werden. Die IKE- und IPsec-Richtlinien können auch von einer oder mehreren VPN-Verbindungen verwendet werden.
Informationen zu Richtlinienvereinbarungen
Für beide Phasen der IKE-Verhandlung müssen die IPsec-Peers Vorschläge von Sicherheitsparametern austauschen, für deren Unterstützung sie jeweils konfiguriert sind, und sich auf eine Gruppe von Konfigurationen einigen. Die angepassten IKE- und IPsec-Richtlinien ermöglichen IBM Cloud VPN VPC-Benutzern das Konfigurieren dieser Sicherheitsparameter, die während dieser Vereinbarung verwendet werden.
Die Verwendung von IKE- und IPsec-Richtlinien zum Konfigurieren einer VPN-Verbindung ist optional. Wenn keine Richtlinie ausgewählt ist, werden Standardvorschläge automatisch über einen Prozess ausgewählt, der als _Automatische Vereinbarung_bezeichnet wird.
Die wichtigsten Sicherheitsparameter, die in diesen Vereinbarungsprozess einbezogen werden, sind:
- IKE-Phase
- Verschlüsselungsalgorithmus
- Authentifizierungsalgorithmus
- Diffie-Hellman-Gruppe (Verschlüsselungsschlüsselaustauschprotokoll)
Da für die automatische Vereinbarung in IBM Cloud IKEv2 verwendet wird, muss die lokale Einheit ebenfalls IKEv2 verwenden. Verwenden Sie eine angepasste IKE-Richtlinie, wenn IKEv2 von Ihrer lokalen Einheit nicht unterstützt wird.
Automatische Vereinbarung für IKE (Phase 1)
Sie können die folgenden Optionen für die Verschlüsselung, Authentifizierung und Diffie-Hellman-Gruppe in jeder beliebigen Kombination verwenden:
| Verschlüsselung | Authentifizierung | DH-Gruppe | |
|---|---|---|---|
| 1 | aes128 | sha256 | 14–24, 31 |
| 2 | aes192 | sha384 | 14–24, 31 |
| 3 | aes256 | sha512 | 14–24, 31 |
Automatische Vereinbarung für IPsec (Phase 2)
Sie können die folgenden Verschlüsselungs-und Authentifizierungsoptionen in beliebiger Kombination verwenden oder die folgenden Kombinationsmodusverschlüsselungsoptionen verwenden, für die die Authentifizierung inaktiviert werden muss.
PFS ist für IBM Cloud VPN for VPC standardmäßig inaktiviert. Einige Anbieter erfordern die PFS-Aktivierung für Phase 2. Überprüfen Sie Ihre Anbieteranweisungen und verwenden Sie benutzerdefinierte Richtlinien, wenn PFS erforderlich ist.
| Verschlüsselung | Authentifizierung | DH-Gruppe | |
|---|---|---|---|
| 1 | aes128 | sha256 | Inaktiviert |
| 2 | aes192 | sha384 | Inaktiviert |
| 3 | aes256 | sha512 | Inaktiviert |
| Verschlüsselung | Authentifizierung | DH-Gruppe | |
|---|---|---|---|
| 1 | aes128gcm16 | Inaktiviert | Inaktiviert |
| 2 | aes192gcm16 | Inaktiviert | Inaktiviert |
| 3 | aes256gcm16 | Inaktiviert | Inaktiviert |
VPN for VPC-Anwendungsfälle
Anwendungsfall 1: VPN-Verbindung zu einem einzelnen Remote-Peer-Gerät desselben Typs, das einem oder mehreren Peer-Netzwerken zugeordnet ist
Sowohl routenbasierte als auch richtlinienbasierte VPNs ermöglichen es Benutzern, eine Verbindung zu einem einzelnen fernen Peergerät herzustellen, das mindestens einem Netz zugeordnet ist.
Dieser Anwendungsfall gilt nicht für Verbindungen zwischen einem richtlinienbasierten VPN und einem routenbasierten VPN. Weitere Informationen finden Sie unter Bekannte Probleme für VPN-Gateways.
Anwendungsfall 2: VPN-Verbindung zu mehreren fernen Peergeräten
Sowohl richtlinienbasierte als auch routenbasierte VPNs ermöglichen es Benutzern, über mehrere VPN-Verbindungen eine Verbindung zu mehreren Remote-Peer-Geräten herzustellen, die verschiedenen VPCs oder Umgebungen zugeordnet sind.
Anwendungsfall 3: Erweiterte VPN-Konfiguration mit einem FQDN
Der folgende Anwendungsfall zeigt einen Kunden, der über eine VPC in IBM Cloud verfügt und seine lokale Site mit einem einzelnen VPN-Gateway verbinden möchte. Das VPN-Gateway des Standorts befindet sich hinter einem NAT-Gerät und hat keine öffentliche IP-Adresse. In diesem Fall können Sie einen FQDN (vollqualifizierter Domänenname) mit der durch NAT geschützten IP-Adresse verknüpfen. Sie können dann diesen FQDN anstelle einer IP-Adresse verwenden, wenn Sie eine VPN-Verbindung herstellen. Die lokale IKE-Identität des lokalen VPN-Gateways ist die private IP-Adresse, die es besitzt. Ein vollständig qualifizierter Domänenname ist der öffentlichen IP-Adresse der NAT-Einheit zugeordnet.
Anwendungsfall 4: Verteilung des Datenverkehrs für ein routenbasiertes VPN
Ein routenbasiertes VPN verfügt über 2 öffentliche IPs. Sie können eine Verbindung zu einer oder beiden IPs herstellen, um Redundanz zu gewährleisten. Wenn Sie eine Verbindung zu einer öffentlichen IP herstellen möchten, können Sie eine der beiden wählen. Wenn Sie jedoch eine Verbindung zu beiden öffentlichen IPs herstellen möchten, haben Sie folgende Möglichkeiten:
Active-Backup-Modus für eine routenbasierte VPN-Verbindung
In diesem Modus wird immer nur ein Tunnel verwendet, um den VPN-Verkehr über den Tunnel zu leiten.
Das VPN verwendet immer den Tunnel mit der kleineren öffentlichen IP als primären Egress-Pfad. Wenn der primäre Egress-Pfad deaktiviert ist, fließt der Verkehr über den sekundären Pfad. Der Grund für die Verwendung nur eines Tunnels zur Weiterleitung des Verkehrs ist die Vermeidung des Problems der asymmetrischen Weiterleitung.
Wenn beispielsweise sowohl tunnel 1 als auch tunnel 2 in einer auf statischen Routen basierenden VPN-Verbindung aktiv sind und Sie eine Route mit dem Ziel 10.1.0.0/24 und der VPN-Verbindung als nächstem
Hop erstellen, wird die private IP 10.254.0.2 der VPN-Appliance zur Routenerstellung zurückgegeben. In diesem Modus ist der Verteilungsverkehr nicht aktiviert. Das folgende Diagramm zeigt die Standardkonfiguration
für eine auf einer statischen Route basierende Verbindung.
Die Protokollstatusfilterung auf einer virtuellen Netzwerkschnittstelle bietet Optionen zur Lösung des asymmetrischen Routingproblems. Weitere Informationen finden Sie unter Filtermodus für den Protokollstatus.
Das Verhalten des Active-Backup-Modus für eine dynamische, routenbasierte VPN-Verbindung ist ähnlich wie bei einer statischen Verbindung. Sie müssen jedoch keine Routen erstellen, da diese automatisch vom Transit-Gateway ermittelt werden.
In diesem Fall wird immer nur ein Tunnel verwendet, um den VPN-Verkehr über den Tunnel zu leiten. Das VPN verwendet immer den Tunnel mit der kleineren öffentlichen IP als primären Egress-Pfad. Wenn der primäre Egress-Pfad deaktiviert ist,
fließt der Verkehr über den sekundären Pfad. Das Subnetz, in dem sich die virtuelle Serverinstanz 10.255.0.0/24 befindet, muss sich vom Subnetz des VPN-Gateways 10.254.0.0/24 unterscheiden, damit das Transit-Gateway
den Datenverkehr zwischen ihnen weiterleiten kann. Das folgende Diagramm zeigt die Standardkonfiguration für eine dynamische routenbasierte Verbindung.
Aktiv-Aktiv-Modus für routenbasierte VPN-Verbindung
In diesem Modus wird der ausgehende Verkehr dynamisch zu den 2 Tunneln geleitet.
Wenn beispielsweise sowohl tunnel 1 als auch tunnel 2 aktiv sind und Sie eine Route mit dem Ziel 10.1.0.0/24 und einer VPN-Verbindung als nächstem Hop erstellen, werden die privaten IP-Adressen 10.254.0.2 und 10.254.0.3 zurückgegeben und der VPC-Netzwerkdienst erstellt 2 Routen. Da diese Routen die gleiche Priorität haben, fließt der Verkehr dynamisch zu tunnel 1 und tunnel 2, wenn der nächste Hop
einer VPC-Route die VPN-Verbindung ist. Um diesen aktiv-aktiven Redundanzmodus zu erreichen, müssen Sie beim Erstellen oder Hinzufügen von Verbindungen zu einem VPN-Gateway das Kontrollkästchen Verkehr verteilen aktivieren. Das folgende Diagramm zeigt diese Konfiguration für eine auf einer statischen Route basierende Verbindung.
Um diese Funktion zu nutzen und eine höhere Netzwerkleistung zu erzielen, muss das lokale Gerät asymmetrisches Routing unterstützen. Beachten Sie auch, dass nicht alle VPN-Gateways vor Ort diesen Anwendungsfall unterstützen. Wenn z. B. der VPN-Verkehr aus unterschiedlichen Tunneln kommt und wieder zurückgeht, kann der Verkehr durch VPN-Geräte oder Firewalls vor Ort blockiert werden.
Das Verhalten des Aktiv-Aktiv-Modus bei einer dynamischen routenbasierten VPN-Verbindung ist ähnlich wie bei einer statischen routenbasierten Verbindung. Wenn Sie beim Hinzufügen von Verbindungen zu einem VPN-Gateway das Kontrollkästchen Verkehr verteilen aktivieren, fließt der Verkehr durch beide Tunnel gleichzeitig. Das Transit-Gateway ist für die Erkennung, das Lernen und die Verwaltung von Routen zuständig. Das folgende Diagramm zeigt die Standardkonfiguration für eine dynamische routenbasierte Verbindung.
Anwendungsfall 5: Dynamische routenbasierte VPN-Verbindung für eine Zone mit Transit Gateway
Mit dem dynamischen routenbasierten VPN können Sie eine Einzelzonen-VPN-Verbindung zwischen Ihrem VPC und Ihrem privaten Netzwerk vor Ort herstellen, indem Sie Transit Gateway verwenden. Diese Einrichtung ermöglicht eine automatische Routenermittlung, einen bidirektionalen Verkehrsfluss und einen dynamischen Routenaustausch zwischen den Geräten, was die Netzwerkverwaltung vereinfacht und die manuelle Konfiguration reduziert.
Anwendungsfall 6: Zonenübergreifende dynamische VPN-Verbindung auf Basis von Routen mit Transit Gateway
Um eine vollständige regionale Hochverfügbarkeit für VPN-Konnektivität zu erreichen, können Sie in jeder Verfügbarkeitszone ein VPN-Gateway bereitstellen und separate VPN-Verbindungen vom Transit-Gateway zu jedem VPN-Gateway herstellen. Dadurch wird eine zonenübergreifende Redundanz gewährleistet, die einen kontinuierlichen Paketfluss und einen dynamischen Routenaustausch ermöglicht, selbst wenn eine Zone ausfällt.
Anwendungsfall 7: VPN-Verbindung als Backup der Direktverbindung
Sie können sowohl Direkt- als auch VPN-Verbindungen an ein Transit-Gateway anschließen, um hohe Verfügbarkeit und flexibles Routing zu ermöglichen. Wenn Sie dem VPN-Gateway Routen hinzufügen, bevorzugt der Verkehr unter normalen Bedingungen den direkten Link-Pfad gegenüber dem VPN-Pfad. Fällt die Direktverbindung aus, wird der Datenverkehr automatisch auf die VPN-Verbindung umgeschaltet, wodurch die ununterbrochene Konnektivität zwischen den Netzwerken aufrechterhalten werden kann. Sie müssen die BGP-Routing-Präferenzen auf Ihrer Seite so konfigurieren, dass die direkte Verbindung gegenüber dem VPN bevorzugt wird. Sie können diese Routing-Präferenz konfigurieren, indem Sie einen kürzeren AS-Pfad für die direkte Verbindung und einen längeren AS-Pfad für das VPN festlegen, so dass die direkte Verbindung bevorzugt wird.
Anwendungsfall 8: Hochverfügbares dynamisches routenbasiertes VPN mit zonaler Affinität
Sie können eine hohe Verfügbarkeit für ein dynamisches, routenbasiertes VPN-Setup erreichen, indem Sie IBM Cloud VPN Gateways in mehreren Zonen einsetzen. Diese Konfiguration führt eine zonale Affinität ein, d. h., wenn sich eine Power Virtual Server, Transit Gateway und eine VPN-Verbindung in derselben Zone befinden, wird der Datenverkehr bevorzugt durch diese Zone geleitet. Der Verkehr wird nur dann in eine andere Zone verlagert, wenn das VPN-Gateway in der aktuellen Zone nicht mehr verfügbar ist.
Der VPN-Verkehr wird mit IPsec gesichert, und die automatische Routenfindung wird mit BGP aktiviert. Ihr lokales Netzwerk kann sich über das Transit-Gateway mit Power Virtual Servers verbinden. Wie in der Abbildung dargestellt, werden zwei VPN-Tunnel aufgebaut, wenn Sie eine dynamische, routenbasierte VPN-Verbindung erstellen. Wenn Sie die Option Verkehr verteilen aktivieren, fließt der Verkehr dynamisch durch beide Tunnel, was einen höheren Durchsatz ermöglicht.
Führen Sie die folgenden Schritte aus, um diese Konfiguration einzurichten:
- Stellen Sie ein VPN-Gateway in Zone 1 und Zone 3 bereit. Siehe Erstellen eines VPN-Gateways.
- Fügen Sie dem bereitgestellten Gateway eine VPN-Verbindung hinzu, um eine Verbindung zu Ihrem lokalen Netzwerk herzustellen. Siehe Hinzufügen von Verbindungen zu einem VPN-Gateway.
- Stellen Sie eine Verbindung zwischen IBM Cloud VPN und Transit Gateway her. Siehe Erstellen eines Transit-Gateways.