Häufig gestellte Fragen für Site-to-Site-VPN-Gateways

Welche Arten von VPN-Verbindungen werden von IBM Cloud für VPCs unterstützt?

IBM Cloud unterstützt die folgenden Arten von VPNs für VPC:

• Site-to-Site-VPN: Wird für Netzwerk-zu-Netzwerk-Konnektivität verwendet.
• Client-to-Site-VPN: Wird für den sicheren Fernzugriff einzelner Benutzer verwendet.

Was ist IBM Cloud VPN für VPC (Site-to-Site)?

IBM Cloud VPN für VPC bietet sichere, verschlüsselte Konnektivität zwischen Ihrer IBM Cloud Virtual Private Cloud (VPC) und anderen privaten Netzwerken, wie z. B. Umgebungen vor Ort. Es verwendet IPsec-Tunnel über das Internet, um Daten während der Übertragung zu schützen. Weitere Informationen finden Sie auf der Site-to-Site-VPN-Gateway- und IBM Cloud VPN für VPC-Produktseite.

Was ist der Unterschied zwischen VPN for VPC, Transit Gateway, und Direct Link?

In der folgenden Tabelle sind die Unterschiede zwischen VPN for VPC, Transit Gateway und Direct Link aufgeführt:

Warum sollte ich ein Site-to-Site-VPN und nicht ein Client-to-Site-VPN verwenden?

Nutzen Sie ein Site-to-Site-VPN, um den Datentransfer zwischen Ihrem IBM Cloud VPC und anderen privaten Netzwerken zu sichern und so hybride Cloud-Architekturen und netzwerkübergreifende Kommunikation zu unterstützen. Verwenden Sie ein Client-to-Site-VPN, wenn einzelne Benutzer einen sicheren, verschlüsselten Zugriff von entfernten Standorten aus benötigen, was ideal für Remote-Arbeitsszenarien oder Drittanbieter ist.

Welche Arten von Site-to-Site-VPN werden von IBM Cloud VPC unterstützt?

IBM Cloud VPC unterstützt die folgenden Arten von Site-to-Site-VPNs:

• Richtlinienbasiertes VPN: Leitet den Datenverkehr auf der Grundlage definierter IP-Richtlinien, arbeitet im Aktiv-Standby-Modus, am besten für statische Netzwerke. Weitere Informationen.
• Routenbasiertes VPN: Verwendet virtuelle Tunnelschnittstellen und dynamisches Routing (BGP), unterstützt aktiv-aktive Redundanz, ideal für komplexe, skalierbare Architekturen. Weitere Informationen.

Was sind typische Anwendungsfälle für IBM Cloud site-to-site VPN?

IBM Cloud site-to-Site VPN for VPC hilft bei der Erweiterung der Hybrid-Cloud, der Backup-Konnektivität und der VPC-Kommunikation zwischen den Regionen. Siehe Anwendungsfälle für Site-to-Site-VPNs.

Kann die Site-to-Site-Verbindung VPN for VPC als Backup-Verbindung dienen?

Ja, VPN for VPC wird üblicherweise als Backup zu Direct Link oder als sekundärer Anschluss neben Transit Gateway verwendet. Siehe Hochverfügbarkeit.

Wie schützt IBM Cloud site-to-site VPN meine Daten?

VPN for VPC verwendet fortschrittliche IPsec/IKEv2 verschlüsselungsalgorithmen, um die Vertraulichkeit und Integrität der Daten bei der Übertragung zu gewährleisten. Erfahren Sie mehr über politische Verhandlungen.

Beeinträchtigt das VPN meine Netzwerkgeschwindigkeit?

Die VPN-Verschlüsselung verursacht nur minimalen Overhead. IBM Cloud optimiert VPN für eine zuverlässige Leistung, aber die tatsächliche Geschwindigkeit hängt von Ihren Netzwerkbedingungen und Ihrer Konfiguration ab.

Wie behebe ich Probleme mit der Verbindung IBM Cloud VPN?

