Deve aplicar SNAT a um encaminhamento de porta para uma sub-rede VPN?

Encaminhar uma porta para um anfitrião que está atrás do próprio cliente VPN do router falha de uma forma que parece um problema de firewall, porque o pedido chega claramente. O serviço registra uma ligação, o cliente espera e nada volta. A tradução de destino fez o seu trabalho; o pacote de retorno é a parte que desapareceu. Uma regra seletiva de NAT de origem no router corrige isso, e a parte interessante é decidir quão estreita essa regra pode ser.

Por que a resposta segue outro caminho

Um encaminhamento de porta reescreve para onde vai um pacote, nunca de onde veio. O endereço do cliente de internet fica no campo de origem durante todo o túnel, por isso o serviço remoto vê um estranho e responde da única forma que conhece: pela sua própria gateway predefinida. Essa gateway é o concentrador VPN do outro lado, que não tem rota de volta para um endereço público arbitrário.

Veja uma captura na interface do túnel e a assimetria é óbvia: pacotes de pedido para fora, nada para dentro. A cadeia de encaminhamento permitiu o fluxo e o túnel transportou-o, então a queda acontece depois de o anfitrião remoto já ter escolhido um caminho de volta.

Uma regra de origem suficientemente estreita para confiar

Faça do router a origem a que o anfitrião remoto responde. Nesta disposição o endereço WAN é 203.0.113.24, a LAN é 192.168.88.0/24, o endereço do túnel do router é 172.20.5.1, e o serviço responde em 172.20.5.40:8443. A regra abaixo corresponde ao pacote após a tradução de destino, e por isso nomeia o endereço traduzido e não o público. Nada nela depende do endereço do cliente, e é exatamente esse o ponto.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Cada correspondência nessa linha existe para manter a reescrita local a um serviço num túnel. Retire a interface ou a porta e reescreve mais tráfego do que o problema exige, e é assim que uma correção dirigida se torna um mistério para a próxima pessoa.

Quando uma máscara global é a escolha honesta

Se o router encaminha muitos serviços para a mesma sub-rede VPN, uma regra por serviço torna-se uma lista que ninguém mantém. Mascarar tudo o que sai da interface do túnel é mais simples e previsível, à custa de esconder o cliente original de cada anfitrião do outro lado. Escolha-o quando os registos de lá não forem usados para atribuição; mantenha a regra estreita quando forem.

As duas opções também falham de forma diferente. Uma regra estreita em falta quebra um serviço; uma máscara ampla que corresponde a demasiado pode reescrever em silêncio tráfego que já funcionava, incluindo as próprias ligações de saída do router.

Verifique os contadores antes de publicar

As regras que nunca correspondem parecem idênticas às que funcionam até contar pacotes. Releia a tabela com contadores de bytes antes de qualquer cliente se ligar, depois ligue-se a partir de uma rede que não seja a LAN e releia-a. Duas leituras são o que transforma uma suposição num facto. Publique o encaminhamento só depois de a segunda se mexer.

iptables -t nat -L POSTROUTING -v -n --line-numbers

Um contador a zero na regra de origem após uma ligação real significa que a correspondência está errada, normalmente porque o destino ou a porta não correspondem ao pacote após a tradução. Se o contador subir mas o cliente continuar a expirar, o caminho de volta está reparado e outra coisa está a descartar a resposta, por isso veja a seguir a política de encaminhamento do outro lado. O acesso em grampo a partir de dentro da LAN é um problema separado e precisa da sua própria regra, não de uma versão mais ampla desta.