Como o traversal NAT encapsula o ESP dentro do UDP
O ESP não tem portas, por isso o traversal NAT o encapsula em UDP na 4500. Verifique a troca de controle e o caminho de dados encapsulado como duas etapas separadas.
Dois clientes atrás do mesmo router falam com um único gateway IPsec, e um cai repetidamente enquanto o outro permanece ligado. O ESP nativo é o protocolo IP 50 sem portas, então um tradutor não tem onde ancorar um mapeamento quando vários clientes compartilham um endereço. O traversal NAT fecha essa lacuna ao encapsular o ESP em UDP na 4500, e esse cabeçalho explica a maioria dos sintomas que se seguem. Também aponta o dispositivo que precisa ser alterado.
Por que o plano de dados passa para a porta 4500
Durante a configuração, o IKEv2 compara os endereços e as portas que cada lado acredita usar, trocando hashes nas suas notificações de detecção de NAT. Quando os hashes não coincidem, há um tradutor em algum ponto do caminho, e os dois pares mudam o tráfego protegido para encapsulamento UDP. Por isso uma sessão que encontrou um tradutor parece diferente de uma que não encontrou.
O invólucro é um envelope, não uma mudança de protocolo: O ESP mantém o seu cabeçalho, a verificação de integridade e a cifragem, e o UDP fornece apenas as portas de que o tradutor precisa. A porta 500 transporta a troca IKE; a 4500 transporta os dados encapsulados após a detecção, e muitas vezes também as mensagens IKE posteriores. Nenhuma das portas transforma o fluxo numa conexão TCP, uma suposição que engana a maioria das pessoas que lê uma captura.
Verifique as duas etapas por ordem
Prove primeiro a troca de controle, depois o caminho de dados, e mantenha os dois separados nas suas notas. Uma captura que mostra tráfego na 500 e nunca na 4500 costuma significar que o caminho de dados está filtrado, por isso a correção pertence à regra da firewall e não ao cliente.
Observe as duas portas com tcpdump -ni any 'udp port 500 or udp port 4500', e leia a tabela de tradução no router enquanto a sessão está ativa. Essa tabela mostra a porta de origem que o gateway vai ver realmente, e uma captura no portátil diverge por conceção: o portátil acredita em 500 enquanto o gateway vê 4500 com uma porta de origem traduzida, e ambos estão corretos. O mesmo fluxo, antes e depois da tradução:
client 192.0.2.10:500 -> router 203.0.113.7:62000 -> gateway 198.51.100.9:4500
Sintomas que o invólucro explica, e dois que não
Um router que permite a troca de controle e bloqueia os dados encapsulados produz o relatório de que o túnel está em cima mas nada passa. As tabelas de mapeamento expiram, por isso uma sessão inativa precisa de tráfego de manutenção que os pares enviam de propósito, e esses pacotes não são verificações de saúde. Quando vários clientes atrás de um gateway falham ao mesmo tempo, examine a tradução desse gateway e qualquer função antiga de passagem direta. O invólucro não explica uma aplicação que falha em todos os clientes depois de o túnel subir, nem um aviso de certificado numa página de bloqueio; ambos ficam acima desta camada.
Leia a tabela de mapeamento para dois clientes ao mesmo tempo: se ambos mostram a mesma porta traduzida, o dispositivo não os separa como o gateway exige. Um modo de passagem direta que entrega o ESP nativo a um único host não equivale a servir vários clientes traduzidos, embora os fornecedores descrevam ambos como compatíveis com IPsec. O NAT duplo acrescenta uma camada de mapeamento e outro ponto de expiração, mas não quebra automaticamente as ligações de saída.
O tráfego de manutenção merece a sua própria linha no manual de operações, porque é o que mantém aberto o caminho de resposta durante os períodos de inatividade. Ative-o onde o fornecedor o documenta, e verifique-o primeiro quando uma sessão morre após alguns minutos de silêncio em vez de no primeiro uso.
Mude o proprietário do mapeamento, e depois teste novamente
Siga as definições de traversal NAT suportadas nos dois pares em vez de adivinhar uma porta. Editar a porta de origem local num cliente não pode mudar o serviço que escuta no outro extremo, e normalmente quebra o mapeamento já construído. Se o cliente estiver atrás de um dispositivo que não controla, a alteração pertence ao proprietário dele.
Após qualquer alteração, repita as duas verificações de etapa e confirme que um pacote de dados atravessa, não apenas que o ecrã de estado ficou verde. Guarde as tuplas, a saída da tabela de mapeamento e a alteração da regra numa única nota, para que a pessoa seguinte não recomece a partir da troca de controle. As notas do strongSwan sobre o traversal NAT cobrem as definições de encapsulamento e de manutenção por trás das duas etapas.