Zur Behebung von IBM Cloud VPN Verbindungsproblemen überprüfen Sie den VPN-Dashboard-Tunnelstatus, validieren Routen, überprüfen den Zugriff und die Firewall-Regeln. Weitere Informationen finden Sie unter Fehlerbehebung von Standort zu Standort. Um Probleme mit ausgehandelten, vorgeschlagenen und empfangenen Algorithmen in IKE- und IPsec-Richtlinien zu beheben, siehe Wie prüfe ich IPsec-Protokolle?

Gibt es Benachrichtigungen bei Nichtverfügbarkeit des VPN-Dienstes?

Um über die Nichtverfügbarkeit von VPN-Diensten informiert zu werden, verwenden Sie den IBM Cloud Standardbenachrichtigungsprozess für Wartungsereignisse. Siehe IBM Cloud Status-Seite.

Was ist der Ausgangspunkt für die Einrichtung eines Site-to-Site-VPNs für meine VPC?

Um mit der Einrichtung eines Site-to-Site-VPNs für Ihre VPC zu beginnen, müssen Sie ein VPN-Gateway erstellen. Siehe Erstellen eines VPN-Gateways.

Wie viele Standort-zu-Standort-VPN-Verbindungen kann ich per IBM Cloud VPC einrichten?

Um die Anzahl der Verbindungen für Ihr Site-to-Site-VPN zu bestimmen, siehe VPN-Quoten.

Wo finde ich Preisangaben für IBM Cloud site-to-site VPN for VPC?

Einzelheiten zu den Preisen für IBM Cloud site-to-site VPN for VPC finden Sie auf der Registerkarte "Preise".

Welche bewährten Sicherheitspraktiken sollte ich bei IBM Cloud VPN beachten?

Verwenden Sie eine starke Verschlüsselung, aktualisieren Sie die Konfigurationen regelmäßig und wenden Sie strenge Zugangskontrollen an.

Kann ich beim Erstellen eines VPN-Gateways gleichzeitig VPN-Verbindungen erstellen?

In der IBM Cloud-Konsole können Sie gleichzeitig mit dem Gateway eine Verbindung erstellen. Wenn Sie die API oder die CLI verwenden, müssen VPN-Verbindungen nach der Erstellung des VPN-Gateway erstellt werden.

Wenn ich ein VPN-Gateway lösche, dem VPN-Verbindungen zugeordnet sind, was geschieht mit den Verbindungen?

Die VPN-Verbindungen werden zusammen mit dem VPN-Gateway gelöscht.

Werden IKE- oder IPsec-Richtlinien gelöscht, wenn ein VPN-Gateway oder eine VPN-Verbindung gelöscht wird?

Nein, IKE- und IPsec-Richtlinien werden nicht gelöscht, da sie für mehrere Verbindungen gelten können.

Wie werden die Verschlüsselungsalgorithmen für IKE und IPsec in einer Site-to-Site-VPN-Verbindung ausgewählt?

Wenn Sie in einer IKE- oder IPsec-Richtlinie mehrere Algorithmen auswählen, hängt die endgültige Auswahl davon ab, welche Seite den Algorithmus wählt und in welcher Reihenfolge die Algorithmen bewertet werden. Unterschiede in der Reihenfolge können zu unterschiedlichen Verhandlungsergebnissen führen.

• Wenn IBM Cloud die VPN-Verbindung initiiert, sendet es die Algorithmen in der konfigurierten Reihenfolge, und der Peer trifft die endgültige Auswahl. Wenn z. B. IBM Cloud aes128, aes256 vorschlägt und der Peer aes256, aes128 vorschlägt, kann je nach Implementierung des Peers entweder aes128 oder aes256 gewählt werden.
• Wenn IBM Cloud der Antwortgeber ist, wählt er den ersten passenden Algorithmus auf der Grundlage seiner eigenen konfigurierten Reihenfolge aus. Wenn zum Beispiel IBM Cloud mit aes128, aes256 konfiguriert ist und die Gegenstelle aes256, aes128 vorschlägt, wird aes128 ausgewählt.

Um eine konsistente Algorithmusauswahl zu gewährleisten, konfigurieren Sie identische IKE- und IPsec-Algorithmen und halten Sie die gleiche Prioritätsreihenfolge sowohl auf dem IBM Cloud VPN Gateway als auch auf dem Peer-Gateway ein.

