ESP é o protocolo IP 50, não a porta TCP 50: o que permitir
Números de protocolo e números de porta são espaços de nomes diferentes. Uma regra para a porta TCP 50 não permite nada, e o NAT traversal move o ESP para UDP 4500.
Os formulários de firewall pedem uma porta TCP, e a entrada óbvia é 50. Essa entrada não permite nada, porque ESP é o protocolo IP número 50 e números de protocolo não são portas. Os dois espaços de nomes compartilham inteiros pequenos e nada mais, e o erro fica invisível até o IKE terminar e o tráfego protegido nunca chegar.
Dois espaços de nomes que compartilham números pequenos
Um cabeçalho IP carrega um campo de protocolo que nomeia o que vem a seguir: 6 para TCP, 17 para UDP, 1 para ICMP, 50 para ESP, 51 para AH. Um cabeçalho TCP ou UDP carrega números de porta, que selecionam um processo no host de destino. O protocolo 50 e a porta TCP 50 são valores sem relação, mas uma caixa de diálogo pode fazê-los parecer intercambiáveis.
Por isso uma regra de encaminhamento de portas não consegue expressar ESP nativo. Não existe uma porta de destino ESP para encaminhar, e um dispositivo que só entende regras de porta não tem vocabulário nenhum para esse pacote. A regra correta nomeia o protocolo IP. Qualquer diálogo de portas é o instrumento errado para esse pacote.
A confusão tem uma segunda metade. Quando o pacote está cifrado, tudo dentro dele é opaco, incluindo o cabeçalho TCP da conexão original. Um firewall que inspeciona portas nesse pacote está olhando o cabeçalho externo, que no caso nativo não tem portas a inspecionar.
ESP nativo, depois a alternativa encapsulada
O ESP nativo é transportado diretamente como protocolo IP, o que é eficiente e incômodo em igual medida. É eficiente porque não há cabeçalho extra, e incômodo porque nenhum dispositivo que traduza endereços e portas consegue acompanhá-lo. O NAT traversal existe para resolver isso, envolvendo o pacote ESP dentro de UDP para que o tradutor tenha portas a reescrever.
| Form on the wire | How it is identified | What the firewall must permit |
|---|---|---|
| IKE negotiation | UDP with a destination port | UDP 500, and 4500 once traversal is detected |
| Native ESP | IP protocol 50 in the outer header | The protocol itself, with no port to name |
| ESP inside UDP | UDP 4500 carrying an ESP payload | The UDP port pair, which translation devices can track |
As duas formas são implantações alternativas do mesmo canal de dados, não camadas de um. Permitir ESP nativo não permite a forma encapsulada, e permitir UDP 4500 não permite o tráfego nativo, então um conjunto de regras deve corresponder à implantação em vez de cobrir os dois por acidente.
A detecção também importa aqui. Os extremos decidem entre as formas durante a negociação, e a troca costuma ocorrer quando um NAT é detectado entre eles. Por isso um caminho que muda depois de estabelecido o túnel pode mover o tráfego para um espaço de nomes que suas regras nunca cobriram.
Leia qual forma a conexão realmente usa
Pergunte ao extremo em vez de adivinhar pelo firewall. No Linux a entrada de estado informa se a associação usa encapsulamento UDP e quais portas estão envolvidas. Uma captura responde à mesma pergunta pelo cabo, e ambas são mais rápidas do que ler um conjunto de regras e esperar.
ip xfrm state | grep -A3 encap
tcpdump -ni any 'ip proto 50 or udp port 4500'O primeiro comando mostra um tipo de encapsulamento quando o NAT traversal está em uso e nada quando não está. O segundo mostra qual das duas formas realmente atravessa a interface, e isso encerra discussões sobre uma configuração que parece correta no papel.
A contraprova pertence ao mesmo passo. Uma regra que relata zero correspondências diz a você que o pacote nunca a alcançou, e isso é uma questão de roteamento ou de seletor, não de firewall.
Em seguida confirme o canal de controle separadamente. O IKE tem suas próprias portas e seus próprios registros, e uma negociação concluída sem dados é exatamente a separação da qual trata este artigo.
Escreva a regra no espaço de nomes correto
Uma regra de protocolo e uma regra de porta são instruções diferentes, então a ferramenta precisa expressar a que você quer dizer. No nftables a correspondência de protocolo é explícita, e a alternativa encapsulada recebe sua própria regra UDP. Mantenha as duas regras adjacentes para que o par fique visível na revisão.
nft add rule inet filter input ip protocol esp accept
nft add rule inet filter input udp dport { 500, 4500 } acceptNão amplie nenhuma das regras para compensar um diagnóstico errado. Um permitir tudo para o protocolo ESP em todas as interfaces, ou uma permissão UDP de qualquer lugar para qualquer lugar, corrige um sintoma e remove o controle que você tentava configurar. O fluxo estreito suportado quase sempre basta uma vez conhecida a forma.
Por fim, mantenha as camadas claras quando o túnel funciona e a aplicação não. Os pacotes que chegam ao gateway ainda precisam de encaminhamento, de uma rota de retorno e de uma política que os admita, e nada disso é expresso por uma regra ESP. A porta que falta explica uma falha específica, não todas as falhas de IPsec. Mantenha a correção da regra e a verificação de roteamento como duas conclusões separadas.
Anote a forma que você observou, a regra de protocolo que adicionou e o contador que viu depois. Três linhas, e a próxima pessoa consegue distinguir um erro de espaço de nomes de um erro de roteamento em um minuto em vez de uma tarde.