ESP dekripteer foutloos en die binne-pakket gaan steeds nêrens heen

Die ESP-ontvangteller styg, die tonnel bly op, en die toepassing sien nooit die pakket nie. Dekripsie het geloop, integriteitsverifikasie het geslaag, en toe moes die ontvanger besluit wat die beskermde loonvrag werklik is. Dit is juis by daardie laaste stap waar 'n formaatwanpassing opduik, en van buite lyk dit niks soos 'n vuurmuurprobleem nie.

Wat jy sien wanneer die etiket lieg

Niks in die kliëntlog onderskei dit van 'n swartgat in die roetering nie. Albei lewer 'n toepassing-tydsverloop langs 'n gesonde tonnel, en daarom kry die tellers eerste die skuld.

'n Stygende ontvangteller is werklik goeie nuus: pakkette kom aan en verifieer. Dit is nie bewys dat die binne-pakket sin gemaak het vir enigiets bokant die kriptolaag nie.

Die tipe woon in die trailer

In gewone IPsec-tonnelmodus bevat die ESP-beskermde loonvrag 'n volledige binne-IP-pakket. Die trailer se Volgende Kop-veld dui aan wat daardie loonvrag is, en dit is nie 'n TCP-poort nie, nie 'n protokolnommer in die buitenste kop nie, en nie deel van die aanvanklike SPI- en volgnommerveld nie. RFC 4303 afdeling 2.6 definieer dit as die loonvragtipe-veld, wat 'n presiese naam vir 'n presiese taak is.

Die waardes wat jy sal teëkom, is klein en die moeite werd om te onthou: IPv4 is 4 (0x04) en IPv6 is 41 (0x29).

Daardie nommers kom uit die IANA se protokolnommertoewysings, nie uit plaaslike konvensie nie. 'n Stuurder wat IPv4 verklaar terwyl hy 'n IPv6-pakket insluit, het 'n formaatteenstrydigheid geskep, en geen vuurmuurreël herstel grepe wat hul eie etiket weerspreek nie.

Hoe om dit van die gewone verdagtes te onderskei

Die meeste vermiste pakkette is nie enkoderingsfoute nie. Kontroleer eers die selektors, want 'n verkeerselektor wat die IPv6-voorvoegsel uitsluit, laat verkeer val voordat enigiets ingekapsel word. Kontroleer dan roetering, dan plaaslike filtering op die ontvangende gasheer. Eers nadat dit uitgesluit is, word 'n loonvragformaat-wanpassing 'n geloofwaardige verklaring.

'n Geënkripteerde opname sal dit nie beslis nie, want die beskermde Volgende Kop sit binne die geënkripteerde loonvrag. Jy het implementeringsdiagnostiek of 'n ondersteunde gedekripteerde waarnemingspunt nodig, en albei vereis magtiging voor gebruik.

As niemand daardie bewyse kan lewer nie, het jy nie 'n formaatfout nie. Jy het 'n teorie, en die selektors bly die beter weddenskap.

Wat die herstel nie is nie

Moenie integriteitskontroles afskakel om verkeer deur te laat nie. Moenie geënkripteerde pakkette by 'n tussenroeteerder herskryf nie, want dit kan nie werk nie en sal die vloei korrupteer terwyl dit in 'n opname nuttig lyk. Moenie 'n wyer toepassing-vuurmuurreël oopmaak op die teorie dat 'n poort geblokkeer word nie. Nie een van dié raak die etiketwanpassing nie.

As 'n bevestigde wanpassing van 'n eweknie-implementering kom, hou 'n minimale gesensureerde reproduksie en neem dit na daardie implementering se ondersteunde kanaal.

Verifieer die vloei, nie die teller nie

Ná die regstelling toets jy die werklike IPv6-vloei van begin tot eind: 'n toepassingversoek deur die tonnel, die antwoord daarop, en die adrespaar wat elke kant waarneem. 'n Stygende ESP-teller bewys net dat pakkette ontvang en verifieer word. Dit sê niks oor of die binne-pakket bruikbaar was nie.

Teken albei resultate in die kaartjie aan. Tellerbeweging plus 'n werkende vloei is 'n regstelling; tellerbeweging alleen is presies wat jy gehad het voordat jy begin het.