A resposta da VPN site a site não passa pelo túnel
Uma resposta que contorna o túnel é uma decisão de roteamento do lado remoto. Verifique a tabela de hosts, os seletores e o rp_filter, e depois escolha rota ou NAT.
Passei uma manhã com um túnel que subia limpo e movia tráfego exatamente numa direção: a filial alcançava o servidor de arquivos da matriz, e toda conexão aberta da matriz para a filial morria no primeiro SYN. As SA estavam ativas, os contadores do túnel subiam e o handshake nunca foi o problema. A resposta estava sendo roteada para um lugar que o túnel não cobre, e essa escolha pertence ao lado remoto. Uma VPN site a site só transporta os pacotes que um host entrega ao gateway, e cada host faz essa escolha separadamente, em cada direção, a partir da sua própria tabela de roteamento.
As duas direções são roteadas separadamente
O IP não guarda memória da direção de uma conversa. Cada host que envia um pacote executa sua própria busca do prefixo mais longo, escolhe um único próximo salto e esquece a decisão. A requisição e a resposta são dois pacotes sem relação que por acaso pertencem à mesma conexão, e o túnel é um salto que qualquer um dos dois pode usar ou não. Nada da troca IKE ensina ao servidor remoto como alcançar a sua sub-rede; a negociação apenas concorda quais prefixos podem ser criptografados.
Esse acordo é o segundo portão. No strongSwan os seletores de tráfego são leftsubnet e rightsubnet, e um pacote cuja origem ou destino cai fora do par negociado não é criptografado, diga o que disser a tabela de roteamento. Um prefixo roteado para o túnel mas ausente dos seletores é uma falha silenciosa de um só sentido: a rota parece correta, o pacote ainda sai em claro ou é descartado, e só o log do charon reclama.
O host remoto não sabe nada do seu túnel
Dentro da LAN remota a resposta é um pacote comum endereçado ao seu cliente. O host de destino não vê cabeçalho IPsec e não tem motivo para preferir o gateway VPN; procura o seu prefixo, não encontra nada mais específico que a sua rota padrão e segue por ela. Se a rota padrão aponta para um firewall central, o firewall tem ou não tem uma rota de volta para o túnel. Quando não tem, você recebe um descarte silencioso, um ICMP unreachable ou uma resposta que sai pela interface voltada para a internet e morre.
Uma segunda interface basta para quebrar isso mesmo quando existe uma rota. Um NAS com link de gerência em outra VLAN, um servidor com uplink de reserva, uma regra de política que manda uma faixa de origem para uma segunda tabela: qualquer uma dessas coisas pode capturar a resposta. No Linux, ip rule show e ip route show table all mostram regras e tabelas que a listagem padrão esconde.
Leia a decisão na máquina que envia a resposta
Pergunte ao kernel antes de mudar qualquer coisa, e dê a ele o endereço de origem, porque regras dependentes da origem mudam a resposta.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"A saída nomeia a interface de saída e o próximo salto. Se a interface não for a que olha para o gateway VPN, você encontrou o defeito, e o trabalho restante é escolher onde a rota deve ficar. Um ping a partir do gateway prova pouco aqui: ele responde com um endereço que o host remoto consegue situar, não com o endereço do seu notebook.
No Windows os equivalentes são Find-NetRoute -RemoteIPAddress 10.10.5.10 para a decisão e Get-NetRoute para a tabela. Uma rota adicionada com New-NetRoute que carrega métrica mais alta que a padrão perde em silêncio, então leia a coluna de métrica, não a entrada. Depois confirme com pacotes: tcpdump -ni any "host 10.10.5.10 and tcp port 445" na interface LAN remota mostra a requisição, e o mesmo filtro do lado do túnel mostra se uma resposta voltou. Requisição visível sem resposta significa que a resposta foi roteada para outro lugar ou descartada; uma resposta na interface errada entrega o culpado antes de você tocar numa rota.
Quando o gateway do servidor não é o ponto final da VPN
Muitos sites colocam um firewall entre os servidores e o concentrador. Esse firewall encaminha a resposta, então precisa de uma rota para o prefixo do seu cliente apontando para o gateway VPN, e de política de encaminhamento nas duas direções. Dispositivos com estado pioram: a requisição atravessou o firewall vinda de um host LAN que ele permitiu, a resposta agora chega de outra direção e a entrada de rastreamento de conexão já não corresponde, então o pacote é descartado como inválido em vez de negado. É por isso que o log de política parece vazio enquanto o tráfego desaparece.
O gateway tem seu próprio segundo filtro. A filtragem de caminho inverso do Linux descarta pacotes cuja origem não é alcançável pela interface por onde chegaram, e essa é exatamente a forma de um caminho de volta assimétrico legítimo. o guia de encaminhamento do strongSwan pede net.ipv4.ip_forward e um net.ipv4.conf.all.rp_filter afrouxado justamente por isso. Um valor estrito de 1 em qualquer dos gateways quebra em silêncio uma rota correta, e nstat -az mostra os descartes se você souber onde olhar.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
Roteie ou traduza, e depois verifique nas duas direções
As duas correções não são equivalentes. Adicionar uma rota mantém o endereço do cliente intacto, então regras baseadas na origem, logs de auditoria e aplicações que registram o chamador continuam funcionando; o preço é que cada salto que toma a decisão precisa da rota, o que são mais lugares para errar. Mascaramento no gateway remoto reduz o caminho de volta a um único salto, porque a resposta agora é endereçada ao próprio gateway, e esconde qual cliente fez o quê.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEEscolha-o deliberadamente: assim que os clientes aparecem como o endereço do gateway, as ACL baseadas na origem deixam de distingui-los, e o conntrack tem de manter o mapeamento para que a resposta seja reescrita de volta ao túnel. Se os seletores ainda excluírem o prefixo do cliente, o NAT não muda nada, porque a requisição nunca entrou no túnel.
Antes de dar isso por resolvido, confirme quatro coisas em ordem: a rota no host que envia a resposta, a rota em cada salto que a encaminha, os seletores cobrindo os dois prefixos e uma captura mostrando a resposta entrando no túnel com a origem que você espera. Depois repita o teste a partir do outro site. Uma direção que passa é um desenho entreaberto, e a segunda direção costuma falhar por um motivo diferente do que você acabou de corrigir.