Bekannte Probleme für VPN-Gateways

Bekannte Probleme sind identifizierte Fehler oder unerwartete Verhaltensweisen, die vor der Veröffentlichung nicht behoben wurden, aber nicht kritisch genug waren, um die Veröffentlichung zu verzögern. Diese Probleme werden Ihnen mitgeteilt, oft mit Workarounds, und werden vom Entwicklungsteam vorrangig für eine kurzfristige Lösung behandelt.

Für Site-to-Site VPN-Gateways sind folgende Probleme bekannt:

• Ein VPN-Gateway für VPC akzeptiert nur VPN-Pakete mit UDP-Kapselung von IPsec-ESP-Paketen. Encapsulating Security Payload(ESP) Pakete werden nicht akzeptiert. Stellen Sie sicher, dass das NAT-T-Feature auf Ihrem lokalen VPN-Gerät aktiviert ist. Stellen Sie außerdem sicher, dass die Ports UDP 500 und 4500 sowohl für IBM VPC NACL als auch für Peer-Netzwerke zugelassen sind.

  NAT-T ermöglicht es dem VPN-Verkehr, NAT-Geräte zu passieren, indem IPsec-Pakete in UDP gekapselt werden. Ohne NAT-T können IPsec-Pakete von NAT-Geräten verworfen werden, weil sie den ESP-Verkehr nicht richtig verarbeiten können. Um eine zuverlässige VPN-Konnektivität über NAT-Geräte hinweg zu erreichen, muss NAT-T auf Ihrem lokalen Gerät aktiviert sein.

• Wenn mehrere Netze, Teilnetze oder beides entweder einem IBM Cloud VPN-Gateway oder einem lokalen Gerät zugeordnet sind, vermeiden Sie das Mischen von richtlinienbasierten und routenbasierten VPNs. Richtlinienbasierte VPNs erstellen einen Tunnel für jeden Zielnetzbereich. Routenbasierte VPNs leiten jedoch alles über einen einzigen Tunnel an ein Peer-Gerät weiter. Wenn mehrere Netzbereiche konfiguriert sind, kann daher nur ein einziger Tunnel eingerichtet werden, der mit einem einzigen Netzbereich verbunden ist. Das Kombinieren zusammenhängender Subnetze zu einem einzigen CIDR-Superset ist eine gültige Abhilfe.

• Peer-Teilnetze einer VPN-Gateway-Verbindung können sich nicht überschneiden.

• Transit Gateway die Präfix-Filterung wird derzeit für VPN-Gateways nicht unterstützt.

• Wenn Sie ein richtlinienbasiertes VPN mit einer routenbasierten Gegenstelle (oder ein statisches, routenbasiertes VPN mit einer richtlinienbasierten Gegenstelle) verbinden, verwenden Sie nur einen einzigen Netzwerkbereich für beide Seiten. Ein richtlinienbasiertes VPN verwendet einen Tunnel für jedes verbundene Netzwerk, während ein routenbasiertes VPN nur einen einzigen Tunnel benötigt. Verbindungen zwischen verschiedenen VPN-Typen, die mit mehreren Netzbereichen auf beiden Seiten verbunden sind, funktionieren möglicherweise nur für einen Netzbereich.

  

  Kombinieren Sie bei Bedarf zusammenhängende Teilnetze in einem einzigen Netzbereich in einer VPN-Konfiguration. Die Teilnetze 192.168.0.0/24 und 192.168.1.0/24 können in einer VPN- oder Weiterleitungskonfiguration als 192.168.0.0/23 definiert werden.

• Ein richtlinienbasiertes IBM Cloud VPN-Gateway befindet sich in der zugeordneten Zone für das Teilnetz, die Sie beim Bereitstellen ausgewählt haben. Das VPN-Gateway bedient nur virtuelle Serverinstanzen in derselben Zone der VPC. Aus diesem Grund können Instanzen in anderen Zonen das VPN-Gateway nicht für die Kommunikation mit einem lokalen privaten Netz verwenden. Stellen Sie für die Fehlertoleranz in der Zone ein VPN-Gateway pro Zone bereit.

• Ein routenbasiertes IBM Cloud VPN-Gateway befindet sich in der zugeordneten Zone für das Teilnetz, die Sie beim Bereitstellen ausgewählt haben. Es wird empfohlen, dass Ihr VPN-Gateway nur virtuelle Serverinstanzen in derselben Zone des VPC bedient. Durch Hinzufügen von benutzerdefinierten Egress-Routen zur Routing-Tabelle, um den Datenverkehr zu lenken, können Instanzen in anderen Zonen das routenbasierte VPN-Gateway verwenden, um mit einem privaten Netzwerk vor Ort zu kommunizieren; diese Einrichtung wird jedoch nicht empfohlen. Stellen Sie für die Fehlertoleranz in der Zone ein VPN-Gateway pro Zone bereit.

• Wenn Sie Site-to-Site-IPsec-VPN-Verbindungen konfigurieren und optimieren, können Probleme mit der Netzleistung auftreten, von denen eines mit der maximalen Übertragungseinheit (MTU) und der maximalen Segmentgröße (MSS) in Zusammenhang steht. Weitere Informationen finden Sie unter IBM site-to-site VPN Maximum Transmission Unit(MTU)Klemmung.

• Wenn eine Route eine VPN-Gateway-Verbindung als nächsten Hop verwendet, muss sie in einer Egress-Routing-Tabelle vorhanden sein, die mit VPC-Subnetzen verbunden ist. Wenn das VPN-Gateway Datenverkehr in den VPN-Tunnel weiterleitet, prüft es außerdem, ob die Quell-IP dieses Datenverkehrs innerhalb des Teilnetzes liegt, das mit dieser Routing-Tabelle verbunden ist. Liegt die Quell-IP außerhalb dieses Subnetzes, wird der Datenverkehr weder verschlüsselt noch durch den VPN-Tunnel an das Peer-Gateway gesendet. Wenn das VPN-Gateway beispielsweise Datenverkehr empfängt, der über die Ingress-Routing-Tabelle geleitet wird, wird der Datenverkehr nicht in den VPN-Tunnel weitergeleitet, da die Quell-IP außerhalb des Teilnetzes liegt, das der Routing-Tabelle zugeordnet ist.

  Das Erstellen einer Route in einer Ingress-Routing-Tabelle mit einer VPN-Gateway-Verbindung als nächstem Hop wird nicht unterstützt.

• Das Festlegen der lokalen und Peer-IKE-Identitäten (Adresse, FQDN oder Hostname) ist optional, wenn Sie ein VPN-Gateway erstellen. Eine spätere Aktualisierung der Peer-Adresse oder des FQDN kann jedoch die VPN-Konnektivität beeinträchtigen:

  • Wenn Sie die lokale und die Peer-IKE-Identität nicht angeben, verwendet das Gateway automatisch Standardwerte: Die öffentliche IP des VPN-Gateways wird als lokale IKE-Identität verwendet, und die öffentliche IP des Peer-Gateways wird als Peer-IKE-Identität verwendet. Diese Standardeinstellung hilft, eine stabile VPN-Verbindung aufrechtzuerhalten, selbst wenn sich die Peer-Adresse ändert.
  • Wenn Sie die lokale und die Peer-IKE-Identität explizit festlegen, legen Sie bestimmte Werte fest. In diesem Fall müssen Sie bei einer Aktualisierung der Peer-Adresse oder des FQDN die VPN-Verbindung löschen und neu erstellen, um eine Unterbrechung der Verbindung zu vermeiden.