Alcançar um cliente IKEv2 no seu IP virtual atribuído

Um gateway precisa iniciar uma conexão para um laptop conectado a ele por IKEv2, usando o endereço virtual atribuído a esse cliente. O túnel está ativo, o cliente alcança tudo atrás do gateway e a direção inversa continua falhando. Essa assimetria é normal: a política negociada descreve quais endereços podem falar, não qual lado pode iniciar. Três coisas precisam se alinhar antes que uma requisição iniciada pelo gateway funcione.

O túnel não corrige o endereço de origem

Uma CHILD SA cobre um par de seletores de tráfego, um por lado, e permite tráfego nas duas direções desse par. Ela não diz nada sobre qual par abriu a troca IKE primeiro. Um gateway que originalmente escutava o túnel ainda pode enviar o primeiro pacote de aplicação, desde que a origem e o destino escolhidos caiam dentro dos seletores instalados. Quando a requisição sai pela interface errada, ela simplesmente não é elegível para o túnel.

O roteamento até o cliente é necessário e não suficiente. A política precisa admitir a origem que você realmente usou.

Leia a política instalada, não o arquivo de configuração

Comece pela associação ativa e seus seletores, porque a atribuição dinâmica muda o que está instalado no kernel.

ipsec statusall
ip xfrm policy

A saída de status nomeia a conexão, o endereço virtual atribuído e os seletores em vigor no momento para esse par. O dump de política mostra os mesmos seletores como estado do kernel, e é ele que a seleção de pacotes realmente consulta. Compare o seletor do lado do gateway com a origem que sua aplicação vai usar, porque uma divergência explica a falha de imediato. Leia o endereço atual do cliente e não um de uma sessão anterior, porque um VIP reatribuído invalida a política antiga.

O cliente precisa escutar onde o pacote chega

Mesmo uma política perfeita chega a uma porta fechada quando o serviço se liga apenas ao loopback. O ouvinte precisa estar no endereço atribuído ou em um endereço local curinga.

ss -ltnp 'sport = :9090'
iptables -S INPUT

A listagem de sockets mostra se a porta está ligada ao endereço virtual, e as regras do firewall mostram se novas conexões são aceitas da origem protegida. Uma regra escrita para conexões estabelecidas não admite uma conexão que o gateway inicia. Mantenha a autenticação própria do serviço, porque chegar pelo túnel só estabelece de qual rede o pacote veio. Um cliente atrás do próprio NAT continua sem precisar de encaminhamento de porta de entrada, porque essas requisições viajam dentro do túnel existente.

Teste a nova direção isoladamente

Uma requisição bem-sucedida de cliente para servidor nunca exercita esse caminho. Gere a requisição a partir do gateway e observe as duas pontas.

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

A consulta de rota responde qual origem e interface o gateway usaria, e esse é o valor que a política precisa admitir. A captura deve mostrar a requisição saindo dentro de ESP e não como TCP simples na interface pública. No cliente, capture o tráfego descriptografado para confirmar a chegada e se o serviço respondeu. Se a requisição desaparecer sem ESP no enlace, suspeite do endereço de origem antes do firewall do cliente.

Repita o teste após uma renovação de chaves ou uma reconexão, porque o VIP pode mudar. Um caminho que só funciona até a próxima sessão não é um caminho que funciona.