Beginnen Sie mit einem Mitschnitt, der vor dem ersten Paket des Versuchs beginnt, sonst lesen Sie die Mitte eines Gesprächs. Eine bereits laufende Aushandlung zeigt verschlüsselte Wechsel und Schlüsselerneuerungen, und keines davon sieht wie die Eröffnung aus. Die Eröffnung ist der Teil, den Sie ohne Schlüssel dekodieren können, und deshalb beantwortet sie Erreichbarkeitsfragen so gut. Vier Prüfungen in dieser Reihenfolge führen Sie von einem frischen Mitschnitt zu einer belastbaren Aussage darüber, welche Seite aufgehört hat zu sprechen.

Erstens: Bestätigen Sie, dass der Mitschnitt am Anfang beginnt

Ein Mitschnitt, der erst nach dem Aufbau des Tunnels startet, enthält den gekapselten Datenstrom und periodische Keepalives, und beides ist entweder verschlüsselt oder nahezu leer. Starten Sie den Client neu und zeichnen Sie den Versuch selbst auf, oder lösen Sie bewusst eine neue Verbindung aus, während der Mitschnitt läuft. Wenn Sie keinen frischen Versuch erzeugen können, notieren Sie das, denn keine Dekodierung holt eine Eröffnung zurück, die Sie nie aufgezeichnet haben.

Begrenzen Sie den Mitschnitt auf die beiden Endpunkte sowie auf UDP 500 und 4500, damit die Datei klein genug zum Lesen bleibt. Auf einem ausgelasteten Host begräbt ein ungefilterter Mitschnitt die Aushandlung unter fremdem Verkehr.

tcpdump -i any -n -s 0 -w fresh-ike.pcap 'udp port 500 or udp port 4500'

Heben Sie die Datei auf, wenn der Versuch interessant ist, denn derselbe Mitschnitt beantwortet beide folgenden Fragen: was der Wechsel war und ob etwas zurückkam. Beschriften Sie sie mit der Startzeit und dem Endpunktpaar, auf das Sie gefiltert haben. Ein Mitschnitt ohne diese beiden Angaben ist eine Woche später nutzlos, wenn sich die Adressen geändert haben und niemand mehr weiß, welcher Versuch aufgezeichnet wurde.

Zweitens: Lesen Sie den Header vor den Nutzlasten

Der IKE-Header trägt die Sicherheitsparameter-Indizes, den Wechseltyp und die Nachrichten-ID, und bei einer neuen Aushandlung sind diese Werte unverwechselbar. Der Initiator erfindet eine SPI ungleich null, die erste Anfrage trägt eine Responder-SPI von null, weil noch keine Antwort gesehen wurde, der Wechseltyp ist IKE_SA_INIT, und die Nachrichten-ID ist null. Alles andere gehört zu einer späteren Phase derselben Aushandlung oder zu einem ganz anderen Versuch.

Die Proposal-, Schlüsselaustausch- und Nonce-Nutzlasten in diesem ersten Wechsel sind im Klartext lesbar. Lesbar heißt nicht authentifiziert, und zu diesem Zeitpunkt hat keine der beiden Seiten ihre Identität bewiesen.

Der private Diffie-Hellman-Wert überquert nie die Leitung, daher lässt der Mitschnitt Sie keine Sitzungsschlüssel ableiten. Die Authentifizierung erfolgt im nächsten Wechsel, geschützt durch das, was der erste ausgehandelt hat. Fragt jemand, ob eine Gegenstelle echt ist, kann dieser Wechsel diese Frage nicht beantworten. Er kann nur zeigen, dass sich beide Seiten auf einen Vorschlag geeinigt und ein gemeinsames Geheimnis erzeugt haben, das die Datei nicht enthält.

Drittens: Ordnen Sie die Anfrage ihrer Antwort zu

Ordnen Sie über das SPI-Paar, den Wechseltyp und die Nachrichten-ID zu und prüfen Sie dann das Antwortflag. Eine Neuübertragung wiederholt die Nachrichten-ID des Originals und ist kein zweiter Anmeldeversuch. Pakete statt Wechsel zu zählen ist der Weg, auf dem eine gesunde Aushandlung zu einer Phantomschleife wird.

Eine Antwort kann auch eine Ablehnung sein: eine Cookie-Anfrage, eine Mitteilung über eine unannehmbare Gruppe oder ein Fehler zu einem Vorschlag. Das sind legitime Antworten, und sie bedeuten, dass der Pfad funktioniert, während die Richtlinie es nicht tut. Dekodieren Sie die Mitteilung, statt jede Antwort als Erfolg zu werten. Wenn die Mitteilung eine Gruppe oder einen Vorschlag nennt, liegt die Reparatur auf der Konfigurationsseite und nicht an der Firewall.

Auch die Richtung zählt. Eine Anfrage ohne Antwort und eine Antwort, die den Client nie erreicht, sind verschiedene Fehler, und nur der zweite sieht wie ein clientseitiger Timeout aus.

Viertens: Trennen Sie IKE von allem anderen auf 4500

Port 4500 trägt drei Dinge, die in einer Übersicht gleich aussehen: IKE hinter einem vier Byte langen Null-Non-ESP-Marker, gekapseltes ESP, dessen Markerposition eine SPI ungleich null enthält, und kurze Keepalives. Dieser Marker trennt IKE von gekapseltem ESP, lesen Sie also diese Bytes, bevor Sie den Verkehr IKE nennen. Ein Mitschnitt-Etikett, das 4500 liest, ist eine Portnummer und kein Protokoll.

Gekapseltes ESP ist verschlüsselte Nutzlast, die Sie ohne Schlüssel nicht deuten können, und seine Anwesenheit kann das Zeichen eines funktionierenden Tunnels sein statt eines Fehlers.

Beobachten Sie beide Ports für denselben Versuch, denn IKE kann nach der NAT-Erkennung auf 4500 wechseln, obwohl es auf 500 eröffnet wurde. Ein nur auf 500 gefilterter Trace wirkt genau dann stumm, wenn die Aushandlung erfolgreich war und den Ort gewechselt hat. Erweitern Sie den Filter und lesen Sie dasselbe Zeitfenster erneut, bevor Sie aus Abwesenheit irgendeinen Schluss ziehen.

Was Stille an einem Beobachtungspunkt bedeutet

Keine Antwort beim Client beweist nur, was dieser Punkt beobachtet hat. Filterung, Routing, die falsche Gegenstelle, ein ausgefallener Dienst und eine Protokollabweichung erzeugen alle denselben leeren Trace.

Ein relevanter ICMP unreachable liefert einen weiteren Beleg, aber lesen Sie das darin zitierte Paket und notieren Sie die Adresse des Geräts, das ihn gesendet hat.

Die Ablehnung eines Routers ist ein anderes Ereignis als ein authentifizierter Fehler der Gegenstelle, und nur der zweite beweist, dass der Dienst lebt. Korrelieren Sie denselben Versuch mit Serverprotokollen oder einer genehmigten Beobachtung, um zu erfahren, ob die Anfrage ankam und ob eine Antwort hinausging. Halten Sie Mitschnitte begrenzt und privat, denn lesbare Handshake-Felder machen den Rest der Datei nicht harmlos. Das Ergebnis, das sich lohnt, ist ein zusammengehörendes Paar aus Anfrage und Antwort oder eine dokumentierte Lücke mit einem benannten Beobachtungspunkt.

Ähnliche Artikel