Distinguir a fragmentação do IKEv2 de um problema de cadeia de certificados

O túnel funcionava na rede do escritório e trava em casa, e o registro mostra a primeira troca concluída antes de qualquer outra coisa acontecer. Esse padrão aponta para a troca de autenticação, não para as credenciais: uma cadeia de certificados torna essa mensagem muito maior que a anterior, e um caminho que não gosta de datagramas grandes a descarta silenciosamente. Há dois mecanismos de fragmentação diferentes envolvidos, e saber qual está a observar decide a correção.

Dois mecanismos de fragmentação, um sintoma

O IKEv2 tem a sua própria extensão de fragmentação, definida na RFC 7383, que divide as mensagens IKE protegidas em mensagens IKE menores. Os pares negociam essa capacidade, e a mensagem é remontada pela implementação do IKE e não pela camada IP.

A fragmentação IP comum é um mecanismo diferente com um modo de falha diferente. Um router entre os pares fragmenta um datagrama grande, ou descarta-o e devolve uma mensagem ICMP que pode nunca chegar ao emissor. Algumas redes descartam fragmentos em silêncio, e alguns dispositivos intermédios tratam o primeiro fragmento mas não o resto. Do ponto de vista da aplicação, os três casos parecem idênticos.

A travessia de NAT acrescenta uma terceira variável, porque o ESP é então envolvido em UDP e o pacote exterior fica maior, embora pareça tráfego UDP comum na porta 4500. Um caminho que deixa passar bem o UDP ainda pode falhar num datagrama que já não cabe.

Leia a troca que falhou

Procure a transição, não o erro. Um registo que mostra a troca inicial enviada e respondida, seguida de nada, diz-lhe que a mensagem seguinte nunca foi concluída. Aumente temporariamente o nível do registo e compare os tamanhos reportados nos dois pares.

O que quer estabelecer é se o respondedor viu o pedido. Se o iniciador enviou algo e o respondedor não tem qualquer registo disso, o problema é a entrega. Se o respondedor analisou um pedido e o rejeitou, o problema é o próprio certificado, e a fragmentação é uma distração. Essa distinção vale mais do que uma página de mensagens de tempo limite.

Mude o caminho, não o certificado

Teste o mesmo cliente, o mesmo certificado e a mesma configuração a partir de outra rede. Um hotspot móvel é normalmente o segundo caminho mais barato, e é genuinamente diferente do link do escritório, não apenas nominalmente.

Se o handshake se completar no segundo caminho, a cadeia de certificados está bem e o primeiro caminho é a variável. Se falhar de forma idêntica nos dois, pare de testar redes e olhe para as mensagens em si. Essa única comparação elimina cerca de metade das explicações possíveis.

Meça a troca antes de editar o que quer que seja

Obtenha o tamanho da cadeia e o tamanho do caminho. Ambos os números limitam o que o handshake pode enviar, e ambos são baratos de medir:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

Os dois primeiros dão o número de certificados e o tamanho do ficheiro, o que é um indicador razoável de quão grande será a mensagem de autenticação. A sonda ping indica se um datagrama desse tamanho sobrevive ao caminho, e os contadores da interface mostram se os fragmentos foram descartados do seu lado. No Windows, a sonda equivalente é um ping com o sinalizador do-not-fragment e um tamanho de carga útil explícito.

Repita a sonda para baixo até ter sucesso. O maior tamanho que passa é o orçamento de trabalho para esse caminho, e é mais útil do que qualquer predefinição publicada.

Corrija a camada que está realmente avariada

Se o caminho descarta datagramas grandes, ative a fragmentação IKE nos dois pares e confirme que a extensão foi negociada, e não apenas oferecida. Se o caminho trata mal os fragmentos ao nível de IP, a correção pertence ali ou ao MTU da interface exterior, não ao armazenamento de certificados.

Se a cadeia é desnecessariamente longa, corte-a até aos certificados intermédios de que um par realmente precisa. Remover uma raiz em que o cliente já confia é manutenção razoável; remover um intermédio já não é, e desativar a verificação para reduzir uma mensagem troca um problema de entrega por um de segurança.

Anote que mecanismo mudou e como estava o handshake depois. A ocorrência seguinte é normalmente noutra rede com o mesmo sintoma, e a nota é o que transforma duas horas em dez minutos.