ESP entschlüsselt sauber, und das innere Paket kommt trotzdem nirgendwo an

Der ESP-Empfangszähler steigt, der Tunnel bleibt oben, und die Anwendung sieht das Paket nie. Die Entschlüsselung lief, die Integritätsprüfung bestand, und dann musste der Empfänger entscheiden, was die geschützte Nutzlast eigentlich ist. Genau an diesem letzten Schritt zeigt sich eine Formatabweichung, und von außen sieht das überhaupt nicht nach einem Firewall-Problem aus.

Was Sie sehen, wenn das Etikett lügt

Nichts im Client-Log unterscheidet das von einem Routing-Schwarzen Loch. Beides erzeugt einen Anwendungs-Timeout neben einem gesunden Tunnel, weshalb zuerst die Zähler beschuldigt werden.

Ein steigender Empfangszähler ist tatsächlich eine gute Nachricht: Pakete kommen an und werden authentifiziert. Es ist kein Beweis dafür, dass das innere Paket für irgendetwas oberhalb der Kryptoschicht Sinn ergab.

Der Typ wohnt im Trailer

Im gewöhnlichen IPsec-Tunnelmodus enthält die ESP-geschützte Nutzlast ein vollständiges inneres IP-Paket. Das Next-Header-Feld im Trailer bestimmt, was diese Nutzlast ist, und es ist kein TCP-Port, keine Protokollnummer im äußeren Header und kein Teil des anfänglichen SPI- und Sequenznummernfelds. RFC 4303 Abschnitt 2.6 definiert es als Nutzlasttyp-Feld, was ein präziser Name für eine präzise Aufgabe ist.

Die Werte, denen Sie begegnen, sind klein und es lohnt sich, sie zu merken: IPv4 ist 4 (0x04) und IPv6 ist 41 (0x29).

Diese Zahlen stammen aus den Protokollnummern-Zuweisungen der IANA und nicht aus lokaler Konvention. Ein Absender, der IPv4 deklariert und dabei ein IPv6-Paket einschließt, hat eine Formatinkonsistenz erzeugt, und keine Firewall-Regel repariert Bytes, die ihrem eigenen Etikett widersprechen.

Wie man es von den üblichen Verdächtigen unterscheidet

Die meisten fehlenden Pakete sind keine Kodierungsfehler. Prüfen Sie zuerst die Selektoren, denn ein Traffic-Selector, der das IPv6-Präfix ausschließt, verwirft den Verkehr, bevor irgendetwas gekapselt wird. Prüfen Sie dann das Routing und danach die lokale Filterung auf dem empfangenden Host. Erst wenn das ausgeschlossen ist, wird eine Nutzlast-Formatabweichung zu einer plausiblen Erklärung.

Ein verschlüsselter Mitschnitt klärt das nicht, weil der geschützte Next-Header innerhalb der verschlüsselten Nutzlast liegt. Sie brauchen Implementierungsdiagnostik oder einen unterstützten entschlüsselten Beobachtungspunkt, und beides erfordert vor der Nutzung eine Genehmigung.

Wenn niemand diesen Beleg liefern kann, haben Sie keinen Formatfehler. Sie haben eine Theorie, und die Selektoren bleiben die bessere Wette.

Was die Reparatur nicht ist

Schalten Sie keine Integritätsprüfungen ab, damit Verkehr durchkommt. Schreiben Sie verschlüsselte Pakete nicht an einem Zwischenrouter um, denn das kann nicht funktionieren und wird den Fluss beschädigen, während es im Mitschnitt hilfreich aussieht. Öffnen Sie keine breitere Anwendungs-Firewall-Regel auf der Theorie, dass ein Port blockiert wird. Nichts davon berührt die Etikettenabweichung.

Wenn eine bestätigte Abweichung von einer Peer-Implementierung stammt, behalten Sie eine minimale bereinigte Reproduktion und tragen Sie sie an den unterstützten Kanal dieser Implementierung.

Prüfen Sie den Fluss, nicht den Zähler

Testen Sie nach der Korrektur den tatsächlichen IPv6-Fluss von Ende zu Ende: eine Anwendungsanfrage durch den Tunnel, ihre Antwort und das Adresspaar, das jede Seite beobachtet. Ein steigender ESP-Zähler beweist nur, dass Pakete empfangen und authentifiziert werden. Er sagt nichts darüber aus, ob das innere Paket brauchbar war.

Halten Sie beide Ergebnisse im Ticket fest. Zählerbewegung plus ein funktionierender Fluss ist eine Reparatur; Zählerbewegung allein ist genau das, was Sie vor dem Anfang hatten.