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 für die auf dieser Seite verwendete Terminologie finden Sie unter Wichtige Begriffe von Cloud VPN.

Fehlermeldungen

So überprüfen Sie Fehlermeldungen:

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

    VPN aufrufen

  2. Wenn ein Statussymbol angezeigt wird, bewegen Sie den Mauszeiger darauf, um die Fehlermeldung anzusehen.

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

VPN-Logs

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

Informationen zum Anzeigen von Logs für das Peer-Gateway 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. Prüfen Sie, ob die konfigurierten IKE-Versionen auf beiden Seiten des Tunnels identisch sind.
    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 Sie das NAT-Gerät für die Weiterleitung von UDP-Traffic an das Peer-VPN-Gateway über die Ports 500 und 4500 konfiguriert haben. Konfigurieren Sie das Peer-Gateway so, dass es die externe IP-Adresse des NAT-Geräts verwendet. Weitere Informationen finden Sie unter Lokale Gateways hinter NAT.
    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, unterstützte Chiffren zu verwenden, um das Peer-VPN-Gateway zu konfigurieren.
    8. Achten Sie darauf, dass Ihre Peer- und Google Cloud-Routen und Firewallregeln so konfiguriert sind, dass Traffic den Tunnel durchqueren kann. Wenden Sie sich bei Bedarf an Ihren Netzwerkadministrator.
  3. Sie können in Ihren Logs nach folgenden Strings suchen, um bestimmte Probleme zu finden:

    1. Geben Sie im Bereich Query Builder eine der erweiterten Abfragen ein, die in der folgenden Tabelle aufgeführt sind, um nach einem bestimmten Ereignis zu suchen, und klicken Sie auf Abfrage ausführen.
    2. Passen Sie gegebenenfalls den Zeitraum im Bereich Histogramm an und klicken Sie dann in diesem Bereich auf Ausführen. Weitere Informationen zur Verwendung von Logs 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 die folgenden Vorschläge, wenn Sie die Konnektivität zwischen lokalen Systemen und VM-Instanzen von Google Cloud mithilfe von ping prüfen:

  • 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 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.

  • Bei Ping-Tests wird nicht geprüft, ob TCP- oder UDP-Ports geöffnet sind. Nachdem Sie festgestellt haben, dass die Systeme eine einfache Konnektivität haben, können Sie ping für weitere Tests verwenden.

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. Diese Ressource enthält Informationen zum Analysieren von Ergebnissen, Erläuterungen zu Variablen mit Auswirkungen auf die Netzwerkleistung und Tipps zur Fehlerbehebung.

Häufige Probleme und Lösungen

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

Standardmäßig handelt Cloud VPN vor dem Ablauf der vorhandenen Verbindung eine neue Sicherheitsverknüpfung (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-Gruppe (DH) auf einen der empfohlenen Werte gesetzt wurde.

Um nach Ereignissen in Ihrem Cloud VPN-Tunnel zu suchen, können Sie einen erweiterten Logfilter von Logging verwenden. Der folgende erweiterte Filter sucht beispielsweise nach Abweichungen bei der DH-Gruppe:

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.

Cloud VPN prüft im Rahmen der Authentifizierung die Identität des Peer-Gateways. In Cloud VPN wird davon ausgegangen, dass sich jedes Peer-Gateway anhand des Identitätstyps ID_IPV4_ADDR entsprechend RFC 7815 mit der für den Cloud VPN-Tunnel konfigurierten externen IP-Adresse (Peer-Gateway) identifiziert.

Die folgenden Log-Nachrichten lassen darauf schließen, dass sich das Peer-VPN-Gateway fälschlicherweise mit einer internen IP-Adresse identifiziert. In diesem Beispiel ist PEER_GATEWAY_INTERNAL_IP eine interne IP-Adresse und PEER_GATEWAY_EXTERNAL_IP die externe IP-Adresse des NAT-Geräts zwischen dem Peer-VPN-Gateway und dem Internet.

authentication of PEER_GATEWAY_INTERNAL_IP with pre-shared key successful
constraint check failed: identity PEER_GATEWAY_EXTERNAL_IP required
selected peer config 'vpn_PEER_GATEWAY_EXTERNAL_IP' inacceptable: constraint checking failed

Bei Verwendung von 1:1-NAT muss sich das lokale VPN-Gateway mit derselben externen IP-Adresse des NAT-Geräts identifizieren:

  • Der Identitätstyp muss ID_IPV4_ADDR (RFC 7815) sein.

  • Nicht alle Cisco-Geräte unterstützen eine Geräte-ID, die von der internen IP-Adresse des Geräts abweicht. Cisco ASA-Geräten kann als ID beispielsweise keine abweichende (externe) IP-Adresse zugewiesen werden. Daher können Cisco ASA-Geräte nicht für die Verwendung von 1:1-NAT mit Cloud VPN konfiguriert werden.

  • Bei Juniper-Geräten können Sie die Identität des Geräts mit set security ike gateway NAME local-identity inet EXTERNAL_IP festlegen, wobei NAME Ihr VPN-Gateway-Name und EXTERNAL_IP Ihre externe IP-Adresse ist. Weitere Informationen finden Sie in diesem Juniper TechLibrary-Artikel.

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. Zusätzlich zu Routen leiten die meisten VPN-Implementierungen Pakete nur über einen Tunnel weiter, wenn die beiden folgenden Bedingungen zutreffen:

  • Ihre Quellen entsprechen den IP-Bereichen, die in der lokalen Trafficauswahl angegeben sind.
  • Die Ziele müssen innerhalb der IP-Bereiche liegen, die in der Remote-Trafficauswahl angegeben sind.

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.

Klassische VPN- und HA VPN-Gateways verbinden

Google Cloud unterstützt nicht das Erstellen eines Tunnels von einem HA VPN-Gateway, das mit einem klassischen VPN-Gateway verbunden ist. Wenn Sie versuchen, eine externalVpnGateway-Ressource mit der externen IP-Adresse eines klassischen VPN-Gateways zu erstellen, 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.

Dies ist so vorgesehen. Erstellen Sie stattdessen einen VPN-Tunnel, der ein HA VPN-Gateway mit einem anderen HA VPN-Gateway verbindet.

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 Cloud Console.

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

Statusmeldungen

Cloud VPN gibt die folgenden Statusmeldungen an, um das VPN-Gateway und den Tunnelstatus anzugeben. 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

IKE-Chiffrenreferenz

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 IKE-Chiffre finden Sie unter Unterstützte IKE-Chiffren.

Nächste Schritte