Fehlerbehebung bei IPsec-Tunneln und häufigen Problemen auf der Kontrollebene mit Paketerfassungen

Einleitung

In diesem Dokument wird beschrieben, wie Paketerfassungen und andere Tools bei Problemen auf Steuerungsebene helfen, wenn Site-to-Site-VPN auf Cisco IOS® XE-Routern ausgehandelt wird.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Grundkenntnisse der Konfiguration der Cisco IOS® CLI
• Grundlegende Kenntnisse über IKEv2 und IPsec

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf folgenden Software-Versionen:

• CSR1000V - Cisco IOS XE Software mit Version 16.12.0

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

Die Paketerfassung ist ein leistungsstarkes Tool, mit dem Sie überprüfen können, ob Pakete zwischen VPN-Peer-Geräten gesendet/empfangen werden. Sie bestätigen auch, ob das Verhalten, das bei IPsec-Debugs beobachtet wurde, mit der Ausgabe übereinstimmt, die bei den Erfassungen erfasst wurde, da die Debugs eine logische Interpretation sind und die Erfassung die physische Interaktion zwischen den Peers darstellt. Daher können Sie Verbindungsprobleme bestätigen oder verwerfen.

Nützliche Tools

Es gibt nützliche Tools, die Ihnen helfen, die Aufnahmen zu konfigurieren, die Ausgabe zu extrahieren und weiter zu analysieren. Einige davon sind:

• Wireshark: Dies ist ein bekannter und häufig verwendeter Open-Source-Paketanalysator.
• Überwachungsaufzeichnungen: Die Cisco IOS XE-Funktion auf Routern unterstützt Sie beim Erfassen von Aufnahmen und liefert Ihnen eine ungefähre Ausgabe des Datenverkehrsflusses, der Protokollsammlung und der Zeitstempel.

Konfigurieren von Aufzeichnungen auf dem IOS XE-Router

Bei der Erfassung wird eine erweiterte Zugriffsliste (ACL) verwendet, die den zu erfassenden Datenverkehrstyp sowie die Quell- und Zieladressen der VPN-Peers oder Segmente des interessanten Datenverkehrs definiert. Bei einer Tunnelaushandlung werden der UDP-Port 500 und der Port 4500 verwendet, wenn NAT-T entlang des Pfads aktiviert ist. Wenn die Aushandlung abgeschlossen und der Tunnel eingerichtet ist, verwendet der interessante Datenverkehr das IP-Protokoll 50 (ESP) oder UDP 4500, wenn NAT-T aktiviert ist.

Um Probleme im Zusammenhang mit der Kontrollebene zu beheben, müssen die IP-Adressen der VPN-Peers zur Erfassung der Tunnelverhandlung verwendet werden.

config terminal
ip access-list extended <ACL name>
permit udp host <local address> host <peer address>
permit udp host <peer address> host <source address>
exit
exit

Die konfigurierte ACL wird verwendet, um den erfassten Datenverkehr einzuschränken, und auf der Schnittstelle platziert, über die der Tunnel ausgehandelt wird.

monitor capture <capture name> access-list <ACL name> buffer size <custom buffer size in MB> interface <source interface of teh router> both 

Sobald die Erfassung konfiguriert ist, kann sie manipuliert werden, um sie zu stoppen, zu löschen oder den mit den folgenden Befehlen gesammelten Datenverkehr zu extrahieren:

• Allgemeine Erfassungsinformationen überprüfen: Überwachungserfassung anzeigen
• Starten/Stoppen der Erfassung: Start/Stopp der Monitorerfassung
• Überprüfen Sie, ob die Erfassung Pakete sammelt: show monitor capture cap buffer
• Siehe eine kurze Ausgabe des Datenverkehrs: show monitor capture cap buffer brief
• Erfassung löschen: Überwachungserfassungskappe leeren
• Extrahieren Sie die Erfassungsausgabe:
  • Stopfbuchse für Monitordeckel                             
  • Monitor, Caption, Export, bootflash:capture.pcap

