L'ESP desxifra bé i el paquet intern segueix sense anar enlloc

El comptador de recepció ESP augmenta, el túnel es manté engegat i l'aplicació no arriba a veure mai el paquet. El desxifratge s'ha executat, la verificació d'integritat ha passat i llavors el receptor havia de decidir què és realment la càrrega protegida. És en aquest darrer pas on apareix una discrepància de format, i des de fora no s'assembla gens a un problema de tallafocs.

Què veus quan l'etiqueta menteix

Res del registre del client no ho distingeix d'un forat negre d'encaminament. Tots dos produeixen un temps d'espera de l'aplicació al costat d'un túnel saludable, i per això els comptadors són els primers a rebre la culpa.

Un comptador de recepció que puja és una bona notícia de debò: els paquets arriben i se n'autentica l'origen. No és prova que el paquet intern tingués sentit per a res per sobre de la capa criptogràfica.

El tipus viu al tràiler

En el mode túnel IPsec habitual, la càrrega protegida per ESP conté un paquet IP intern complet. El camp de capçalera següent del tràiler identifica què és aquesta càrrega, i no és cap port TCP, ni un número de protocol de la capçalera externa, ni forma part del camp inicial SPI i de número de seqüència. RFC 4303 secció 2.6 el defineix com a camp de tipus de càrrega, que és un nom precís per a una feina precisa.

Els valors que trobaràs són petits i val la pena recordar-los: IPv4 és 4 (0x04) i IPv6 és 41 (0x29).

Aquests números venen de les assignacions de números de protocol de l'IANA, no de cap convenció local. Un emissor que declara IPv4 mentre encapsula un paquet IPv6 ha produït una inconsistència de format, i cap regla de tallafocs arregla uns bytes que contradiuen la seva pròpia etiqueta.

Com distingir-ho dels sospitosos habituals

La majoria de paquets que falten no són defectes de codificació. Comprova primer els selectors, perquè un selector de trànsit que exclou el prefix IPv6 descarta el trànsit abans que res no s'encapsuli. Després comprova l'encaminament i, tot seguit, el filtratge local a l'amfitrió receptor. Només quan això queda descartat, una discrepància de format de càrrega esdevé una explicació plausible.

Una captura xifrada no ho resoldrà, perquè la capçalera següent protegida és dins de la càrrega xifrada. Calen diagnòstics de la implementació o un punt d'observació desxifrat suportat, i tots dos requereixen autorització abans de fer-los servir.

Si ningú no pot aportar aquesta evidència, no tens un error de format. Tens una teoria, i els selectors continuen sent la millor aposta.

Què no és la reparació

No desactivis les comprovacions d'integritat perquè el trànsit passi. No reescriguis paquets xifrats en un encaminador intermedi, perquè no pot funcionar i corromprà el flux mentre sembla útil en una captura. No obris una regla de tallafocs d'aplicació més àmplia amb la teoria que un port està bloquejat. Cap d'aquestes coses no toca la discrepància d'etiqueta.

Si una discrepància confirmada ve d'una implementació igual, conserva'n una reproducció mínima i saneja i porta-la al canal de suport d'aquella implementació.

Verifica el flux, no el comptador

Després de la correcció, prova el flux IPv6 real d'un extrem a l'altre: una petició d'aplicació a través del túnel, la seva resposta i el parell d'adreces que observa cada costat. Un comptador ESP que puja només demostra que els paquets s'estan rebent i autenticant. No diu res sobre si el paquet intern era utilitzable.

Anota tots dos resultats al tiquet. Moviment del comptador més un flux que funciona és una correcció; moviment del comptador tot sol és exactament el que tenies abans de començar.