O ESP descifra sen problema e o paquete interno segue sen ir a ningures

O contador de recepción de ESP sobe, o túnel segue activo e a aplicación nunca ve o paquete. O descifrado executouse, a verificación de integridade pasou e entón o receptor tivo que decidir que é realmente a carga protexida. É nese último paso onde aparece unha discrepancia de formato, e desde fóra non se parece en nada a un problema de cortalumes.

Que ves cando a etiqueta mente

Nada no rexistro do cliente o distingue dun burato negro de encamiñamento. Ambos producen un tempo de espera da aplicación xunto a un túnel san, e por iso os contadores reciben a culpa primeiro.

Un contador de recepción que sobe é unha boa noticia de verdade: os paquetes chegan e autentícanse. Non é proba de que o paquete interno tivese sentido para algo por riba da capa criptográfica.

O tipo vive no tráiler

No modo túnel IPsec habitual, a carga protexida por ESP contén un paquete IP interno completo. O campo de cabeceira seguinte do tráiler identifica que é esa carga, e non é un porto TCP, nin un número de protocolo na cabeceira externa, nin forma parte do campo inicial de SPI e número de secuencia. RFC 4303 sección 2.6 defíneo como o campo de tipo de carga, que é un nome preciso para un traballo preciso.

Os valores que atoparás son pequenos e paga a pena lembralos: IPv4 é 4 (0x04) e IPv6 é 41 (0x29).

Eses números veñen das asignacións de números de protocolo da IANA, non dunha convención local. Un emisor que declara IPv4 mentres encapsula un paquete IPv6 produciu unha inconsistencia de formato, e ningunha regra de cortalumes repara bytes que contradín a súa propia etiqueta.

Como distinguelo dos sospeitosos habituais

A maioría dos paquetes perdidos non son defectos de codificación. Comproba primeiro os selectores, porque un selector de tráfico que exclúe o prefixo IPv6 descarta o tráfico antes de que nada se encapsule. Despois comproba o encamiñamento e logo o filtrado local no host receptor. Só cando iso queda descartado, unha discrepancia de formato de carga pasa a ser unha explicación plausible.

Unha captura cifrada non o resolverá, porque a cabeceira seguinte protexida está dentro da carga cifrada. Necesitas diagnósticos da implementación ou un punto de observación descifrado admitido, e ambos requiren autorización antes de usarse.

Se ninguén pode achegar esa proba, non tes un fallo de formato. Tes unha teoría, e os selectores seguen sendo a mellor aposta.

Que non é a reparación

Non desactives as comprobacións de integridade para que o tráfico pase. Non reescribas paquetes cifrados nun encamiñador intermedio, porque non pode funcionar e corromperá o fluxo mentres parece útil nunha captura. Non abras unha regra de cortalumes de aplicación máis ampla coa teoría de que se está bloqueando un porto. Nada diso toca a discrepancia de etiqueta.

Se unha discrepancia confirmada procede dunha implementación par, garda unha reprodución mínima e saneada e lévaa á canle admitida desa implementación.

Verifica o fluxo, non o contador

Tras a corrección, proba o fluxo IPv6 real de extremo a extremo: unha petición de aplicación polo túnel, a súa resposta e o par de enderezos que observa cada lado. Un contador ESP que sobe só demostra que os paquetes se reciben e se autentican. Non di nada sobre se o paquete interno era utilizábel.

Anota ambos os resultados no ticket. Movemento do contador máis un fluxo que funciona é unha reparación; movemento do contador por si só é exactamente o que tiñas antes de comezar.