Fehlerbehebung

Diese Anleitung zur Fehlerbehebung hilft Ihnen, gängige Probleme mit Cloud VPN zu ermitteln und zu lösen.

Interpretationen von Statusmeldungen und Referenzen zu IKE-Chiffre finden Sie im Abschnitt Referenz.

Informationen zum Logging und Monitoring finden Sie unter Logs und Messwerte ansehen.

Definitionen der auf dieser Seite verwendeten Terminologie finden Sie unter Cloud VPN – Wichtige Begriffe.

Fehlermeldungen

So prüfen Sie Fehlermeldungen:

1. Rufen Sie in der Google Cloud Console die Seite VPN auf.

   Zu VPN

2. Wenn Sie ein Statussymbol sehen, können Sie den Mauszeiger darauf bewegen, um die Fehlermeldung anzusehen.

   Hinweis: Aktualisieren Sie Ihren Browser, um eine Änderung des Symbolstatus und des Nachrichtenstatus zu sehen, z. B. von First Handshake auf Established.

Oft kann Ihnen die Fehlermeldung helfen, das Problem zu identifizieren. Prüfen Sie andernfalls Ihre Logs auf weitere Informationen. Ausführliche Statusinformationen finden Sie in der Google Cloud Console auf der Seite Tunneldetails.

VPN-Logs

Cloud VPN-Logs werden in Cloud Logging gespeichert. Das Logging erfolgt automatisch, sie müssen es also nicht aktivieren.

Informationen zum Anzeigen von Logs für die Peer-Gateway-Seite Ihrer Verbindung finden Sie in der Produktdokumentation.

In vielen Fällen sind die Gateways zwar korrekt konfiguriert, doch es tritt ein Problem im Peer-Netzwerk zwischen den Hosts und dem Gateway auf oder es besteht ein Netzwerkproblem zwischen dem Peer-Gateway und dem Cloud VPN-Gateway.

So prüfen Sie die Logs:

1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.

   Zum Log-Explorer

2. Prüfen Sie die Logs hinsichtlich folgender Informationen:

   1. Prüfen Sie, ob die Remote-Peer-IP-Adresse auf dem Cloud VPN-Gateway korrekt konfiguriert ist.
   2. Prüfen Sie, ob Traffic von den lokalen Hosts das Peer-Gateway erreicht.
   3. Prüfen Sie, ob zwischen den beiden VPN-Gateways in beiden Richtungen Traffic fließt. Prüfen Sie die VPN-Logs auf vom anderen VPN-Gateway eingegangene Nachrichten.
   4. Die konfigurierten IKE-Versionen müssen auf beiden Seiten des Tunnels identisch sein.
   5. Prüfen Sie, ob das gemeinsame Secret auf beiden Seiten des Tunnels identisch ist.
   6. Wenn sich das Peer-VPN-Gateway hinter der 1:1-NAT befindet, prüfen Sie, ob das NAT-Gerät für die Weiterleitung von UDP-Traffic an das Peer-VPN-Gateway über die Ports 500 und 4500 richtig konfiguriert ist.
   7. Wenn in den VPN-Logs der Fehler no-proposal-chosen angezeigt wird, konnten sich Cloud VPN und das Peer-VPN-Gateway nicht auf einen Chiffresatz einigen. Bei IKEv1 muss der Chiffresatz genau übereinstimmen. Bei IKEv2 muss von jedem Gateway mindestens eine gemeinsame Chiffre vorgeschlagen werden. Achten Sie darauf, dass Sie unterstützte Chiffren zur Konfiguration Ihres Peer-VPN-Gateways verwenden.
   8. Prüfen Sie, ob Ihre Peer- und Google Cloud-Routen und Firewallregeln so konfiguriert sind, dass Traffic über den Tunnel weitergeleitet werden kann. Wenden Sie sich bei Bedarf an Ihren Netzwerkadministrator.

