IKEv2 usa UDP 500 e 4500: qual deles transporta os dados?

Abrir a UDP 500 na firewall permite que o túnel negoceie, e depois a ligação deixa de passar tráfego. A lista de portas estava incompleta, não errada. O IKEv2 começa num socket e, em muitas implementações reais, continua noutro, enquanto a carga útil pode não ser porta nenhuma. Ler as fases por ordem explica qual regra falta.

Duas portas, duas funções

O IKEv2 começa com uma troca de chaves na UDP 500, onde os pares se autenticam e estabelecem uma associação de segurança para o túnel. O caminho de dados que se segue é outra questão: pode ser ESP nativo, que é um número de protocolo IP e não uma porta, ou tráfego encapsulado em UDP na 4500. Manter isto separado numa revisão da firewall é a diferença entre um túnel que negoceia e um túnel que funciona. Um socket leva o controlo e o outro a carga útil.

Por isso uma regra que só permite 500 produz o sintoma mais confuso de toda a família de protocolos: a negociação tem sucesso e nada de útil se segue. O estado mostra um par, o registo mostra uma IKE SA estabelecida e a aplicação continua a expirar. A permissão em falta pertence a um fluxo diferente do que acabou de funcionar.

Porque é que a 4500 existe

Muitos dispositivos NAT não conseguem encaminhar outro protocolo que não seja TCP ou UDP, e alguns reescrevem endereços de formas que quebram a verificação de integridade do ESP. Encapsular o ESP em UDP resolve ambos os problemas, ao custo de um cabeçalho extra e de uma segunda porta a permitir. É esse encapsulamento que justifica a existência da segunda porta.

Assim que o NAT é detetado, o próprio IKE passa para a 4500 para que todo o tráfego partilhe um único caminho através do tradutor. Um marcador de quatro bytes que não é ESP distingue as mensagens de controlo dos dados nesse socket. A mudança é uma decisão do protocolo, não uma preferência do administrador.

Onde a porta de origem muda

Um tradutor pode reescrever a porta de origem do cliente, pelo que o tuple visto no servidor não corresponde ao tuple no cliente. Veja os dois lados de cada salto NAT antes de concluir que uma regra está a ser ignorada. O diagnóstico apenas no cliente pode produzir uma regra que parece correta e falha na mesma.

Implementações compatíveis com MOBIKE também podem passar para a 4500 sem NAT detetado, e algumas instalações forçam deliberadamente esse caminho. Ver 4500 é, por isso, evidência de uma decisão, não prova de um router doméstico.

Verifique os dois fluxos em cada fronteira

Percorra as três fronteiras: a rede do cliente, qualquer firewall intermédia e o servidor. Cada uma precisa dos fluxos documentados pela instalação, não dos fluxos de um artigo sobre outro caso.

sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state

A linha ESP numa lista de firewall é uma correspondência de protocolo, por isso uma regra de porta nunca a cobre. Se o operador usar uma porta personalizada, siga a configuração documentada nas duas extremidades, porque um cliente não pode criar um listener no servidor escolhendo um número familiar.

Registe onde a negociação parou e se foi instalada uma associação de segurança filha, porque esse par separa um caminho bloqueado de um erro de autenticação ou de política. Depois repita o teste com a verificação do servidor ativa, porque a acessibilidade não é autenticação. Esse último passo separa uma porta permitida de um par de confiança.