ESP ontsleutelt prima en het binnenste pakket komt nog steeds nergens aan

De ESP-ontvangstteller loopt op, de tunnel blijft overeind en de toepassing ziet het pakket nooit. De ontsleuteling liep, de integriteitscontrole slaagde en toen moest de ontvanger beslissen wat de beschermde payload eigenlijk is. Juist in die laatste stap verschijnt een formaatafwijking, en van buitenaf lijkt dat helemaal niet op een firewallprobleem.

Wat je ziet als het label liegt

Niets in het clientlog onderscheidt dit van een zwart gat in de routering. Beide geven een time-out van de toepassing naast een gezonde tunnel, daarom krijgen de tellers als eerste de schuld.

Een stijgende ontvangstteller is echt goed nieuws: pakketten komen aan en worden geauthenticeerd. Het is geen bewijs dat het binnenste pakket betekenis had voor iets boven de cryptolaag.

Het type woont in de trailer

In de gewone IPsec-tunnelmodus bevat de door ESP beschermde payload een volledig binnenste IP-pakket. Het veld volgende header in de trailer bepaalt wat die payload is, en het is geen TCP-poort, geen protocolnummer in de buitenste header en geen deel van het begin-SPI- en volgnummervveld. RFC 4303 sectie 2.6 definieert het als het payloadtypeveld, wat een precieze naam is voor een precieze taak.

De waarden die je tegenkomt zijn klein en de moeite van het onthouden waard: IPv4 is 4 (0x04) en IPv6 is 41 (0x29).

Die getallen komen uit de protocolnummertoewijzingen van IANA en niet uit lokale conventie. Een afzender die IPv4 verklaart terwijl hij een IPv6-pakket insluit, heeft een formaatinconsistentie gemaakt, en geen firewallregel repareert bytes die hun eigen label tegenspreken.

Hoe je het van de gebruikelijke verdachten onderscheidt

De meeste ontbrekende pakketten zijn geen coderingsfouten. Controleer eerst de selectors, want een verkeersselector die het IPv6-prefix uitsluit, gooit verkeer weg voordat er iets wordt ingekapseld. Controleer dan de routering en daarna lokale filtering op de ontvangende host. Pas als dat is uitgesloten, wordt een formaatafwijking van de payload een plausibele verklaring.

Een versleutelde opname beslecht dit niet, want de beschermde volgende header zit in de versleutelde payload. Je hebt implementatiediagnostiek nodig of een ondersteund ontsleuteld observatiepunt, en beide vereisen toestemming voor gebruik.

Als niemand dat bewijs kan leveren, heb je geen formatbug. Je hebt een theorie, en de selectors blijven de betere gok.

Wat de reparatie niet is

Schakel geen integriteitscontroles uit om verkeer door te laten. Herschrijf geen versleutelde pakketten op een tussenliggende router, want dat kan niet werken en zal de stroom beschadigen terwijl het in een opname behulpzaam lijkt. Open geen bredere applicatiefirewallregel op de theorie dat een poort geblokkeerd wordt. Niets daarvan raakt de labelafwijking.

Als een bevestigde afwijking van een peer-implementatie komt, bewaar dan een minimale opgeschoonde reproductie en breng die naar het ondersteunde kanaal van die implementatie.

Verifieer de stroom, niet de teller

Test na de correctie de werkelijke IPv6-stroom van begin tot eind: een applicatieverzoek door de tunnel, het antwoord daarop en het adrespaar dat elke kant waarneemt. Een stijgende ESP-teller bewijst alleen dat pakketten worden ontvangen en geauthenticeerd. Hij zegt niets over de vraag of het binnenste pakket bruikbaar was.

Noteer beide resultaten in het ticket. Tellerbeweging plus een werkende stroom is een reparatie; tellerbeweging alleen is precies wat je had voordat je begon.