Wie kann ich IPsec-Protokolle überprüfen?

Führen Sie die folgenden Schritte aus, um IPsec-Protokolle für ausgehandelte, vorgeschlagene und empfangene Algorithmen anzuzeigen:

1. Konfigurieren Sie zunächst eine Protokollierungsinstanz für Ihre VPN-Instanz. Weitere Informationen finden Sie unter Konfigurieren des IBM Cloud Logs Routing-Dienstes.
2. Nachdem Sie die Protokollierungsinstanz eingerichtet haben, können Sie auf die IPsec-Protokolleinträge, die von Ihrem VPN erzeugt werden, zugreifen und diese überprüfen. Informationen über das Protokollformat und die verfügbaren Felder finden Sie unter Protokolle für VPN for VPC.

Vergewissern Sie sich beim Debuggen von Verbindungen, dass die von der Gegenstelle empfangenen Vorschläge mindestens einen passenden Algorithmus mit der IKE- und IPsec-Richtlinie auf der Seite IBM haben. Wenn kein passender Algorithmus zwischen der Peer- und der IBM Cloud-Konfiguration existiert, kann die Verbindung nicht aufgebaut werden.

Was geschieht mit einem VPN-Gateway, wenn ich versuche, das Teilnetz zu löschen, in dem sich das Gateway befindet?

Das Subnetz kann nicht gelöscht werden, wenn virtuelle Serverinstanzen vorhanden sind, einschließlich des VPN-Gateways.

Gibt es standardmäßige IKE- und IPsec-Richtlinien?

Ja. Wenn Sie eine VPN-Verbindung erstellen, ohne auf eine Richtlinien-ID (IKE oder IPsec) zu verweisen, wird die automatisch Vereinbarung verwendet.

Warum muss ich beim Bereitstellen eines VPN-Gateways ein Teilnetz auswählen?

Sie müssen ein Subnetz auswählen, wenn Sie ein VPN-Gateway in IBM Cloud bereitstellen, da das Gateway innerhalb eines VPC-Subnetzes bereitgestellt wird, um die Verbindung herzustellen. Ein routenbasiertes VPN kann Konnektivität über alle Zonen hinweg unterstützen, aber das Gateway selbst benötigt vier verfügbare private IP-Adressen im gewählten Subnetz, um hohe Verfügbarkeit und automatische Wartung zu gewährleisten. Am besten verwenden Sie ein dediziertes Subnetz der Größe 16 für das VPN-Gateway, bei dem die Länge des Subnetzpräfixes kleiner oder gleich 28 ist.

Wie sollte ich vorgehen, wenn ACLs in dem Teilnetz verwendet werden, in dem das VPN-Gateways bereitgestellt werden soll?

Stellen Sie sicher, dass ACL-Regeln vorhanden sind, um den Datenverkehr für Verwaltungszwecke und VPN-Tunnel zu ermöglichen. Weitere Informationen finden Sie unter Konfigurieren von Netzwerk-ACLs für die Verwendung mit VPN.

Wie sollte ich vorgehen, wenn ACLs in den Teilnetzen verwendet werden, die mit einem lokalen privaten Netz kommunizieren müssen?

Stellen Sie sicher, dass ACL-Regeln vorhanden sind, die den Datenverkehr zwischen Virtual Server-Instanzen in Ihrer VPC und Ihrem lokalen privaten Netz zulassen. Weitere Informationen finden Sie unter Konfigurieren von ACLs für die Verwendung mit VPN.

Unterstützt VPN for VPC Konfigurationen für Hochverfügbarkeit?

Ja, VPN for VPC unterstützt Hochverfügbarkeit in einer Active-Standby-Konfiguration für richtlinienbasierte VPNs und einer Active-Active-Konfiguration für ein statisches, routenbasiertes VPN.

Ist es vorgesehen, SSL-VPN zu unterstützen?

Nein, nur Site-to-Site-IPsec wird unterstützt.

Gibt es Obergrenzen für den Durchsatz in Site-to-Site-VPNaaS?