3. Um bestimmte Probleme zu finden, können Sie in Ihren Logs nach den folgenden Strings suchen:

   1. Geben Sie im Bereich Query Builder eine der in der folgenden Tabelle aufgeführten erweiterten Abfragen ein, um nach einem bestimmten Ereignis zu suchen, und klicken Sie auf Abfrage ausführen.

   2. Passen Sie den Zeitrahmen im Bereich Histogramm an und klicken Sie dann im Bereich auf Ausführen. Weitere Informationen zur Verwendung von Log-Explorer für Abfragen finden Sie unter Logabfragen erstellen.

      Zur Ansicht	Diese Logging-Suche verwenden
      Cloud VPN initiiert Phase 1 (IKE SA).	resource.type="vpn_gateway" ("initiating IKE_SA" OR "generating IKE_SA_INIT request")
      Cloud VPN kann keine Verbindung zu Remote-Peer herstellen.	resource.type="vpn_gateway" "establishing IKE_SA failed, peer not responding"
      IKE-Authentifizierungsereignisse (Phase 1)	resource.type="vpn_gateway" ("generating IKE_AUTH request" OR "parsed IKE_AUTH response")
      Erfolgreiche IKE-Authentifizierung	resource.type="vpn_gateway" ("authentication of" AND "with pre-shared key successful")
      Phase 1 (IKE SA) eingerichtet	resource.type="vpn_gateway" ("IKE_SA" AND "established between")
      Alle Ereignisse der Phase 2 (untergeordnete SA), einschließlich Neuverschlüsselungsereignissen	resource.type="vpn_gateway" "CHILD_SA"
      Peer fordert eine Neuverschlüsselung von Phase 2 an.	resource.type="vpn_gateway" detected rekeying of CHILD_SA
      Peer fordert eine Beendigung von Phase 2 (untergeordnete SA) an.	resource.type="vpn_gateway" received DELETE for ESP CHILD_SA
      Cloud VPN fordert die Beendigung von Phase 2 (untergeordnete SA) an.	resource.type="vpn_gateway" sending DELETE for ESP CHILD_SA
      Cloud VPN schließt Phase 2 (untergeordnete SA), möglicherweise als Antwort an Peer.	resource.type="vpn_gateway" closing CHILD_SA
      Cloud VPN hat Phase 2 selbst geschlossen.	resource.type="vpn_gateway" CHILD_SA closed
      Wenn die Remote-Trafficauswahl nicht übereinstimmt	resource.type="vpn_gateway" Remote traffic selectors narrowed
      Wenn die lokale Trafficauswahl nicht übereinstimmt	resource.type="vpn_gateway" Local traffic selectors narrowed

Verbindung

Beachten Sie beim Prüfen der Konnektivität zwischen lokalen Systemen und Google Cloud-VM-Instanzen mithilfe von ping Folgendes:

• Achten Sie darauf, dass die Firewallregeln in Ihrem Google Cloud-Netzwerk eingehenden ICMP-Traffic zulassen. Die implizierte Regel zum Zulassen von ausgehendem Traffic lässt ausgehenden ICMP-Traffic von Ihrem Netzwerk zu, sofern Sie die Regel nicht überschrieben haben. Prüfen Sie außerdem, ob Ihre lokalen Firewallregeln auch so konfiguriert sind, dass eingehender und ausgehender ICMP-Traffic zugelassen wird.

• Interne IP-Adressen verwenden, um Google Cloud-VMs und lokale Systeme zu pingen. Mit den externen IP-Adressen von VPN-Gateways lässt sich die Konnektivität durch den Tunnel nicht testen.

• Beim Konnektivitätstest von lokalen Systemen zu Google Cloud-VMs empfiehlt es sich, einen Ping-Befehl von einem System in Ihrem Netzwerk und nicht vom VPN-Gateway zu senden. Ein Ping-Test über ein Gateway ist bei Verwendung der entsprechenden Quellschnittstelle möglich. Wenn Sie den Ping-Test jedoch von einer Instanz in Ihrem Netzwerk durchführen, wird dabei gleichzeitig die Firewallkonfiguration geprüft.

• Mit Ping-Tests wird nicht geprüft, ob TCP- oder UDP-Ports geöffnet sind. Nachdem Sie festgestellt haben, dass die Systeme eine grundlegende Konnektivität haben, können Sie mit ping weitere Tests durchführen.

Netzwerkdurchsatz berechnen

Sie können den Netzwerkdurchsatz berechnen, sowohl innerhalb von Google Cloud als auch zu Ihren lokalen Cloud-Standorten oder den Cloud-Standorten von Drittanbietern. Das oben genannte Dokument enthält Informationen zur Analyse von Ergebnissen, Erläuterungen zu Variablen, die sich auf die Netzwerkleistung auswirken können, sowie Tipps zur Fehlerbehebung.

Häufige Probleme und Lösungen

Regelmäßige Tunnelausfälle für mehrere Sekunden

