SNAT, DNAT y Masquerade: qué hace cada regla NAT de VPN

Ponga una captura a ambos lados de una puerta de enlace VPN y un solo flujo puede mostrar cuatro direcciones distintas. El NAT de origen reescribe de dónde dice el paquete que viene; el NAT de destino reescribe a dónde va. Masquerade no es una tercera dirección, es una regla de NAT de origen que toma su dirección de la interfaz de salida en lugar de un valor fijo. Nombra cuál de las tres necesitas de verdad y la mayoría de los tiques de «la VPN está rota» se reducen a una pregunta sobre el camino de vuelta.

Qué reescribe cada regla

El NAT de origen, normalmente escrito SNAT, cambia la dirección de origen de un flujo al salir de un router o una puerta de enlace. El servicio receptor responde a la dirección traducida, y la caja que traduce deshace el cambio con el estado que guardó para esa conexión. En Linux ese estado vive en conntrack, por eso conntrack -L imprime las tuplas original y de respuesta una al lado de la otra.

El NAT de destino, DNAT, cambia el destino en su lugar. Un paquete dirigido a una dirección pública en UDP 51820 puede reescribirse hacia un servidor WireGuard interno en 10.8.0.2:51820. Así publica un router doméstico o un balanceador en la nube un escucha VPN, y eso no dice nada sobre lo que el túnel pueda transportar después.

Masquerade pertenece a la familia SNAT. La regla no nombra ninguna dirección; usa la que tenga la interfaz de salida cuando el paquete sale. Linux le da su propio objetivo, y es la opción habitual en una interfaz WAN que obtiene su dirección por DHCP o PPPoE.

Dónde vive el mapeo decide el fallo

Anote la tupla en cada frontera: antes del túnel, dentro de él y en la interfaz pública. Una captura dentro del túnel difiere legítimamente de una fuera, y quien compare las dos sin saber dónde ocurre la traducción perseguirá el host equivocado.

El tráfico de vuelta debe pasar por el dispositivo que guarda el mapeo. Si la respuesta toma otra ruta, un segundo enlace ascendente, una ruta de política o un proveedor que nunca ha oído hablar de su rango privado, la traducción inversa con estado nunca ocurre y el cliente ve tráfico en un solo sentido. Añadir más NAT de origen rara vez arregla una ruta de vuelta ausente; puede ocultar el síntoma en un flujo mientras rompe la política basada en direcciones en todo lo demás.

El otro error común es esperar que un túnel cree enrutabilidad. Un cliente privado cuyos paquetes salen a internet necesita un arreglo de salida válido: una ruta por defecto, una puerta de enlace que reenvíe y, normalmente, traducción de origen a una dirección pública. El cifrado por sí solo no hace alcanzable una dirección privada.

Masquerade o SNAT explícito

Compare ambos por lo que prometen. Masquerade elige la dirección de salida, el SNAT explícito la fija. En una puerta de enlace con una dirección pública estable, fijarla da a los registros y a las listas de permitidos de los socios un valor predecible. En un enlace WAN dinámico, una dirección SNAT fijada se vuelve incorrecta en el momento en que cambia la concesión, y es justo el caso para el que se creó Masquerade.

El alcance importa tanto como la elección. Una regla Masquerade que coincide con cada paquete que sale de la puerta de enlace, sin límite de origen ni de destino, también traduce tráfico que querías mantener intacto, incluido el tráfico hacia otras redes privadas. Limita la regla al rango de clientes, al destino previsto y a la interfaz.

El IPsec basado en políticas es donde esto muerde más fuerte. La guía de reenvío de strongSwan recorre cómo habilitar el reenvío IP y añadir una regla de SNAT para los clientes, y la misma documentación cubre cómo excluir el tráfico que debe conservar su dirección original. Traduce un origen antes de que la política de seguridad lo encuentre y el túnel puede levantarse mientras el tráfico sigue cayendo, porque el paquete ya no se parece al selector que se negoció.

Decide también qué debe ver el extremo lejano. Tras la traducción un servicio ve la puerta de enlace, no al cliente individual. Eso simplifica el enrutamiento de vuelta y a la vez aplana los registros y anula las listas de permitidos por cliente. Si conservar las direcciones de los clientes importa, planifica un camino de vuelta enrutado en lugar de esconderlas para que pase una prueba.

Leer las reglas en una puerta de enlace Linux

Una puerta de enlace de acceso remoto con clientes en 10.8.0.0/24 y una interfaz WAN llamada eth0 necesita el reenvío habilitado y una política de filtrado que permita el flujo antes de que cualquier regla NAT pueda ayudar. La versión de iptables mantiene ambas direcciones en la tabla 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

La forma de nftables usa los mismos dos ganchos con una interfaz nombrada y una cadena 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 fragmentos asumen que la cadena de filtrado ya acepta el flujo reenviado. NAT no es una regla de permiso, y un paquete traducido correctamente puede descartarse una tabla más allá. Confirma el mapeo vivo con conntrack -L, confirma qué está cargado con nft list ruleset o iptables-save -t nat, y luego captura en ambas interfaces para ver que la dirección cambia de verdad.

Modos de fallo que parecen una regla mala

El tráfico de horquilla es el clásico. Un cliente interno que llega a un servidor interno por la dirección pública del servidor necesita el DNAT a la entrada y una traducción de origen a la salida de vuelta, o el servidor responde directamente al cliente y la respuesta se rechaza. La solución es una segunda regla, más estrecha, para ese caso de interno a público, no una regla Masquerade más amplia para todo.

La traducción doble es la silenciosa. Un cliente que ya está detrás de un NAT de operador llega a tu puerta de enlace con una dirección que no puedes enrutar de vuelta, así que traduces otra vez. Funciona, pero los registros ahora llevan dos saltos de direccionamiento privado y cualquier investigación necesita ambos mapeos. El IPsec basado en políticas añade un tercer giro: traduce antes de que coincida la política y obtienes una SA levantada sin tráfico que pase, lo que se lee como un fallo del cortafuegos y no del NAT.

Luego está la prueba que pasa y el despliegue que falla. Ejecutar el comando NAT a mano demuestra el mecanismo, no la configuración. Una regla añadida en tiempo de ejecución desaparece al reiniciar o en el siguiente evento de interfaz, y una regla Masquerade ligada a una interfaz que cambia de número puede cambiar en silencio la dirección que ve el extremo lejano. Pon la regla en la configuración del cortafuegos que la posee y vuelve a probar después de una reconexión.

Lista de comprobación antes de guardar la regla

Nombra primero la dirección: origen, destino o ambas. Luego identifica quién debe guardar el estado — la puerta de enlace, el router de arriba o el par IPsec — y confirma que el camino de vuelta regresa por él. Limita la regla al rango de clientes, el destino y la interfaz que realmente pretendes, y decide de antemano si el extremo lejano debe ver la puerta de enlace o la dirección original del cliente.

Prueba desde un cliente, no desde la puerta de enlace. Un navegador en la propia puerta de enlace puede saltarse por completo la regla de traducción de clientes, así que una página que funcione ahí no demuestra nada sobre el túnel. Envía una petición originada por el cliente, observa los contadores y la tabla de conntrack, y repítelo tras una reconexión del túnel y un cambio de dirección WAN si cualquiera de las dos cosas es posible donde trabajas.