Ja, der Durchsatz hängt von verschiedenen Faktoren ab, wie z. B. dem VPN-Modus, der Verteilung des Datenverkehrs, den kryptografischen Einstellungen, der Rechenkapazität, den Netzwerkbedingungen und der Kapazität der Peer-Geräte. Unter optimalen Bedingungen kann ein routenbasiertes VPN im Aktiv-Aktiv-Modus mit aktivierter Option zur Verteilung des Datenverkehrs einen Gesamtdurchsatz von bis zu ~2 Gbit/s über beide Tunnel unterstützen (basierend auf internen Benchmark-Tests von IBM, keine garantierte Grenze in Ihrer Umgebung). Weitere Informationen zum VPN-Durchsatz finden Sie unter Verbessern des Site-to-Site-VPN-Durchsatzes und der Leistung.

Werden PSK-Authentifizierung (PSK, Pre-Shared Key, vorab verteilter gemeinsamer Schlüssel) und zertifikatbasierte IKE-Authentifizierung für VPNaaS unterstützt?

Nur die PSK-Authentifizierung wird unterstützt.

Kann ich VPN for VPC als VPN-Gateway für meine klassische IBM Cloud-Infrastruktur verwenden?

Ja. Die empfohlene Methode zur Verbindung Ihres klassischen Netzwerks mit einer VPC ist die Verwendung eines IBM Cloud Transit Gateway. Siehe Einrichten des Zugangs zur klassischen Infrastruktur.

Was ist eine Rekey-Kollision zwischen Site-to-Site-VPNs?

Eine Rekey-Kollision tritt auf, wenn beide VPN-Peers gleichzeitig versuchen, einen Rekey zu initiieren, was zu widersprüchlichen Verhandlungen, Tunnelinstabilität oder abgebrochenen Verbindungen führen kann. Dieses Problem wird häufig bei IKEv1 beobachtet, da beide Seiten übereinstimmende Schlüssellaufzeiten verwenden müssen und dem Protokoll Mechanismen zur Kollisionsbehandlung fehlen, was es unzuverlässig macht. IKEv1 ist ebenfalls alt und sollte nach Möglichkeit vermieden werden. IKEv2 unterstützt jedoch asymmetrische Schlüssellaufzeiten, um mit gleichzeitigen Rekey-Versuchen umgehen zu können. Wenn Sie IKEv1 verwenden, wird bei Konflikten durch neu erstellte Schlüssel die IKE/IPsec-SA (SA, Security Association, Sicherheitszuordnung) gelöscht. Um die IKE/IPsec-SA erneut zu erstellen, setzen Sie den Verbindungsadministratorstatus auf down und anschließend wieder auf up. Um Rekey-Kollisionen zu minimieren und eine stabile Leistung zu erhalten, verwenden Sie IKEv2.

Wie kann ich den gesamten Datenverkehr von der VPC-Seite an die lokale Seite in einem richtlinienbasierten VPN senden?

Um den gesamten Datenverkehr von der VPC-Seite an die lokale Seite zu senden, setzen Sie die Peer-CIDRs auf 0.0.0.0/0, wenn Sie eine Verbindung erstellen.

Wenn eine Verbindung erfolgreich erstellt wurde, fügt der VPN-Dienst eine CIDR 0.0.0.0/0 über die <VPN gateway private IP>-Route in die Standard-Routing-Tabelle der VPC ein. Diese neue Route kann jedoch Routing-Probleme verursachen, z. B. wenn virtuelle Server in verschiedenen Teilnetzen nicht miteinander kommunizieren können und wenn VPN-Gateways nicht mit lokalen VPN-Gateways kommunizieren.

Informationen zur Behebung von Routing-Problemen finden Sie unter Warum kommunizieren meine VPN-Gateways oder virtuellen Serverinstanzen nicht miteinander?

Was ist der Unterschied zwischen statischen und dynamischen routenbasierten VPN-Verbindungstypen?

Die statische Routing-Verbindung verwendet kein BGP für die Routenanzeige und kann keine Routen an Transit Gateway oder an ein lokales Netzwerk weiterleiten. Bei dieser Verbindung müssen alle Routen manuell erstellt und verwaltet werden, während bei einer dynamischen Verbindung nach der anfänglichen Bereitstellung und Anbindung keine manuelle Konfiguration erforderlich ist.