Standardmäßig handelt Cloud VPN vor Ablauf der bestehenden SA (Security Association) eine Ersatz-SA aus. Dies wird auch als Neuverschlüsselung bezeichnet. Auf dem Peer-VPN-Gateway wird möglicherweise keine Neuverschlüsselung durchgeführt. Eventuell wird darauf stattdessen erst nach dem Löschen der vorhandenen SA eine neue SA ausgehandelt, was zu Unterbrechungen führt.

Prüfen Sie in den Cloud VPN-Logs, ob auf dem Peer-Gateway eine Neuverschlüsselung erfolgt. Wenn die Verbindung getrennt und unmittelbar nach der Log-Nachricht Received SA_DELETE wiederhergestellt wird, hat auf dem lokalen Gateway keine Neuverschlüsselung stattgefunden.

Informationen zum Prüfen der Tunneleinstellungen finden Sie im Dokument Unterstützte IKE-Chiffren. Wichtig ist insbesondere, dass die Lebensdauer von Phase 2 korrekt ist und eine Diffie-Hellman (DH)-Gruppe auf einen der empfohlenen Werte gesetzt wurde.

Für die Suche nach Ereignissen in Ihrem Cloud VPN-Tunnel können Sie einen erweiterten Logfilter von Logging verwenden. Der folgende erweiterte Filter sucht beispielsweise nach nicht übereinstimmenden DH-Gruppen:

resource.type="vpn_gateway"
"Peer proposal: DOES NOT HAVE DIFFIE_HELLMAN_GROUP"

Lokale Gateways hinter NAT

Cloud VPN kann mit lokalen oder Peer-VPN-Gateways arbeiten, die sich hinter NAT befinden. Dies ist aufgrund von UDP-Kapselung und NAT-T möglich, wobei nur 1:1-NAT unterstützt wird.

Konnektivität nicht bei allen VMs gegeben

Wenn ping, traceroute oder andere Methoden zum Senden von Traffic nur von einigen VMs zu Ihren lokalen Systemen oder nur von einigen lokalen Systemen zu einigen Google Cloud-VMs funktionieren und Sie überprüft haben, dass sowohl die Google Cloud- als auch die lokalen Firewallregeln den Traffic, den Sie senden, nicht blockieren, haben Sie möglicherweise eine Trafficauswahl, die bestimmte Quellen oder Ziele ausschließt.

Die Trafficauswahl definiert die IP-Adressbereiche eines VPN-Tunnels. Neben Routen werden bei den meisten VPN-Implementierungen nur Pakete durch einen Tunnel übergeben, wenn die beiden folgenden Bedingungen erfüllt sind:

• Die Quellen liegen im IP-Bereich, der in der lokalen Trafficauswahl angegeben ist.
• Ihre Ziele entsprechen den in der Remote-Trafficauswahl angegebenen IP-Bereichen.

Die Trafficauswahl legen Sie beim Erstellen des Tunnels eines klassischen VPN mit richtlinienbasiertem Routing oder einem routenbasierten VPN fest. Außerdem geben Sie beim Erstellen des entsprechenden Peer-Tunnels eine Trafficauswahl an.

Einige Anbieter verwenden synonym zu lokale Trafficauswahl Begriffe wie lokaler Proxy, lokale Verschlüsselungsdomain oder linkes Netzwerk. Synonyme für Remote-Trafficauswahl sind Begriffe wie Remote-Proxy, Remote-Verschlüsselungsdomain oder rechtes Netzwerk.

Wenn Sie die Trafficauswahl für den Tunnel eines klassischen VPN ändern möchten, müssen Sie ihn löschen und neu erstellen. Diese Schritte sind erforderlich, da die Trafficauswahl ein wesentlicher Bestandteil der Tunnelerstellung ist und Tunnel nach der Erstellung nicht mehr bearbeitet werden können.

Beachten Sie beim Definieren der Trafficauswahl Folgendes:

• Die lokale Trafficauswahl für den Cloud VPN-Tunnel sollte alle Subnetze in Ihrem VPC-Netzwerk (Virtual Private Cloud) abdecken, die Sie mit dem Peer-Netzwerk teilen müssen.
• Die lokale Trafficauswahl für das Peer-Netzwerk sollte alle lokalen Subnetze abdecken, die Sie mit dem VPC-Netzwerk teilen müssen.
• Die Trafficauswahl steht in folgendem Bezug zu einem VPN-Tunnel:
  • Die lokale Trafficauswahl für Cloud VPN sollte der Remote-Trafficauswahl für den Tunnel auf dem Peer-VPN-Gateway entsprechen.
  • Die Remote-Trafficauswahl für Cloud VPN sollte der lokalen Trafficauswahl für den Tunnel auf dem Peer-VPN-Gateway entsprechen.

