ESP dekrypterer fint, og den indre pakken hamnar framleis ingen stad

ESP-mottaksteljaren stig, tunnelen blir ståande, og applikasjonen ser aldri pakken. Dekrypteringa køyrde, integritetskontrollen gjekk gjennom, og så måtte mottakaren avgjere kva den verna nyttelasta eigentleg er. Det er nettopp i dette siste steget ein formatavvik kjem fram, og utanfrå ser det slett ikkje ut som eit brannmurproblem.

Kva du ser når etiketten lyg

Ingenting i klientloggen skil dette frå eit svart hol i rutinga. Begge gir ein applikasjonstimeout ved sida av ein sunn tunnel, og difor får teljarane skulda fyrst.

Ein stigande mottaksteljar er verkeleg gode nyhende: pakkane kjem inn og blir autentiserte. Det er ikkje prov på at den indre pakken gav meining for noko over kryptolaget.

Typen bur i traileren

I vanleg IPsec-tunnelmodus inneheld den ESP-verna nyttelasta ein fullstendig indre IP-pakke. Feltet for neste header i traileren seier kva denne nyttelasta er, og det er ikkje ein TCP-port, ikkje eit protokollnummer i den ytre headeren og ikkje ein del av det innleiande SPI- og sekvensnummerfeltet. RFC 4303 avsnitt 2.6 definerer det som nyttelasttypefeltet, som er eit presist namn for ei presis oppgåve.

Verdiane du møter er små og verd å hugse: IPv4 er 4 (0x04), og IPv6 er 41 (0x29).

Desse tala kjem frå IANA sine tildelingar av protokollnummer og ikkje frå lokal konvensjon. Ein avsendar som erklærer IPv4 medan han pakkar inn ein IPv6-pakke, har skapt ein formatinkonsistens, og inga brannmurregel reparerer byte som seier imot sin eigen etikett.

Slik skil du det frå dei vanlege mistenkte

Dei fleste manglande pakkane er ikkje kodingsfeil. Kontroller selektorane fyrst, fordi ein trafikkselektor som stengjer ute IPv6-prefikset, kastar trafikken før noko som helst blir innkapsla. Kontroller deretter ruting og så lokal filtrering på mottakarverten. Fyrst når dette er utelukka, blir eit formatavvik i nyttelasta ei truleg forklaring.

Eit kryptert opptak avgjer ikkje dette, fordi den verna neste headeren sit inne i den krypterte nyttelasta. Du treng implementasjonsdiagnostikk eller eit støtta dekryptert observasjonspunkt, og begge krev løyve før bruk.

Om ingen kan leggje fram det provet, har du ikkje ein formatfeil. Du har ein teori, og selektorane er framleis det betre veddemålet.

Kva reparasjonen ikkje er

Ikkje slå av integritetskontrollar for å få trafikk gjennom. Ikkje skriv om krypterte pakkar på ein mellomliggjande ruter, for det kan ikkje verke og vil øydeleggje flyten medan det ser nyttig ut i eit opptak. Ikkje opne ein breiare applikasjonsbrannmurregel på teorien om at ein port blir blokkert. Ingen av desse rører etikettavviket.

Om eit stadfesta avvik kjem frå ein peer-implementasjon, ta vare på ein minimal sanert reproduksjon og bring han til den støtta kanalen til den implementasjonen.

Verifiser flyten, ikkje teljaren

Etter rettinga testar du den faktiske IPv6-flyten ende til ende: ein applikasjonsførespurnad gjennom tunnelen, svaret på han, og adresseparet kvar side observerer. Ein stigande ESP-teljar beviser berre at pakkar blir tekne imot og autentiserte. Han seier ingenting om den indre pakken var brukande.

Noter begge resultata i saka. Teljarrørsle pluss ein fungerande flyt er ei retting; teljarrørsle åleine er nøyaktig det du hadde før du byrja.