So lesen Sie den ersten IKEv2-Austausch in einem Paketmitschnitt

Mitschnitte mitten in einer Sitzung sind der übliche Grund, warum eine IKEv2-Spur wie Rauschen aussieht, denn die Gegenstellen tauschen bereits Schlüssel aus oder übertragen verschlüsselte Nutzdaten, wenn die Aufzeichnung beginnt. Beginnen Sie stattdessen mit einem frischen Verbindungsversuch, damit die erste Nachricht in der Datei diejenige ist, die die Aushandlung eröffnet. Die folgende Lesereihenfolge setzt das voraus und markiert den Punkt, an dem ein Paket nichts mehr über die Gegenseite beweist. Genau dieses Überspringen führt dazu, dass ein funktionierender Tunnel als blockierter Port diagnostiziert wird.

Bestätigen Sie, dass Sie den Eröffnungsaustausch sehen

Eine IKEv2-Aushandlung beginnt mit IKE_SA_INIT, Austauschtyp 34, Nachrichten-ID 0. Der Initiator wählt einen SPI ungleich null, und der Responder-SPI ist in dieser ersten Anfrage null und in der Antwort ungleich null. Diese drei Tatsachen trennen einen frischen Versuch von einer Schlüsselerneuerung oder von einer IKE_AUTH-Nachricht, die zufällig oben in einem Mitschnitt steht.

Header-Felder sind lesbar, ebenso die Proposal-, Key-Exchange- und Nonce-Nutzdaten. Lesbar heißt nicht authentifiziert: Keine der beiden Seiten hat zu diesem Zeitpunkt eine Identität nachgewiesen, und der private Diffie-Hellman-Wert erscheint nie auf der Leitung.

Geben Sie die Felder als Tabelle aus, statt durch einen Decode-Bereich zu scrollen, denn Neuübertragungen und nicht zusammenpassende SPIs werden in Spalten offensichtlich.

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

Lesen Sie die Ausgabe paarweise. Eine Anfrage mit Nachrichten-ID 0, gefolgt von einer Antwort mit derselben ID und einem Responder-SPI ungleich null, ist ein Austausch, selbst wenn er dreimal erscheint, weil die Anfrage erneut übertragen wurde. Drei identische Anfragen sind keine drei Anmeldungen, und genau diese Deutung führt zu der Annahme, ein Client drehe eine Schleife, während er nur geduldig ist. Sortieren Sie nach Nachrichten-ID und dann nach Zeitstempel, und das ganze Gespräch schrumpft auf eine kurze Liste von Versuchen.

Lesen Sie eine Ablehnung, bevor Sie einen Erfolg lesen

Eine Antwort ist nicht automatisch ein Fortschritt. Der Responder kann mit einer Cookie-Notification antworten und erwarten, dass der Initiator es erneut versucht, oder mit INVALID_KE_PAYLOAD, das eine Gruppe nennt, die er stattdessen akzeptieren würde. Beides kommt als wohlgeformte IKE-Nachricht an, und beides sieht für einen Filter, der nur Pakete zählt, wie ein abgeschlossener Austausch aus.

Öffnen Sie die Notify-Nutzdaten und lesen Sie zuerst den Typ. Eine Cookie-Challenge bedeutet, dass der Responder sich gegen gefälschte Quelladressen verteidigt, und der Client muss mit angehängtem Cookie erneut senden. Eine ungültige Gruppe bedeutet, dass die beiden Vorschläge nicht übereinstimmen, was kein noch so häufiges Wiederholen ändert, bis sich die Konfiguration einer Seite bewegt.

Nur IKE_AUTH, der zweite Austausch, trägt die verschlüsselte Identität und die Authentifizierungs-Nutzdaten. Ein abgeschlossenes IKE_SA_INIT sagt Ihnen daher, dass die Seiten sich über Algorithmen und abgeleitete Schlüssel einig sind, und nichts darüber, ob die Anmeldedaten akzeptiert werden. Erwarten Sie auch dort zwei Nachrichten, und erwarten Sie, dass beide ohne die Sitzungsschlüssel undurchsichtig sind.

Port 4500 ist nicht ein Protokoll

UDP 500 trägt üblicherweise den Eröffnungsaustausch. Sobald die NAT-Erkennung gelaufen ist, wechselt IKE auf 4500 und stellt jeder Nachricht einen vier Byte langen Null-Marker voran, der kein ESP ist. Gekapseltes ESP auf demselben Port beginnt stattdessen mit einem ESP-SPI ungleich null, und ein ein Byte langer NAT-Keepalive ist eine dritte Form, die auftaucht, wenn sonst nichts passiert.

Ein Filter, der nur auf den Port passt, mischt alle drei, weshalb "auf 4500 ist Verkehr" so wenig klärt. Teilen Sie die Ansicht nach Protokoll auf, bevor Sie etwas über die Gegenseite schließen.

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

Stille beschreibt den Beobachtungspunkt

Anfragen ohne Antworten belegen genau eine Sache: An diesem Mitschnittpunkt erschien keine Antwort. Filterung, eine Route, die die Antwort woanders hinschickt, ein nicht erreichbarer Responder oder ein Responder, dem der Vorschlag nicht gefällt, erzeugen alle dasselbe leere Ergebnis, und eine allgemeine UDP-Sonde wird sie nicht trennen.

Ein ICMP-Unreachable ist ein Beweis anderer Art. Lesen Sie das darin zitierte Paket und stellen Sie fest, welches Gerät es ausgesandt hat, denn die administrative Ablehnung eines Routers ist kein authentifizierter Fehler der Gegenseite.

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

Korrelieren Sie denselben Versuch mit serverseitigen Protokollen, wo Sie sie lesen dürfen. Kam die Anfrage an, antwortete der Dienst, und wo endete die Antwort? Diese drei Antworten schicken Sie zu einem Pfadproblem oder zu einem Richtlinienproblem, und sie kosten weniger, als die Anmeldedaten ein viertes Mal zu tauschen.