Wenn ein IPSec-VPN-Tunnel instabil wird, erfassen Sie die NSX Data Center for vSphere-Produktprotokolle, um mit der grundlegenden Fehlerbehebung zu beginnen. Sie können Paketerfassungssitzungen auf dem Datenpfad einrichten und einige Befehle der NSX Edge-Befehlszeilenschnittstelle ausführen, um die Ursachen der Tunnelinstabilität zu ermitteln.

Wenden Sie das folgende Verfahren an, um die Ursachen der IPSec-VPN-Tunnelinstabilität zu beheben.

Voraussetzungen

Stellen Sie vor dem Einrichten von Paketerfassungssitzungen auf dem Datenpfad sicher, dass die folgenden Anforderungen erfüllt werden:
  • Pakete können an den UDP-Ports 500 und 4500 gesendet und empfangen werden.
  • Der Datenverkehr kann laut Firewallregeln die Ports 500 und 4500 passieren.
  • Die Firewallregeln lassen ESP-Pakete (Encapsulating Security Payload) zu.
  • Das Routing über das lokale Subnetz ist ordnungsgemäß konfiguriert.
  • Überprüfen Sie die MTU-Konfiguration auf Fragmentierungsprobleme, indem Sie eine geringe Ping-Nutzlast und dann eine größere Ping-Nutzlast an die IP-Adresse am Ende des Tunnels senden.

