IKEv2-Fragmentierung von einem Zertifikatskettenproblem unterscheiden

Der Tunnel lief im Büronetz und bleibt zu Hause stehen, und das Protokoll zeigt, dass der erste Austausch abgeschlossen wird, bevor sonst etwas passiert. Dieses Muster deutet auf den Authentifizierungsaustausch hin, nicht auf Anmeldedaten: Eine Zertifikatskette macht diese Nachricht viel größer als die vorherige, und ein Pfad, der große Datagramme nicht mag, verwirft sie stillschweigend. Es sind zwei verschiedene Fragmentierungsmechanismen beteiligt, und zu wissen, welchen man vor sich hat, entscheidet über die Lösung.

Zwei Fragmentierungsmechanismen, ein Symptom

IKEv2 hat eine eigene Fragmentierungserweiterung, definiert in RFC 7383, die geschützte IKE-Nachrichten in kleinere IKE-Nachrichten aufteilt. Die Peers verhandeln diese Fähigkeit, und eine Nachricht wird von der IKE-Implementierung statt von der IP-Schicht wieder zusammengesetzt.

Gewöhnliche IP-Fragmentierung ist ein anderer Mechanismus mit einem anderen Fehlerbild. Ein Router zwischen den Peers fragmentiert ein großes Datagramm oder verwirft es und sendet eine ICMP-Nachricht zurück, die den Absender möglicherweise nie erreicht. Manche Netze verwerfen Fragmente stillschweigend, und manche Middleboxen verarbeiten das erste Fragment, aber nicht den Rest. Aus Sicht der Anwendung sehen alle drei Fälle gleich aus.

NAT-Traversal fügt eine dritte Variable hinzu, weil ESP dann in UDP eingepackt wird und das äußere Paket größer wird, während es wie gewöhnlicher UDP-Verkehr auf Port 4500 aussieht. Ein Pfad, der UDP gut durchlässt, kann an einem Datagramm scheitern, das nicht mehr passt.

Den fehlgeschlagenen Austausch lesen

Suchen Sie den Übergang statt den Fehler. Ein Protokoll, das den ersten Austausch gesendet und beantwortet zeigt, gefolgt von nichts, sagt Ihnen, dass die nächste Nachricht nie abgeschlossen wurde. Erhöhen Sie vorübergehend die Protokollstufe und vergleichen Sie die gemeldeten Größen auf beiden Seiten.

Was Sie feststellen wollen, ist, ob der Responder die Anfrage überhaupt gesehen hat. Wenn der Initiator etwas gesendet hat und der Responder keinen Eintrag darüber hat, liegt das Problem in der Zustellung. Wenn der Responder eine Anfrage geparst und abgelehnt hat, ist das Zertifikat selbst das Problem, und Fragmentierung lenkt ab. Diese Unterscheidung ist mehr wert als eine Seite mit Timeout-Meldungen.

Den Pfad ändern, nicht das Zertifikat

Testen Sie denselben Client, dasselbe Zertifikat und dieselbe Konfiguration aus einem anderen Netz. Ein mobiler Hotspot ist normalerweise der günstigste zweite Pfad, und er unterscheidet sich wirklich von der Büroverbindung, nicht nur nominell.

Wenn der Handshake auf dem zweiten Pfad abgeschlossen wird, ist die Zertifikatskette in Ordnung und der erste Pfad die Variable. Wenn er auf beiden identisch scheitert, hören Sie auf, Netze zu testen, und sehen Sie sich die Nachrichten selbst an. Dieser eine Vergleich beseitigt etwa die Hälfte der möglichen Erklärungen.

Den Austausch messen, bevor Sie etwas ändern

Ermitteln Sie die Größe der Kette und die Größe des Pfads. Beide Zahlen begrenzen, was der Handshake senden kann, und beide sind billig zu messen:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

Die ersten beiden liefern die Anzahl der Zertifikate und die Dateigröße, was ein vernünftiger Anhaltspunkt dafür ist, wie groß die Authentifizierungsnachricht wird. Die Ping-Sonde meldet, ob ein Datagramm dieser Größe den Pfad übersteht, und die Schnittstellenzähler zeigen, ob Fragmente auf Ihrer Seite verworfen wurden. Unter Windows ist die entsprechende Sonde ein Ping mit dem Do-not-fragment-Flag und einer expliziten Nutzlastgröße.

Wiederholen Sie die Sonde abwärts, bis sie gelingt. Die größte Größe, die durchkommt, ist das Arbeitsbudget für diesen Pfad, und sie ist nützlicher als jeder veröffentlichte Standardwert.

Die Schicht reparieren, die tatsächlich kaputt ist

Wenn der Pfad große Datagramme verwirft, aktivieren Sie die IKE-Fragmentierung auf beiden Seiten und bestätigen Sie, dass die Erweiterung ausgehandelt und nicht nur angeboten wurde. Wenn der Pfad Fragmente auf IP-Ebene schlecht behandelt, gehört die Korrektur dorthin oder in die MTU der äußeren Schnittstelle, nicht in den Zertifikatsspeicher.

Wenn die Kette unnötig lang ist, kürzen Sie sie auf die Zwischenzertifikate, die ein Peer tatsächlich braucht. Eine Wurzel zu entfernen, der der Client bereits vertraut, ist vernünftige Pflege; ein Zwischenzertifikat zu entfernen nicht, und die Prüfung zu deaktivieren, um eine Nachricht zu verkleinern, tauscht ein Zustellungsproblem gegen ein Sicherheitsproblem.

Notieren Sie, welchen Mechanismus Sie geändert haben und wie der Handshake danach aussah. Das nächste Auftreten ist meist in einem anderen Netz mit demselben Symptom, und die Notiz ist das, was zwei Stunden in zehn Minuten verwandelt.