ESP dekrypterer fint, og den indre pakken ender fortsatt ingen steder

ESP-mottakstellieren stiger, tunnelen blir stående, og applikasjonen ser aldri pakken. Dekrypteringen kjørte, integritetskontrollen besto, og så måtte mottakeren avgjøre hva den beskyttede nyttelasten egentlig er. Det er nettopp i dette siste trinnet en formatavvikelse dukker opp, og utenfra ser det slett ikke ut som et brannmurproblem.

Hva du ser når etiketten lyver

Ingenting i klientloggen skiller dette fra et svart hull i rutingen. Begge gir en applikasjonstimeout ved siden av en sunn tunnel, og derfor får tellerne skylden først.

En stigende mottaksteller er virkelig gode nyheter: pakkene ankommer og blir autentisert. Det er ikke bevis for at den indre pakken ga mening for noe over kryptolaget.

Typen bor i traileren

I vanlig IPsec-tunnelmodus inneholder den ESP-beskyttede nyttelasten en fullstendig indre IP-pakke. Trailerens neste-header-felt angir hva denne nyttelasten er, og det er ikke en TCP-port, ikke et protokollnummer i den ytre headeren og ikke en del av det innledende SPI- og sekvensnummerfeltet. RFC 4303 avsnitt 2.6 definerer det som nyttelasttypefeltet, som er et presist navn for en presis oppgave.

Verdiene du møter er små og verdt å huske: IPv4 er 4 (0x04), og IPv6 er 41 (0x29).

Disse tallene kommer fra IANAs tildelinger av protokollnumre og ikke fra lokal konvensjon. En avsender som erklærer IPv4 mens den pakker inn en IPv6-pakke, har skapt en formatinkonsistens, og ingen brannmurregel reparerer bytes som motsier sin egen etikett.

Slik skiller du det fra de vanlige mistenkte

De fleste manglende pakkene er ikke kodingsfeil. Kontroller selektorene først, fordi en trafikkselektor som utelukker IPv6-prefikset, slipper trafikken før noe som helst blir innkapslet. Kontroller deretter ruting og så lokal filtrering på mottakerverten. Først når dette er utelukket, blir en formatavvikelse i nyttelasten en sannsynlig forklaring.

En kryptert opptak vil ikke avgjøre det, fordi den beskyttede neste headeren sitter inne i den krypterte nyttelasten. Du trenger implementasjonsdiagnostikk eller et støttet dekryptert observasjonspunkt, og begge krever tillatelse før bruk.

Hvis ingen kan legge fram det beviset, har du ikke en formatfeil. Du har en teori, og selektorene er fortsatt det bedre veddemålet.

Hva reparasjonen ikke er

Ikke slå av integritetskontroller for å få trafikk gjennom. Ikke skriv om krypterte pakker på en mellomliggende ruter, for det kan ikke virke og vil ødelegge flyten mens det ser nyttig ut i et opptak. Ikke åpne en bredere applikasjonsbrannmurregel på teorien om at en port blokkeres. Ingen av disse berører etikettavvikelsen.

Hvis et bekreftet avvik kommer fra en peer-implementasjon, ta vare på en minimal sanert reproduksjon og bring den til den implementasjonens støttede kanal.

Verifiser flyten, ikke telleren

Etter rettelsen tester du den faktiske IPv6-flyten ende til ende: en applikasjonsforespørsel gjennom tunnelen, svaret på den, og adresseparet hver side observerer. En stigende ESP-teller beviser bare at pakker mottas og autentiseres. Den sier ingenting om hvorvidt den indre pakken var brukbar.

Noter begge resultatene i saken. Tellerbevegelse pluss en fungerende flyt er en rettelse; tellerbevegelse alene er nøyaktig det du hadde før du begynte.