Wichtig: Bei klassischem VPN mit statischem Routing unterstützt IKEv1 pro Trafficauswahl nur einen IP-Bereich bzw. CIDR-Block. Klassisches VPN unterstützt auch die Verwendung mehrerer CIDR-Blöcke für die Trafficauswahl mit IKEv2. Für alle CIDR-Blöcke wird jedoch nur eine einzige untergeordnete SA (Security Association) verwendet. Informationen darüber, ob Ihr Peer-VPN-Gateway mehrere CIDRs in einer einzigen untergeordneten SA mit IKEv2 unterstützt, finden Sie in der Dokumentation Ihres Peer-VPN-Gateways. Weitere Informationen zu mehreren IP-Bereichen und Trafficauswahl finden Sie unter Richtlinienbasierte Tunnel- und Trafficauswahl auf der Seite Netzwerke und Tunnelrouting.

Probleme mit der Netzwerklatenz zwischen VMs in verschiedenen Regionen

Beobachten Sie die Leistung des gesamten Google Cloud-Netzwerks, um festzustellen, ob es Latenz- oder Paketverlustprobleme gibt. In der Google Cloud-Leistungsansicht werden im Dashboard zur Leistungsüberwachung Paketverlust- und Latenzmesswerte in allen Google Cloud-Diensten angezeigt. Anhand dieser Messwerte können Sie nachvollziehen, ob Probleme, die in der Projektleistungsansicht erkennbar sind, nur für Ihr Projekt relevant sind. Weitere Informationen finden Sie unter Dashboard zur Leistungsüberwachung verwenden.

Gateway kann nicht mit einem Nicht-HA-VPN-Gateway verbunden werden

Google Cloud unterstützt nicht das Erstellen von Tunnelverbindungen zwischen einem HA VPN-Gateway und einem Nicht-HA VPN-Gateway, das in Google Cloud gehostet wird. Diese Einschränkung umfasst klassische VPN-Gateways und VPN-Gateways von Drittanbietern, die auf Compute Engine-VMs ausgeführt werden.

Wenn Sie dies versuchen, gibt Google Cloud die folgende Fehlermeldung zurück:

  You cannot provide an interface with an IP address owned by Google Cloud.
  You can only create tunnels from an HA gateway to an HA gateway
  or create tunnels from an HA gateway to an ExternalVpnGateway.

Zur Vermeidung dieses Fehlers erstellen Sie einen VPN-Tunnel, der Ihr HA VPN-Gateway mit einem der folgenden verbindet:

• Ein weiteres HA VPN-Gateway
• Ein externes VPN-Gateway, das nicht in Google Cloud gehostet wird

Verbindung zu externem Ziel über HA VPN nicht möglich

Wenn Sie ein HA VPN-Gateway verwenden, verwenden Google Cloud-Ressourcen den VPN-Tunnel, um nur eine Verbindung zu den Zielen herzustellen, die vom Peer-Router beworben werden.

Wenn Sie keine Verbindung zu einem Remote-Ziel herstellen können, achten Sie darauf, dass der Peer-Router den IP-Bereich des Ziels bewirbt.

IPv6-Traffic wird nicht weitergeleitet

Wenn Sie Probleme beim Herstellen einer Verbindung zu IPv6-Hosts haben, gehen Sie so vor:

1. Prüfen Sie, ob IPv4-Routen ordnungsgemäß beworben werden. Wenn IPv4-Routen nicht beworben werden, lesen Sie die Informationen unter Fehlerbehebung: BGP-Routen und Routenauswahl.
2. Prüfen Sie die Firewallregeln, um sicherzugehen, dass IPv6-Traffic zugelassen wird.
3. Achten Sie darauf, dass sich in Ihrem VPC-Netzwerk und im lokalen Netzwerk keine überlappenden IPv6-Subnetzbereiche befinden. Siehe Überlappende Subnetzbereiche prüfen.
4. Prüfen Sie, ob Sie Kontingente und Limits für Ihre erkannten Routen in Cloud Router überschritten haben. Wenn Sie Ihr Kontingent für erkannte Routen überschritten haben, werden IPv6-Präfixe vor IPv4-Präfixen gelöscht. Siehe Kontingente und Limits prüfen.
5. Prüfen Sie, ob alle Komponenten, die eine IPv6-Konfiguration erfordern, korrekt konfiguriert wurden.
   • Das VPC-Netzwerk hat die Verwendung interner IPv6-Adressen mit dem Flag --enable-ula-internal-ipv6 aktiviert.
   • Das VPC-Subnetz ist für die Verwendung des Stack-Typs IPV4_IPV6 konfiguriert.
   • Im VPC-Subnetz ist --ipv6-access-type auf INTERNAL festgelegt.
   • Die Compute Engine-VMs im Subnetz sind mit IPv6-Adressen konfiguriert.
   • Das HA VPN-Gateway ist für die Verwendung des Stack-Typs IPV4_IPV6 konfiguriert.
   • Der BGP-Peer hat IPv6 aktiviert und die richtigen IPv6-Adressen des nächsten Hops sind für die BGP-Sitzung konfiguriert.
     • Informationen zum Aufrufen des Status und der Routen von Cloud Router finden Sie unter Status und Routen von Cloud Router ansehen.
     • Informationen zum Konfigurieren der BGP-Sitzung finden Sie unter BGP-Sitzungskonfiguration ansehen.

