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

Pon unha captura a ambos os dous lados dunha pasarela VPN e un só fluxo pode amosar catro enderezos distintos. O NAT de orixe reescribe de onde di o paquete que vén; o NAT de destino reescribe a onde vai. Masquerade non é unha terceira dirección, é unha regra de NAT de orixe que toma o seu enderezo da interface de saída en lugar dun valor fixo. Nomea cal das tres necesitas de verdade e a maioría dos tickets de «a VPN está rota» redúcense a unha pregunta sobre o camiño de volta.

Que reescribe cada regra

O NAT de orixe, normalmente escrito SNAT, cambia o enderezo de orixe dun fluxo ao saír dun router ou dunha pasarela. O servizo que recibe responde ao enderezo traducido, e a caixa que traduce desfai o cambio co estado que gardou para esa conexión. En Linux ese estado vive en conntrack, por iso conntrack -L imprime as tuplas orixinal e de resposta unha ao lado da outra.

O NAT de destino, DNAT, cambia o destino no seu lugar. Un paquete dirixido a un enderezo público en UDP 51820 pode reescribirse cara a un servidor WireGuard interno en 10.8.0.2:51820. Así publica un router doméstico ou un balanceador na nube un escoitador VPN, e iso non di nada sobre o que o túnel poida transportar despois.

Masquerade pertence á familia SNAT. A regra non nomea ningún enderezo; usa o que teña a interface de saída cando o paquete sae. Linux dálle o seu propio destino, e é a opción habitual nunha interface WAN que obtén o enderezo por DHCP ou PPPoE.

Onde vive o mapeo decide o fallo

Anota a tupla en cada fronteira: antes do túnel, dentro del e na interface pública. Unha captura dentro do túnel difire lexitimamente dunha fóra, e quen compare as dúas sen saber onde ocorre a tradución perseguirá o host equivocado.

O tráfico de volta debe pasar polo dispositivo que garda o mapeo. Se a resposta toma outra ruta, un segundo enlace ascendente, unha ruta de política ou un provedor que nunca oíu falar do teu rango privado, a tradución inversa con estado nunca ocorre e o cliente ve tráfico nun só sentido. Engadir máis NAT de orixe raramente arranxa unha ruta de volta ausente; pode ocultar o síntoma nun fluxo mentres rompe a política baseada en enderezos en todo o demais.

O outro erro común é esperar que un túnel cree enrutabilidade. Un cliente privado cuxos paquetes saen a internet necesita unha disposición de saída válida: unha ruta por defecto, unha pasarela que reenvía e, normalmente, tradución de orixe a un enderezo público. O cifrado por si só non fai alcanzable un enderezo privado.

Masquerade ou SNAT explícito

Compara os dous polo que prometen. Masquerade escolle o enderezo de saída, o SNAT explícito fíxao. Nunha pasarela cun enderezo público estable, fixalo dá aos rexistros e ás listas de permitidos dos socios un valor previsible. Nun enlace WAN dinámico, un enderezo SNAT fixado vólvese incorrecto no momento en que cambia a concesión, e é xusto o caso para o que se creou Masquerade.

O alcance importa tanto como a elección. Unha regra Masquerade que coincide con cada paquete que sae da pasarela, sen límite de orixe nin de destino, tamén traduce tráfico que querías manter intacto, incluído o tráfico cara a outras redes privadas. Limita a regra ao rango de clientes, ao destino previsto e á interface.

O IPsec baseado en políticas é onde isto morde máis forte. A guía de reenvío de strongSwan percorre como habilitar o reenvío IP e engadir unha regra de SNAT para os clientes, e a mesma documentación cobre como excluír o tráfico que debe conservar o seu enderezo orixinal. Traduce unha orixe antes de que a política de seguridade a atope e o túnel pode erguerse mentres o tráfico segue caendo, porque o paquete xa non se parece ao selector que se negociou.

Decide tamén que debe ver o extremo afastado. Tras a tradución un servizo ve a pasarela, non o cliente individual. Iso simplifica o enrutamento de volta e á vez achanda os rexistros e anula as listas de permitidos por cliente. Se conservar os enderezos dos clientes importa, planifica un camiño de volta enrutado en lugar de ocultalos para que pase unha proba.

Ler as regras nunha pasarela Linux

Unha pasarela de acceso remoto con clientes en 10.8.0.0/24 e unha interface WAN chamada eth0 necesita o reenvío habilitado e unha política de filtrado que permita o fluxo antes de que calquera regra NAT poida axudar. A versión de iptables mantén ambas as direccións na táboa 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 de nftables usa os mesmos dous ganchos cunha interface nomeada e unha cadea 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 fragmentos asumen que a cadea de filtrado xa acepta o fluxo reenviado. NAT non é unha regra de permiso, e un paquete traducido correctamente aínda pode descartarse unha táboa máis alá. Confirma o mapeo vivo con conntrack -L, confirma que está cargado con nft list ruleset ou iptables-save -t nat, e despois captura en ambas as interfaces para ver que o enderezo cambia de verdade.

Modos de fallo que parecen unha regra mala

O tráfico de forcada é o clásico. Un cliente interno que chega a un servidor interno polo enderezo público do servidor necesita o DNAT á entrada e unha tradución de orixe á saída de volta, ou o servidor responde directamente ao cliente e a resposta rexéitase. A corrección é unha segunda regra, máis estreita, para ese caso de interno a público, non unha regra Masquerade máis ampla para todo.

A tradución dobre é a silenciosa. Un cliente que xa está detrás dun NAT de operador chega á túa pasarela cun enderezo que non podes enrutar de volta, así que traduces outra vez. Funciona, pero os rexistros agora levan dous saltos de enderezo privado e calquera investigación necesita ambos os mapeos. O IPsec baseado en políticas engade un terceiro xiro: traduce antes de que coincida a política e obtés unha SA erguida sen tráfico que pase, o que se le como un fallo do cortalumes e non do NAT.

Despois está a proba que pasa e o despregamento que falla. Executar o comando NAT a man demostra o mecanismo, non a configuración. Unha regra engadida en tempo de execución desaparece ao reiniciar ou no seguinte evento de interface, e unha regra Masquerade ligada a unha interface que cambia de número pode cambiar en silencio o enderezo que ve o extremo afastado. Pon a regra na configuración do cortalumes que a posúe e volve probar despois dunha reconexión.

Lista de comprobación antes de gardar a regra

Nomea primeiro a dirección: orixe, destino ou ambas. Despois identifica quen debe gardar o estado — a pasarela, o router de arriba ou o par IPsec — e confirma que o camiño de volta regresa por el. Limita a regra ao rango de clientes, ao destino e á interface que realmente pretendes, e decide de antemán se o extremo afastado debe ver a pasarela ou o enderezo orixinal do cliente.

Proba desde un cliente, non desde a pasarela. Un navegador na propia pasarela pode saltarse por completo a regra de tradución de clientes, así que unha páxina que funcione alí non demostra nada sobre o túnel. Envía unha petición orixinada polo cliente, observa os contadores e a táboa de conntrack, e repíteo tras unha reconexión do túnel e un cambio de enderezo WAN se calquera das dúas cousas é posible onde traballas.