strongSwan ESP-in-UDP: quando não há NAT a detetar

A deteção de NAT descobre tradução de endereços, não a política da firewall. Uma ligação de site sem NAT pode ainda exigir uma escolha explícita de ESP-in-UDP.

A deteção de NAT responde a uma pergunta: os endereços ou as portas mudaram em trânsito? Não responde se uma firewall permite o protocolo IP 50. Gateways de site sem qualquer tradução podem continuar atrás de uma política que descarta o ESP nativo, e esse requisito tem de ser configurado em vez de descoberto. O mecanismo é ESP-in-UDP, e é uma decisão, não um recurso alternativo que apareça sozinho.

A deteção é aritmética sobre endereços, não uma sonda da firewall

O IKEv2 transporta cargas úteis de deteção de NAT com hashes dos endereços e das portas de origem e destino. Cada lado compara o que recebeu com o que vê localmente, e uma divergência diz-lhe que algo traduziu o pacote. Nada nessa troca testa se um router no meio encaminha o protocolo 50.

Vale a pena dizer a consequência prática sem rodeios. Um túnel que funcionava com ESP nativo não descobre sozinho uma firewall nova mais restritiva, e a tentativa seguinte falha na fase de dados enquanto o IKE continua a ter sucesso. Verá associações de segurança IKE estabelecidas e nenhum tráfego protegido, o que parece uma falha de encaminhamento até capturar no cabo.

O encapsulamento é, portanto, uma propriedade da ligação que configura, não um resultado que os pares negoceiam a partir do comportamento da rede.

Como o encap altera a troca

Numa implementação moderna de strongSwan gerida através de swanctl.conf, a opção encap = yes na ligação influencia a troca de deteção de NAT para que ambos os pares usem encapsulamento UDP para ESP. Os pacotes protegidos viajam então dentro de UDP, convencionalmente na porta 4500, e ambas as extremidades têm de concordar com essa disposição.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Esse fragmento pertence a uma definição de ligação real e não é um perfil de site completo. Mantenha os endereços dos pares, a autenticação e os seletores de tráfego child que já executa; a única chave acrescentada muda a forma como os dados protegidos são envolvidos, não o que protegem.

O guia do strongSwan sobre NAT-traversal descreve este comportamento, incluindo a interação com a porta flutuante quando se usa MOBIKE.

Use a opção que pertence ao seu backend

O strongSwan tem dois backends de configuração, e a chave difere entre eles. Uma swanctl.conf ligação aceita encap, enquanto uma ipsec.conf ligação antiga aceita forceencaps. Colocar a palavra-chave de um backend no outro produz uma configuração que carrega sem queixa e não muda nada, o que é pior do que um erro.

Verifique que daemon está realmente a correr antes de editar seja o que for. Em muitas distribuições existem ambos os ficheiros porque um é um resto de uma migração anterior, e o ativo é o que a unidade de serviço arranca. Leia essa unidade em vez de adivinhar pelas datas dos ficheiros. Uma verificação de cinco segundos aqui evita horas a testar uma opção que nada carregou.

Aplique a alteração através do proprietário da ligação e restabeleça a associação durante uma janela controlada. Um child já instalado mantém o encapsulamento atual até ser substituído, por isso editar o ficheiro sozinho não prova que a nova disposição está em uso.

Verifique os dados envolvidos, não apenas a porta

Capture no gateway enquanto flui tráfego protegido e depois compare isso com a própria visão do strongSwan:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

O ESP nativo aparece como protocolo IP 50 e não se parece nada com UDP. O ESP envolvido aparece como datagramas UDP em 4500 cuja carga útil não é IKE. O tráfego IKE nessa mesma porta não é prova de encapsulamento, porque o MOBIKE pode mover o IKE para lá enquanto o caminho de dados continua nativo, por isso leia a carga útil, não o número da porta.

Tenha também em conta a MTU do caminho. O invólucro acrescenta sobrecarga, e um caminho que transportava ESP nativo pode precisar de ajustes quando os pacotes crescem. O tratamento de ICMP necessário já devia fazer parte do desenho; o encapsulamento não elimina essa dependência.

Aceite a alteração quando o tráfego novo de aplicações dentro do túnel for visível na captura como ESP envolvido em ambas as extremidades, e quando o serviço interno e a sua rota de retorno continuarem a funcionar. Qualquer coisa menos é uma configuração que parece correta num ficheiro.

Artigos relacionados