Doppelte IKE-Pakete: den fehlenden Übergang finden

Das Protokoll zeigt dieselbe IKE-Anfrage zweimal, jemand zeigt auf den mobilen Uplink, und das Ticket wird mit einer Vermutung geschlossen. Diese Vermutung ist der Mythos: Ein wiederholtes Paket ist eine Beobachtung über einen Austausch, keine Diagnose einer Verbindung. Neuübertragung ist normales Verhalten mit eigenen Regeln, und sie erscheint auf gesunden Pfaden, sobald eine Antwort langsam ist. Folgen Sie der Antwort, bevor Sie eine Schnittstelle beschuldigen.

Der Mythos: Eine wiederholte Anfrage beweist Verlust auf einer Verbindung

Zwei verschiedene Dinge erzeugen ein Duplikat, und keines benennt einen Schuldigen. Der Anfragende kann eine Anfrage wiederholen, weil er keine Antwort erhalten hat, oder der Erfassungspunkt kann dasselbe Paket zweimal zeigen, weil er an einer bestimmten Stelle am Stack hängt. Ein Tap, der eingehenden und ausgehenden Verkehr auf demselben Host sieht, protokolliert ein Paket ohne Weiteres als zwei, und wer dieses Protokoll liest, kann den Unterschied ohne die Austauschkennungen nicht erkennen. Behandeln Sie das Duplikat als Timer-Ereignis, bis Sie sagen können, welches der beiden Sie in der Hand halten.

Zwei Uplinks verschlimmern die Verwirrung, statt sie zu lindern. Eine einzelne Protokollzeile nennt eine Schnittstelle, während die Antwort über die andere hinausgegangen sein kann, die Schnittstelle in der Meldung beschreibt also, wo ein Paket gesehen wurde, und nicht die Form des Gesprächs. Deshalb lautet die erste Frage, welchen Austausch Sie betrachten, und nicht, welche Verbindung defekt ist.

Was die Neuübertragung Ihnen tatsächlich sagt

In IKEv2 funktioniert Neuübertragung so: Der Anfragende wiederholt eine Anfrage, wenn keine Antwort eingetroffen ist, und der Antwortende kann seine zwischengespeicherte Antwort erneut senden, statt eine neue zu berechnen. Nachrichtenkennungen gehören zu diesem Austausch, und genau das macht eine wiederholte Anfrage mit derselben Kennung als arbeitendes Protokoll erkennbar und nicht als neuen Versuch. Ein erster Versuch braucht oft mehr als eine Quelladresse oder eine Initiator-SPI zur Zuordnung, daher schlägt der eigene Austauschdatensatz der Plattform eine Paketliste. IKEv1 folgt anderen Regeln mit anderen Kennungen, und eine Herstellerwarnung zu einem doppelten ersten Paket bedeutet nicht über alle Versionen dasselbe.

Ein Neuübertragungs-Zeitstempel sagt Ihnen also, dass ein Timer abgelaufen ist. Er sagt Ihnen nicht, welcher Hop langsam war, und er sagt schon gar nicht, dass der Betreiber schuld ist. Das sind getrennte Aussagen, und nur die zweite ist in einem Ticket nützlich.

Die praktische Konsequenz ist, den Austausch festzuhalten, bevor Sie eine Schlussfolgerung ziehen. Notieren Sie die lokale Empfangsadresse, den von der Richtlinie gewählten Antwortpfad, das Peer-Tupel und die Austauschkennungen an einer Stelle, denn jede davon beantwortet eine andere Frage, wenn der Datensatz später gelesen wird.

Vier Beobachtungspunkte als eine Kette

Betrachten Sie den Austausch als vier Glieder einer Kette und nicht als vier getrennte Stellen zum Nachsehen. Ein Glied trägt einen Beleg oder bleibt unbekannt, und die Kette ist nur so aussagekräftig wie ihr schwächstes festgehaltenes Glied. Die folgende Tabelle ist das Inventar: was jede Position belegen kann und was sie unberührt lässt.