Wird beim Erstellen eines routenbasierten VPN-Gateways dynamisches Routing unterstützt?

Ja, eine dynamische VPN-Verbindung wird von einem routenbasierten VPN-Gateway unterstützt. Siehe Erstellen eines VPN-Gateways, um ein routenbasiertes VPN zu erstellen, und wählen Sie für den Verbindungstyp dynamisch.

Muss ich eine Transit Gateway anschließen, damit die dynamische Routing-Verbindung funktioniert?

Ja, Sie müssen eine Transit Gateway anschließen, damit die dynamische Routing-Verbindung richtig funktioniert. Ohne Transit Gateway funktioniert die Kommunikation zwischen dem VPN-Gateway und Ihrem lokalen Netz nicht, selbst wenn die IPsec-Verbindung hergestellt ist.

Warum benötige ich eine Transit Gateway für eine dynamische routenbasierte Verbindung?

Eine Transit Gateway ist für dynamisches Routing unerlässlich, da sie als zentraler Knotenpunkt für alle Verbindungen innerhalb Ihres Netzwerks fungiert. Die Transit Gateway verwaltet das Routing für alle Speichen, einschließlich VPN-Verbindungen. Ohne die Transit Gateway könnten die Speichen nicht miteinander kommunizieren, da sie auf die Nabe Transit Gateway angewiesen sind, um den Verkehr zwischen ihnen zu erleichtern und weiterzuleiten.

Kann ich mein VPN mit mehreren Transit Gateways in einer dynamischen, routenbasierten VPN-Verbindung verbinden?

Nein, jedes VPN-Gateway kann nur mit einem Transit Gateway verbunden werden.

Kann ich ein bestehendes Transit Gateway an das routenbasierte VPN für dynamisches Routing anschließen?

Ja, Sie können ein bestehendes Transit Gateway mit dem routenbasierten VPN für dynamisches Routing verbinden. Sie brauchen keine neue Transit Gateway zu erstellen.

Was ist ASN und warum brauche ich es für dynamisches Routing?

Eine Autonomous System Number (ASN) ist ein eindeutiger Bezeichner, der im Border Gateway Protocol (BGP) verwendet wird, um ein Autonomes System (AS) zu repräsentieren. Sie funktioniert ähnlich wie eine öffentliche IP-Adresse in einer IPsec-Verbindung und dient als Schlüsselattribut zur Identifizierung von Geräten innerhalb eines Netzes. Jedes Gerät innerhalb des Netzes ist einem bestimmten ASN zugeordnet, und ohne einen gültigen ASN kann ein VPN-Gateway keine BGP-Sitzung mit anderen Geräten im Netz erfolgreich aufbauen.

Was ist der Nutzen von angekündigten CIDRs?

Angekündigte CIDRs sind statische IP-Adressbereiche, die vom VPN aus erreichbar sind und für Ihr lokales Netzwerk angekündigt werden. Diese CIDRs sind nützlich für private Endpunkte, die nicht direkt mit einem Transit Gateway verbunden werden können, wie z. B. Secrets Manager Endpunkte oder Cloud Object Storage Endpunkte. Durch die Bekanntgabe dieser CIDRs von IBM VPN an Ihr lokales Netzwerk kann jede Ressource innerhalb Ihrer lokalen Umgebung eine Verbindung zu diesen Endpunkten herstellen.

Muss ich Routen konfigurieren, wenn ich eine dynamische, routenbasierte VPN-Verbindung aufbaue?

Nein, Sie müssen die Routen nicht manuell konfigurieren, wenn Sie eine dynamische, routenbasierte VPN-Verbindung erstellen. Alle Speichen, die mit Transit Gateway verbunden sind, stellen automatisch eine Verbindung zu Ihrem Netzwerk vor Ort her.

Wie viele Routen unterstützt VPN for VPC pro VPN-Peer für eine dynamische, routenbasierte Verbindung?

