SNAT, DNAT e Masquerade: o que cada regra NAT de VPN faz

Coloque uma captura dos dois lados de um gateway VPN e um único fluxo pode mostrar quatro endereços diferentes. O NAT de origem reescreve de onde o pacote diz vir; o NAT de destino reescreve para onde vai. Masquerade não é uma terceira direção, é uma regra de NAT de origem que tira o endereço da interface de saída em vez de um valor fixo. Nomeie qual das três você realmente precisa e a maioria dos tickets „a VPN está quebrada“ se resume a uma pergunta sobre o caminho de volta.

O que cada regra reescreve

O NAT de origem, normalmente escrito SNAT, muda o endereço de origem de um fluxo ao sair de um roteador ou gateway. O serviço que recebe responde ao endereço traduzido, e a caixa que traduz desfaz a mudança com o estado que guardou para aquela conexão. No Linux esse estado vive no conntrack, por isso conntrack -L imprime as tuplas original e de resposta lado a lado.

O NAT de destino, DNAT, muda o destino em vez disso. Um pacote endereçado a um endereço público em UDP 51820 pode ser reescrito para um servidor WireGuard interno em 10.8.0.2:51820. É assim que um roteador doméstico ou um balanceador na nuvem publica um ouvinte VPN, e isso não diz nada sobre o que o túnel pode carregar depois.

Masquerade pertence à família SNAT. A regra não nomeia nenhum endereço; usa o que a interface de saída tiver quando o pacote sair. O Linux dá a ela um alvo próprio, e é a escolha habitual numa interface WAN que recebe o endereço por DHCP ou PPPoE.

Onde o mapeamento vive decide a falha

Anote a tupla em cada fronteira: antes do túnel, dentro dele e na interface pública. Uma captura dentro do túnel difere legitimamente de uma fora, e quem compara as duas sem saber onde a tradução acontece vai perseguir o host errado.

O tráfego de volta precisa passar pelo dispositivo que detém o mapeamento. Se a resposta pegar outro caminho, um segundo uplink, uma rota de política ou um provedor que nunca ouviu falar da sua faixa privada, a tradução inversa com estado nunca acontece e o cliente vê tráfego de mão única. Adicionar mais NAT de origem raramente conserta uma rota de volta ausente; pode esconder o sintoma num fluxo enquanto quebra a política baseada em endereços em todo o resto.

O outro erro comum é esperar que um túnel crie roteabilidade. Um cliente privado cujos pacotes saem para a internet precisa de um arranjo de saída válido: uma rota padrão, um gateway que encaminhe e, normalmente, tradução de origem para um endereço público. A criptografia sozinha não torna um endereço privado alcançável.

Masquerade ou SNAT explícito

Compare os dois pelo que prometem. Masquerade escolhe o endereço de saída, o SNAT explícito o fixa. Numa gateway com endereço público estável, fixá-lo dá aos logs e às listas de permissão dos parceiros um valor previsível. Num link WAN dinâmico, um endereço SNAT fixado torna-se errado no momento em que a concessão muda, e é exatamente o caso para o qual o Masquerade foi feito.

O escopo importa tanto quanto a escolha. Uma regra Masquerade que casa com todo pacote que sai do gateway, sem limite de origem ou destino, também traduz tráfego que você queria manter intacto, incluindo tráfego para outras redes privadas. Limite a regra à faixa de clientes, ao destino pretendido e à interface.

O IPsec baseado em políticas é onde isso morde mais forte. O guia de encaminhamento do strongSwan percorre a ativação do encaminhamento IP e a adição de uma regra de SNAT de origem para clientes, e a mesma documentação cobre excluir o tráfego que precisa manter o endereço original. Traduza uma origem antes que a política de segurança a encontre e o túnel pode subir enquanto o tráfego continua caindo, porque o pacote já não parece o seletor negociado.

Decida também o que a ponta remota deve ver. Depois da tradução um serviço vê o gateway, não o cliente individual. Isso simplifica o roteamento de volta e ao mesmo tempo achata logs e anula listas de permissão por cliente. Se preservar os endereços dos clientes importa, planeje um caminho de volta roteado em vez de escondê-los para fazer um teste passar.

Ler as regras num gateway Linux

Um gateway de acesso remoto com clientes em 10.8.0.0/24 e uma interface WAN chamada eth0 precisa de encaminhamento ativo e de uma política de filtragem que permita o fluxo antes de qualquer regra NAT ajudar. A versão iptables mantém as duas direções na tabela nat:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

A forma nftables usa os mesmos dois ganchos com uma interface nomeada e uma cadeia explícita:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

Ambos os trechos presumem que a cadeia de filtragem já aceita o fluxo encaminhado. NAT não é regra de permissão, e um pacote traduzido corretamente ainda pode ser descartado uma tabela adiante. Confirme o mapeamento ao vivo com conntrack -L, confirme o que está carregado com nft list ruleset ou iptables-save -t nat, e então capture nas duas interfaces para ver o endereço realmente mudar.

Modos de falha que parecem uma regra ruim

O tráfego de grampo é o clássico. Um cliente interno que chega a um servidor interno pelo endereço público do servidor precisa do DNAT na entrada e de uma tradução de origem na saída de volta, senão o servidor responde diretamente ao cliente e a resposta é rejeitada. A correção é uma segunda regra, mais estreita, para esse caso interno-para-público, não uma regra Masquerade mais ampla para tudo.

A tradução dupla é a silenciosa. Um cliente que já está atrás de NAT de operadora chega ao seu gateway com um endereço que você não consegue rotear de volta, então você traduz de novo. Funciona, mas os logs agora carregam dois saltos de endereçamento privado e qualquer investigação precisa dos dois mapeamentos. O IPsec baseado em políticas acrescenta um terceiro giro: traduza antes da correspondência de política e você obtém uma SA de pé sem tráfego passando, o que se lê como bug de firewall e não de NAT.

Depois há o teste que passa e a implantação que falha. Rodar o comando NAT à mão prova o mecanismo, não a configuração. Uma regra adicionada em tempo de execução desaparece no reboot ou no próximo evento de interface, e uma regra Masquerade amarrada a uma interface que muda de número pode mudar em silêncio o endereço que a ponta remota vê. Coloque a regra na configuração do firewall que a possui e reteste depois de uma reconexão.

Lista de verificação antes de salvar a regra

Nomeie primeiro a direção: origem, destino ou ambas. Depois identifique quem deve deter o estado — o gateway, o roteador acima ou o par IPsec — e confirme que o caminho de resposta volta por ele. Limite a regra à faixa de clientes, ao destino e à interface que você realmente pretende, e decida de antemão se a ponta remota deve ver o gateway ou o endereço original do cliente.

Teste a partir de um cliente, não do gateway. Um navegador no próprio gateway pode contornar por completo a regra de tradução de clientes, então uma página que funcione ali não prova nada sobre o túnel. Envie uma requisição originada no cliente, observe os contadores e a tabela de conntrack, e repita depois de uma reconexão do túnel e de uma mudança de endereço WAN se qualquer uma das duas for possível onde você trabalha.