O ESP descriptografa bem e o pacote interno continua sem ir a lugar nenhum

O contador de receção ESP sobe, o túnel mantém-se ativo e a aplicação nunca vê o pacote. A desencriptação correu, a verificação de integridade passou e depois o recetor teve de decidir o que é realmente a carga protegida. É nesse último passo que aparece uma discrepância de formato, e visto de fora não se parece nada com um problema de firewall.

O que vê quando o rótulo mente

Nada no registo do cliente distingue isto de um buraco negro de encaminhamento. Ambos produzem um tempo limite da aplicação ao lado de um túnel saudável, e é por isso que os contadores são os primeiros a levar a culpa.

Um contador de receção a subir é mesmo boa notícia: os pacotes chegam e são autenticados. Não é prova de que o pacote interno fizesse sentido para algo acima da camada criptográfica.

O tipo vive no trailer

No modo túnel IPsec comum, a carga protegida por ESP contém um pacote IP interno completo. O campo de cabeçalho seguinte no trailer identifica o que é essa carga, e não é uma porta TCP, nem um número de protocolo no cabeçalho externo, nem faz parte do campo inicial de SPI e número de sequência. RFC 4303 secção 2.6 define-o como o campo de tipo de carga, que é um nome preciso para uma tarefa precisa.

Os valores que vai encontrar são pequenos e vale a pena memorizá-los: IPv4 é 4 (0x04) e IPv6 é 41 (0x29).

Esses números vêm das atribuições de números de protocolo da IANA e não de uma convenção local. Um emissor que declara IPv4 enquanto encapsula um pacote IPv6 produziu uma inconsistência de formato, e nenhuma regra de firewall repara bytes que contradizem o próprio rótulo.

Como distingui-lo dos suspeitos do costume

A maioria dos pacotes em falta não são defeitos de codificação. Verifique primeiro os seletores, porque um seletor de tráfego que exclui o prefixo IPv6 descarta o tráfego antes de qualquer coisa ser encapsulada. Depois verifique o encaminhamento e, em seguida, a filtragem local no anfitrião recetor. Só depois de isso estar excluído é que uma discrepância de formato da carga se torna uma explicação plausível.

Uma captura cifrada não resolverá a questão, porque o cabeçalho seguinte protegido está dentro da carga cifrada. Precisa de diagnósticos da implementação ou de um ponto de observação desencriptado suportado, e ambos exigem autorização antes do uso.

Se ninguém conseguir produzir essa prova, não tem um erro de formato. Tem uma teoria, e os seletores continuam a ser a melhor aposta.

O que a reparação não é

Não desative as verificações de integridade para o tráfego passar. Não reescreva pacotes cifrados num router intermédio, porque isso não pode funcionar e vai corromper o fluxo enquanto parece útil numa captura. Não abra uma regra de firewall de aplicação mais ampla com a teoria de que uma porta está bloqueada. Nada disso toca na discrepância de rótulo.

Se uma discrepância confirmada vier de uma implementação par, guarde uma reprodução mínima e higienizada e leve-a ao canal suportado dessa implementação.

Verifique o fluxo, não o contador

Depois da correção, teste o fluxo IPv6 real de ponta a ponta: um pedido da aplicação através do túnel, a resposta e o par de endereços que cada lado observa. Um contador ESP a subir apenas prova que os pacotes estão a ser recebidos e autenticados. Não diz nada sobre se o pacote interno era utilizável.

Registe os dois resultados no ticket. Movimento do contador mais um fluxo a funcionar é uma reparação; movimento do contador sozinho é exatamente o que tinha antes de começar.