Jedes IBM VPN Gateway unterstützt bis zu 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, müssen Sie die Anzahl der Routen, die von Ihrem lokalen Peer-Netzwerk beworben werden, auf 120 oder weniger reduzieren und dann die Verbindung auf der Website IBM Cloud umschalten, um die BGP-Sitzung wiederherzustellen. Wenn die VPN-Appliance außerdem mehr als 120 Routen über eine Kombination von Peers empfängt, leitet sie nur die ersten 120 Routen an das Transit-Gateway weiter. Wenn zum Beispiel zwei Peers jeweils 70 Routen an die VPN-Appliance senden, werden nur die ersten 120 Routen an das Transit-Gateway weitergeleitet. Wenn Sie mehr als 120 Routen benötigen, können Sie die VPN-Appliance mit verschiedenen Geräten vor Ort verbinden. Beachten Sie jedoch, dass diese Konfiguration keine Hochverfügbarkeit oder Disaster Recovery für die VPN-Appliance garantiert, wenn sie mit verschiedenen Geräten vor Ort verbunden ist.

Führt IBM vierteljährliche ASV-Scans Approved Scanning Vendor) für die VPN-Appliances auf Datenebene durch?

Das vierteljährliche ASV-Scanning ist eine Voraussetzung für den PCI-Sicherheitsstandard (Payment Card Industry (PCI) Security Standards Council). Das ASV-Scanning von VPN-Appliances auf Datenebene ist alleinige Aufgabe des Kunden. IBM verwendet keine ASVs, um Appliances auf Datenebene zu scannen, da diese Scans negative Auswirkungen auf die Funktionen und die Leistung für die Kundenworkloads haben können.

Welche Metriken werden mir in Rechnung gestellt, wenn ich ein VPN-Gateway für VPC verwende?

Für die monatliche Abrechnung des VPN-Gateways werden die folgenden Metriken erfasst:

• Stunden der VPN-Gateway-Instanz: Diese Metrik gibt an, wie lange Ihre VPN-Gateway-Instanz in Betrieb ist.
• Stunden der VPN-Verbindung: Diese Metrik gibt an, wie lange Ihre einzelnen VPN-Verbindungen bestehen und im VPN-Gateway verwaltet werden.
• Floating IP: Die Anzahl der aktiven Floating IP-Adressen, die von der VPN-Gateway-Instanz verwendet werden.

Wenn Sie ein VPN-Gateway verwenden, wird Ihnen auch der gesamte ausgehende öffentliche Internetverkehr zu den VPC-Datentarifen in Rechnung gestellt.

Wann wird der Datenverkehr nicht über ein routenbasiertes VPN-Gateway geleitet?

Wenn Sie eine VPC-Route mit einer VPN-Verbindung als nächstem Hop konfiguriert haben, wird der Datenverkehr aufgrund der folgenden Bedingungen möglicherweise nicht wie erwartet weitergeleitet:

• Die Sicherheitsgruppen, die mit der VPC-Instanz verbunden sind, lassen den Datenverkehr nicht zu. Darüber hinaus blockieren die mit dem Subnetz der Instanz oder dem VPN-Gateway verbundenen Netzwerk-ACLs den Datenverkehr. Stellen Sie sicher, dass Ihre Sicherheitsgruppen und ACLs den gewünschten Datenverkehr zulassen. Weitere Informationen finden Sie unter Konfigurieren von Netzwerk-ACLs für die Verwendung mit VPN.
• Wenn die Quell-IP des Datenverkehrs nicht zu einem Subnetz gehört, das mit der Routing-Tabelle, die die VPN-Route enthält, verbunden ist, verwirft das VPN-Gateway den Datenverkehr. Nehmen wir zum Beispiel eine VPC-Routing-Tabelle, die nur mit Teilnetz A verbunden ist und eine Route enthält, deren nächster Hop eine VPN-Verbindung ist. Erreicht der Datenverkehr das VPN-Gateway, stammt aber von einer IP-Adresse außerhalb von Teilnetz A oder einem anderen Teilnetz, das mit dieser Routing-Tabelle verbunden ist, leitet das Gateway den Datenverkehr nicht weiter.