Referenz zur Fehlerbehebung

Dieser Abschnitt enthält Informationen zu Statussymbolen, Statusmeldungen und unterstützten IKE-Chiffren.

Statussymbole

Cloud VPN verwendet die folgenden Statussymbole in der Google Cloud Console:

Symbol	Farbe	Beschreibung	Gilt für folgende Nachrichten
	Grün	Erfolg	ETABLIERT
	Gelb	Warnung	RESSOURCEN WERDEN ZUGEWIESEN, ERSTER HANDSHAKE, WARTEN AUF VOLLSTÄNDIGE KONFIGURATION, BEREITSTELLUNG
	Rot	Fehler	Alle sonstigen Nachrichten

Statusmeldungen

Zur Anzeige von VPN-Gateway- und Tunnelstatus verwendet Cloud VPN die folgenden Statusmeldungen: Der VPN-Tunnel wird für die angegebenen Status in Rechnung gestellt.

Meldung	Beschreibung	Tunnel für diesen Status in Rechnung gestellt?
RESSOURCEN WERDEN ZUGEWIESEN	Ressourcen werden zum Einrichten eines Tunnels zugewiesen.	Ja
BEREITSTELLUNG	Zum Einrichten des Tunnels wird auf den Erhalt der vollständigen Konfiguration gewartet.	Nein
WARTEN AUF VOLLSTÄNDIGE KONFIGURATION	Die Konfiguration ist vollständig vorhanden, aber der Tunnel wurde noch nicht eingerichtet.	Ja
ERSTER HANDSHAKE	Der Tunnel wird eingerichtet.	Ja
ETABLIERT	Eine sichere Kommunikationssitzung wurde erfolgreich eingerichtet.	Ja
NETZWERKFEHLER (ersetzt durch KEINE EINGEHENDEN PAKETE)	Die IPsec-Autorisierung ist fehlgeschlagen.	Ja
AUTORISIERUNGSFEHLER	Der Handshake ist fehlgeschlagen.	Ja
AUSHANDLUNGSFEHLER	Die Tunnelkonfiguration wurde abgelehnt, möglicherweise aufgrund eines Eintrags in der Ablehnungsliste.	Ja
BEREITSTELLUNG WIRD AUFGEHOBEN	Der Tunnel wird heruntergefahren.	Nein
KEINE EINGEHENDEN PAKETE	Das Gateway empfängt keine Pakete vom lokalen VPN.	Ja
REJECTED	Die Tunnelkonfiguration wurde abgelehnt. Bitte wenden Sie sich an den Support.	Ja
ANGEHALTEN	Der Tunnel wird angehalten und ist nicht aktiv. Das kann darauf zurückzuführen sein, dass eine oder mehrere erforderliche Weiterleitungsregeln für den VPN-Tunnel gelöscht werden.	Ja

Referenz zu IKE-Chiffren

Cloud VPN unterstützt Chiffren und Konfigurationsparameter für Peer-VPN-Geräte oder VPN-Dienste. Die Verbindung wird automatisch ausgehandelt, solange auf der Peer-Seite eine unterstützte IKE-Chiffreeinstellung verwendet wird.

Die vollständige Referenz zu IKE-Chiffren finden Sie unter Unterstützte IKE-Chiffren.

Nächste Schritte

• Weitere Informationen zu den grundlegenden Konzepten von Cloud VPN finden Sie in Cloud VPN – Übersicht.
• Informationen zu Szenarien mit hoher Verfügbarkeit, hohem Durchsatz oder mehreren Subnetzen finden Sie unter Erweiterte Konfigurationen.