Prozedur

  1. Sammeln Sie die Support-Protokolle von den beiden Sites.
    Wichtig: Aufgrund des beschränkten Speicherplatzes auf der NSX Edge-Appliance müssen Sie Protokolle an einen Syslog-Server umleiten. Weitere Informationen finden Sie im Abschnitt „Konfigurieren von Remote Syslog-Servern“ im NSX Data Center for vSphere-Administratorhandbuch.
  2. Stellen Sie sicher, dass der IPSec-VPN-Dienst auf der NSX Edge korrekt konfiguriert ist und mit den Drittanbieter-Hardware-VPN-Firewalllösungen wie SonicWall, Watchguard usw. funktioniert. Falls erforderlich, wenden Sie sich an den VPN-Anbieter, um spezifische Konfigurationsinformationen zu erhalten, die Sie benötigen.
  3. Richten Sie eine Paketerfassung der IKE-Pakete oder ESP-Pakete zwischen dem NSX Edge und der Drittanbieter-Firewall ein.
  4. Notieren Sie den Echtzeitstatus auf dem NSX Edge, wenn das Problem auftritt. Führen Sie die folgenden Befehle aus und zeichnen Sie die Ergebnisse auf.
    Befehl Zweck
    show service ipsec Überprüfen Sie den Status des IPSec-VPN-Diensts.
    show service ipsec sp Überprüfen Sie den Status der Sicherheitsrichtlinie.
    show service ipsec sa Überprüfen Sie den Status der Sicherheitsverbindung (SA).
  5. Wenn das Problem weiterhin auftritt, erfassen Sie die IPSec-bezogenen Protokolle und die Ausgabe der Drittanbieter-VPN-Lösung.
  6. Überprüfen Sie die IPSec-bezogenen Protokolle und die Ausgabe, um Probleme zu ermitteln. Stellen Sie sicher, dass der IPSec-VPN-Dienst ausgeführt wird, dass Sicherheitsrichtlinien erstellt werden und dass Sicherheitsverbindungen zwischen den Geräten konfiguriert sind.
    Zu den allgemeinen Problemen, die Sie aus den Protokollen erkennen können, zählen folgende:
    • Ungültige ID: INVALID_ID_INFORMATION oder PAYLOAD_MALFORMED
    • Keine vertrauenswürdige Zertifizierungsstelle: INVALID_KEY_INFORMATION oder eine genauere Fehlermeldung Beispiel: kein öffentlicher RSA-Schlüssel bekannt für '=CN, ST=BJ, O=VMWare, OU=CINS, CN=left' oder PAYLOAD_MALFORMED
    • Vorgeschlagene Proxy-ID wurde nicht gefunden: INVALID_ID_INFORMATION oder PAYLOAD_MALFORMED.
    • DPD: Keine Antwort vom Peer. Beispiel: DPD: Keine Antwort vom Peer – Peer als ausgefallen deklarieren.
  7. Überprüfen Sie die Tunnel-Fehlermeldung in der vSphere Web Client- oder NSX Edge-Befehlszeilenschnittstelle (CLI) oder durch Ausführen der NSX Data Center for vSphere-REST-APIs.
    Wenn Sie beispielsweise die Fehlermeldung auf dem vSphere Web Clientanzeigen möchten, doppelklicken Sie auf den NSX Edge, navigieren Sie zu der Seite IPSec-VPN und führen Sie die folgenden Schritte aus:
    1. Klicken Sie auf IPSec-Statistik anzeigen (Show IPSec Statistics).
    2. Wählen Sie den IPSec-Kanal aus, der nicht verfügbar ist.
    3. Wählen Sie für den ausgewählten Kanal den inaktiven (deaktivierten) Tunnel aus und zeigen Sie die Details zum Tunnel-Fehler an.
      • Klicken Sie in NSX 6.4.6 und höher auf Deaktiviert in der Spalte Tunnelzustand.
      • Klicken Sie in NSX 6.4.5 und früher auf Details anzeigen in der Spalte Tunnelzustand.

    Die folgende Tabelle listet die möglichen Ursachen für die IPSec-Tunnel-Verbindungsprobleme und die Fehlermeldung auf, die mit den einzelnen Problemen verknüpft ist.

    Ursachen Fehlermeldung
    IKEv1-Peer ist nicht erreichbar. Version IKEv1: Erneute Übertragung der IKE-Meldung, da keine Antwort vom Peer empfangen wurde.
    Nichtübereinstimmung im Vorschlag für IKEv1-Phase 1 Version IKEv1: Kein Vorschlag ausgewählt. Überprüfen Sie die konfigurierte Verschlüsselung/Authentifizierung/DH/IKE-Version.
    Nichtübereinstimmung bei einem der folgenden Elemente:
    • IKEv1-PSK
    • IKEv1-ID
    • IKEv1-Zertifikat
    Version IKEv1: Authentifizierung fehlgeschlagen. Überprüfen Sie den konfigurierten geheimen Schlüssel oder die lokale/Peer-ID-Konfiguration.
    Nichtübereinstimmung im Vorschlag für IKEv1-Phase 2 IPSec SA-Vorschläge oder Datenverkehrauswahl stimmten nicht überein.
    IKEv2-Peer ist nicht erreichbar. Version IKEv2: Erneute Übertragung der IKE-Meldung, da keine Antwort vom Peer empfangen wurde.
    Nichtübereinstimmung im IKEv2 IKE SA-Vorschlag Version IKEv2: Kein Vorschlag ausgewählt. Überprüfen Sie die konfigurierte Verschlüsselung/Authentifizierung/DH/IKE-Version.
    Nichtübereinstimmung im IKEv2 IPSec SA-Vorschlag IPSec SA-Vorschläge oder Datenverkehrauswahl stimmten nicht überein.
    Nichtübereinstimmung bei der IKEv2 IPSec SA-Datenverkehrauswahl Datenverkehrauswahl stimmt nicht überein. Überprüfen Sie die Subnetzkonfiguration nach links/rechts.
    Nichtübereinstimmung bei einem der folgenden Elemente:
    • IKEv2-PSK
    • IKEv2-ID
    • IKEv2-Zertifikat
    Version IKEv2: Authentifizierung fehlgeschlagen. Überprüfen Sie den konfigurierten geheimen Schlüssel oder die lokale/Peer-ID-Konfiguration.
  8. Wenn das Problem weiterhin auftritt, erfassen Sie den Laufzeitstatus, den Datenverkehrsstatus und die Paketerfassungssitzungen auf dem gesamten Datenpfad.
    Um zu bestimmen, wo Probleme mit dem Datenverkehr auftreten, führen Sie einen Ping-Befehl von einem privaten Subnetz von einer Seite des IPSec-Tunnels zu einem anderen privaten Subnetz auf der anderen Seite des IPSec-Tunnels aus.
    1. Richten Sie die Paketerfassung an den Punkten 1, 2, 3 und 4 ein, wie in der folgenden Abbildung dargestellt.
    2. Pingen Sie von VM 1 an Host 2.
    3. Pingen Sie von Host 2 an VM 1.
    4. Prüfen Sie, an welcher Stelle die Paketübertragung fehlgeschlagen ist oder gelöscht wurde:
    Abbildung 1. Paketerfassung an verschiedenen Punkten auf dem Datenpfad

    Das Image wird im umgebenden Text beschrieben.