Analysieren der Tunneleinrichtung mit Paketerfassungen

Wie bereits erwähnt, werden zur Aushandlung des IPSec-Tunnels Pakete über UDP mit Port 500 und Port 4500 gesendet, wenn NAT-T aktiviert ist. Bei der Erfassung können mehr Informationen aus den Paketen angezeigt werden, z. B. die Phase, die ausgehandelt wird (Phase 1 oder Phase 2), die Rolle jedes Geräts (Initiator oder Responder) oder die SPI-Werte, die gerade erstellt wurden.

Die kurze Ausgabe der Erfassung durch den Router zeigt die Interaktion zwischen den Peers an und sendet UDP-Pakete.

Nachdem der Dump extrahiert und die pcap-Datei vom Router exportiert wurde, können weitere Informationen aus den Paketen mithilfe von Wireshark angezeigt werden.

Im Internet Protocol-Abschnitt des ersten gesendeten IKE_SA_INIT Exchange-Pakets befinden sich die Quell- und Zieladressen des UDP-Pakets. Im Bereich User Datagram Protocol werden die verwendeten Ports und im Bereich Internet Security Association and Key Management Protocol die Version des Protokolls, die Art der ausgetauschten Nachricht und die Rolle des Geräts sowie der erstellte SPI angezeigt. Beim Sammeln von IKEv2-Debugging-Meldungen werden die gleichen Informationen in den Debug-Protokollen angezeigt.

Wenn die IKE_AUTH-Exchange-Aushandlung stattfindet, wird die Nutzlast verschlüsselt, es werden jedoch einige Informationen über die Aushandlung angezeigt, z. B. der zuvor erstellte SPI und die Art der ausgeführten Transaktion.

Sobald das letzte IKE_AUTH-Exchange-Paket empfangen wurde, ist die Tunnelaushandlung abgeschlossen.

Transaktion, wenn NAT dazwischen liegt

Eine weitere Funktion, die erkennbar ist, wenn die Tunnelaushandlung stattfindet, ist die Nat-Transversal-Funktion. Wenn ein zwischengeschaltetes Gerät eine oder beide für den Tunnel verwendete Adressen nutzt, ändern die Geräte den UDP-Port von 500 auf 4500, wenn Phase 2 (IKE_AUTH-Austausch) ausgehandelt wird.

Aufnahme von Seite A:

Aufnahme von Seite B:

Häufige Probleme auf der Kontrollebene

Lokale oder externe Faktoren können die Tunnelaushandlung beeinflussen und mit Erfassungen identifiziert werden. Die nächsten Szenarien sind die gängigsten.

Konfigurationskonflikt

Dieses Szenario lässt sich durch Betrachtung der Gerätekonfiguration in Phase 1 und Phase 2 lösen. Es kann jedoch Szenarien geben, in denen kein Zugriff auf das Remote-End möglich ist. Hilft bei der Identifizierung des Geräts, das ein NO_PROPOSAL_CHOSEN innerhalb der Pakete in Phase 1 oder 2 sendet. Diese Antwort weist darauf hin, dass möglicherweise ein Problem mit der Konfiguration besteht und welche Phase angepasst werden muss.

Erneute Übertragungen

Eine IPSec-Tunnelaushandlung kann fehlschlagen, weil die Aushandlungspakete entlang des Pfads zwischen den Endgeräten verworfen werden. Bei den verworfenen Paketen kann es sich um Phase-1- oder Phase-2-Pakete handeln. Wenn dies der Fall ist, sendet das Gerät, das ein Antwortpaket erwartet, das letzte Paket erneut. Wenn es nach 5 Versuchen keine Antwort gibt, wird der Tunnel beendet und von Anfang an neu gestartet.

Durch die Erfassung auf beiden Seiten des Tunnels kann ermittelt werden, was den Verkehr möglicherweise blockieren könnte und in welche Richtung er betroffen ist.