ESP dekrypterer fint, og den indre pakke ender stadig ingen steder

ESP-modtagelsestælleren stiger, tunnelen bliver oppe, og applikationen ser aldrig pakken. Dekrypteringen kørte, integritetskontrollen bestod, og så skulle modtageren afgøre, hvad den beskyttede nyttelast egentlig er. Det er i netop dette sidste trin, at en formatafvigelse dukker op, og udefra ligner det slet ikke et firewallproblem.

Hvad du ser, når etiketten lyver

Intet i klientloggen skelner dette fra et sort hul i routing. Begge giver en applikationstimeout ved siden af en sund tunnel, og derfor får tællerne skylden først.

En stigende modtagelsestæller er virkelig gode nyheder: pakkerne ankommer og bliver autentificeret. Det er ikke bevis for, at den indre pakke gav mening for noget oven over kryptolaget.

Typen bor i traileren

I almindelig IPsec-tunnelmode indeholder den ESP-beskyttede nyttelast en komplet indre IP-pakke. Trailerens felt for næste header angiver, hvad denne nyttelast er, og det er ikke en TCP-port, ikke et protokolnnummer i den ydre header og ikke en del af det indledende SPI- og sekvensnummerfelt. RFC 4303 afsnit 2.6 definerer det som nyttelasttypefeltet, hvilket er et præcist navn til en præcis opgave.

De værdier, du møder, er små og værd at huske: IPv4 er 4 (0x04), og IPv6 er 41 (0x29).

Disse tal kommer fra IANAs tildelinger af protokolnnumre og ikke fra lokal konvention. En afsender, der erklærer IPv4, mens den indkapsler en IPv6-pakke, har skabt en formatinkonsistens, og ingen firewallregel reparerer bytes, der modsiger deres egen etiket.

Sådan skelner du det fra de sædvanlige mistænkte

De fleste manglende pakker er ikke kodningsfejl. Kontrollér selektorerne først, fordi en trafikselektor, der udelukker IPv6-præfikset, dropper trafikken, før noget som helst bliver indkapslet. Kontrollér derefter routing og så lokal filtrering på modtagerhosten. Først når disse er udelukket, bliver en formatafvigelse i nyttelasten en sandsynlig forklaring.

En krypteret optagelse afgør det ikke, fordi den beskyttede næste header sidder inde i den krypterede nyttelast. Du har brug for implementeringsdiagnostik eller et understøttet dekrypteret observationspunkt, og begge kræver tilladelse før brug.

Hvis ingen kan fremlægge det bevis, har du ikke en formatfejl. Du har en teori, og selektorerne er stadig det bedre bud.

Hvad reparationen ikke er

Deaktiver ikke integritetskontroller for at få trafik igennem. Omskriv ikke krypterede pakker på en mellemliggende router, for det kan ikke virke og vil ødelægge flowet, mens det ser hjælpsomt ud i en optagelse. Åbn ikke en bredere applikationsfirewallregel på den teori, at en port blokeres. Intet af det rører ved etiketafvigelsen.

Hvis en bekræftet afvigelse kommer fra en peer-implementering, så gem en minimal saniteret reproduktion, og tag den til den pågældende implementerings understøttede kanal.

Verificér flowet, ikke tælleren

Efter rettelsen skal du teste det faktiske IPv6-flow ende til ende: en applikationsanmodning gennem tunnelen, dens svar og det adressepar, hver side observerer. En stigende ESP-tæller beviser kun, at pakker modtages og autentificeres. Den siger intet om, hvorvidt den indre pakke var brugbar.

Notér begge resultater i sagen. Tællerbevægelse plus et fungerende flow er en rettelse; tællerbevægelse alene er præcis, hvad du havde, før du begyndte.