ESP dekrypterar fint och det inre paketet hamnar fortfarande ingenstans

ESP:s mottagningsräknare stiger, tunneln står kvar och applikationen ser aldrig paketet. Dekrypteringen kördes, integritetskontrollen gick igenom och sedan måste mottagaren avgöra vad den skyddade nyttolasten egentligen är. Det är just i detta sista steg som en formatavvikelse dyker upp, och utifrån ser det inte alls ut som ett brandväggsproblem.

Vad du ser när etiketten ljuger

Inget i klientloggen skiljer detta från ett svart hål i routingen. Båda ger en applikationstimeout bredvid en frisk tunnel, och därför får räknarna skulden först.

En stigande mottagningsräknare är verkligen goda nyheter: paketen anländer och autentiseras. Det är inte bevis för att det inre paketet gav mening för något ovanför kryptolagret.

Typen bor i trailern

I vanligt IPsec-tunnelläge innehåller den ESP-skyddade nyttolasten ett komplett inre IP-paket. Trailerns nästa-header-fält anger vad denna nyttolast är, och det är inte en TCP-port, inte ett protokollnummer i det yttre huvudet och inte en del av det inledande SPI- och sekvensnummerfältet. RFC 4303 avsnitt 2.6 definierar det som nyttolasttypfältet, vilket är ett exakt namn för en exakt uppgift.

Värdena du möter är små och värda att komma ihåg: IPv4 är 4 (0x04) och IPv6 är 41 (0x29).

De siffrorna kommer från IANA:s tilldelningar av protokollnummer och inte från lokal konvention. En avsändare som deklarerar IPv4 medan den bäddar in ett IPv6-paket har skapat en formatinkonsekvens, och ingen brandväggsregel reparerar byte som motsäger sin egen etikett.

Så skiljer du det från de vanliga misstänkta

De flesta saknade paket är inte kodningsfel. Kontrollera väljarna först, eftersom en trafikväljare som utesluter IPv6-prefixet kastar trafiken innan något alls kapslas in. Kontrollera sedan routingen och därefter lokal filtrering på mottagarvärden. Först när det är uteslutet blir en formatavvikelse i nyttolasten en trolig förklaring.

En krypterad avlyssning avgör inte saken, eftersom den skyddade nästa headern sitter inne i den krypterade nyttolasten. Du behöver implementeringsdiagnostik eller en stödd dekrypterad observationspunkt, och båda kräver tillstånd före användning.

Om ingen kan lägga fram det beviset har du ingen formatbugg. Du har en teori, och väljarna är fortfarande det bättre vadet.

Vad reparationen inte är

Stäng inte av integritetskontrollerna för att få trafik igenom. Skriv inte om krypterade paket på en mellanliggande router, för det kan inte fungera och kommer att förstöra flödet medan det ser hjälpsamt ut i en avlyssning. Öppna inte en bredare applikationsbrandväggsregel på teorin att en port blockeras. Inget av det rör etikettavvikelsen.

Om en bekräftad avvikelse kommer från en peer-implementering, behåll en minimal sanerad reproduktion och ta den till den implementeringens stödda kanal.

Verifiera flödet, inte räknaren

Efter rättelsen testar du det faktiska IPv6-flödet från början till slut: en applikationsbegäran genom tunneln, dess svar och det adresspar som varje sida observerar. En stigande ESP-räknare bevisar bara att paket tas emot och autentiseras. Den säger inget om det inre paketet var användbart.

Anteckna båda resultaten i ärendet. Räknarrörelse plus ett fungerande flöde är en reparation; räknarrörelse ensam är exakt vad du hade innan du började.