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 statisches, routenbasiertes VPN oder ein richtlinienbasiertes VPN, um einen IPsec-Site-to-Site-Tunnel zwischen Ihrer VPC und Ihrem lokalen privaten Netz oder einer anderen VPC einzurichten.
Das routenbasierte VPN ist jetzt zusätzlich zum richtlinienbasierten VPN verfügbar. Wählen Sie als Erstes bei der Erstellung eines VPN-Gateways den Modus Routenbasiert aus und verwenden Sie bei der Erstellung von Routen den Verbindungstyp "VPN".
Funktionen von VPN for VPC
Der Service IBM Cloud VPN for VPC enthält die folgenden Funktionen:
MD-5 und SHA-1 Authentifizierungsalgorithmen, 2 und 5 DH-Gruppen und der 3-DES-Verschlüsselungsalgorithmus wurden am 20. September 2022 veraltet und werden von der Konsole nicht mehr unterstützt.
-
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 und SHA-512.
-
Hochverfügbarkeit - IBM Cloud VPN for VPC basiert auf zwei VPN-Einheiten, um Redundanz auf Appliance-Ebene zu ermöglichen. Ein richtlinienbasiertes VPN wird im Aktiv-Standby-Modus mit einer einzelnen IP des VPN-Gateways betrieben, die von den Mitgliedern gemeinsam genutzt wird, während ein routenbasiertes VPN Active-Active-Redundanz mit zwei VPN-Gateway-IPs bietet.
Ein statisches, routenbasiertes VPN wird im Redundanzmodus Aktiv/Aktiv bereitgestellt. Zwei VPN-Tunnel sind mit dem Peer-VPN-Gateway verbunden. Das IBM Gateway verwendet jedoch immer den Tunnel mit der kurzen öffentlichen IP als primären Egress-Pfad. Der Tunnel mit der langen öffentlichen IP ist der sekundäre Egress-Pfad. Der Datenverkehr von IBM VPC zum lokalen Netz verläuft über den primären Egress-Pfad, wenn beide Tunnel aktiv sind. Der Datenverkehr durchläuft den sekundären Egress-Pfad, wenn der primäre Egress-Pfad inaktiviert ist. Das lokale VPN-Gateway muss die Routenpriorität verwenden, damit derselbe bevorzugte Pfad ausgewählt wird. Weitere Informationen
-
Erkennung inaktiver Peers (Dead Peer Detection) - Konfigurierbarer Mechanismus, um die Verfügbarkeit eines IPsec-Peers zu erkennen.
-
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-24 und 31.
-
Verschlüsselung- IBM Cloud VPN für VPC unterstützt AES-128, AES-192 und AES-256 für die Datenverschlüsselung während IKE Phase 1 und 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 verwendet die UDP-Kapselung von IPsec Encapsulating Security Protocol (ESP)-Paketen im Tunnelmodus, der Authentifizierung und vollständige Paketverschlüsselung bietet.
-
Modi - IBM Cloud VPN for VPC bietet VPN-Modi, die auf statischen Routen bzw. auf Richtlinien basieren. Bei einem routenbasierten VPN wird der Datenverkehr, der mit den ausgehandelten CIDR-Bereichen übereinstimmt, über das VPN geleitet. Bei einem auf statischen Routen basierenden VPN werden virtuelle Tunnelschnittstellen erstellt; jeder Datenverkehr, der mit angepassten Routen zu diesen logischen Schnittstellen wird, passiert das VPN. Beide VPN-Optionen stellen die gleichen Funktionen.
-
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 Teilnetz mit mindestens 16 IPs (Präfix 28 oder niedriger) für Ihr VPN-Gateway zu verwenden. 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 für den VPN-Datenverkehr vorhanden sind.
-
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.
-
Lesen Sie die Planungshinweise und erstellen Sie Ihr VPN-Gateway.
-
Erstellen Sie eine VPN-Verbindung.
IBM Cloud VPN for VPC unterstützt nur ein einzelnes routenbasiertes VPN pro Zone und VPC.
-
Wählen Sie für statische routenbasierte VPNs die Option Routingtabelle für statisches Routing erstellen aus und erstellen Sie anschließend Routen mit dem Typ VPN-Verbindung.
-
Stellen Sie eine Verbindung zu einem lokalen Netz über einen VPN-Tunnel her.
-
Stellen Sie sicher, dass Ihre VPN-Verbindung verfügbar ist, indem Sie über den Tunnel ein Ping-Signal oder Datenverkehr an Einheiten senden, die sich im Peernetz befinden.
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 ebenfalls von 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 mit einer einzelnen fernen Peereinheit desselben Typs, die einem oder mehreren Peernetzen 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 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 fernen Peereinheiten herzustellen, die verschiedenen VPCs/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 lokale VPN-Gateway befindet sich hinter einer NAT-Einheit und hat keine öffentliche IP-Adresse. Die lokale IKE-Identität des lokalen VPN-Gateways ist die private IP-Adresse, deren Eigner es ist. 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 hat 2 aktive Tunnel im Backend. Wenn beide VPN-Tunnel aktiv sind, wird nur ein Tunnel verwendet, um den VPN-Datenverkehr über den Tunnel zu leiten.
Das VPN verwendet den Tunnel mit der kleinen ö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. Die folgende Abbildung zeigt die Standardkonfiguration. Wenn 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 für die Routenerstellung zurückgegeben, wenn sowohl tunnel 1
als auch tunnel 2
aktiv sind.
Die Protokollstatusfilterung auf einer virtuellen Netzwerkschnittstelle bietet Optionen zur Lösung des asymmetrischen Routingproblems. Weitere Informationen finden Sie unter Filtermodus für den Protokollstatus.
Beim Erstellen von Verbindungen für ein routenbasiertes VPN können Sie jetzt die Verteilung des Datenverkehrs zwischen den Up
Tunneln der VPN-Gateway-Verbindung aktivieren, 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 die Funktion "Verkehr verteilen" aktivieren.
Wie im folgenden Diagramm dargestellt, wird der ausgehende Verkehr dynamisch zu den beiden Tunneln geleitet. Wenn die Tunnel Up
sind, 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
.
Um diese Funktion zu nutzen, sollte das Gerät vor Ort asymmetrisches Routing unterstützen, um eine höhere Netzwerkleistung zu erzielen. Beachten Sie auch, dass nicht alle VPN-Gateways vor Ort diesen Anwendungsfall unterstützen. Wenn z. B. der VPN-Verkehr aus verschiedenen Tunneln ein- und ausgeht, kann der Verkehr durch VPN-Geräte oder Firewalls vor Ort blockiert werden.