Füllen Sie die Kette nur dort, wo Sie Zugriff haben, und markieren Sie den Rest als unbekannt, statt ihn zu erschließen. Ein Hook, der Pakete auf einer Maschine aufzeichnet, sagt nichts darüber, was die entfernte Maschine empfangen hat, und eine Protokollzeile, dass eine Anfrage gesehen wurde, ist kein Beleg dafür, dass je eine Antwort hinausging. Ehrliche Lücken sind nützlicher als ein vollständig wirkender Datensatz aus Vermutungen.

Finden Sie den ersten fehlenden Übergang

Gehen Sie die Kette vom Initiator nach außen und halten Sie am ersten Glied ohne Beleg an. Wenn das Gateway die Anfrage nie protokolliert, liegt der Fehler auf dem Pfad davor. Wenn das Gateway dieselbe Anfrage wiederholt protokolliert, während der Client nie eine Antwort protokolliert, ist die Rückrichtung verdächtig: Quelladresse, Übersetzung und Filterung an jeder Grenze, die Sie kontrollieren. Kommt die Antwort an und der Client bewegt sich dennoch nicht weiter, hat die Frage den Transport verlassen und ist zu Richtlinie oder Zustand geworden.

Halten Sie Peer und Protokoll beim Vergleichen fest, und denken Sie daran, dass Verzögerung, Verlust, Richtlinie und Zustand jeweils eine andere Zeitlinie erzeugen. Ein Mobilfunknetz ist nicht automatisch die Ursache, und eine Festleitung ist nicht automatisch zuverlässig genug für jede Anforderung. Zeichnen Sie beide Richtungen auf, während der Austausch läuft:

tcpdump -ni any -vv 'udp port 500 or udp port 4500'

Wenn der Zugriff vor dem fernen Ende endet, hilft der Datensatz weiterhin, wenn er sagt, wo er endet. Eine Aufzeichnung nur am Initiator kann zeigen, dass eine Anfrage hinausgeht und keine Antwort ankommt, was den Fehler auf alles nach diesem Hook eingrenzt, ohne vorzugeben zu wissen, welcher Hop sie verworfen hat. Markieren Sie die fernen Glieder als unbekannt und lassen Sie die nächste Person mit Zugriff sie ausfüllen. So festgehalten bleibt der Datensatz ehrlich und trotzdem kurz.

Vergleichen Sie, bevor Sie etwas ändern. Dieselbe Anfrage gegen denselben Peer mit demselben Protokoll zu wiederholen, hält die Variablen zählbar, während ein Reset, eine Schlüsselerneuerung oder eine Richtlinienänderung zwischen Aufzeichnungen den Vergleich zerstört. Ist eine Änderung unvermeidlich, zeichnen Sie unmittelbar danach erneut auf, damit Vorher und Nachher noch denselben Austausch beschreiben.

Was ein brauchbarer Bericht sagt

Ein Bericht, auf dessen Grundlage man handeln kann, verbindet eine Anfrage mit ihrer Antwort und benennt den ersten Schritt, hinter dem kein Beleg steht. Dieser Satz übersteht es, eine Woche später von einem Ingenieur gelesen zu werden, der nicht dabei war, und er gibt der nächsten Person einen Ausgangspunkt statt eines Verdächtigen.

Lockern Sie niemals Identitätsprüfungen oder erweitern Sie die zulässige Protokollmenge, nur um eine Neuübertragungstheorie zu prüfen. Sichern Sie die Originalpakete und Ereignisaufzeichnungen vor jedem Reset, denn ein Reset zerstört genau das Material, das Sie gerade sammeln wollten, und löscht die Zeitfolge, die zeigte, wo der Austausch stockte.

Der Mythos ist, dass ein Duplikat beweist, dass ein Betreiber schuld ist. Die Realität ist, dass ein Duplikat beweist, dass ein Timer abgelaufen ist, und die Antwort liegt auf dem Antwortpfad.