Mascarada o enrutamiento por políticas: tráfico LAN por una puerta de enlace VPN

Poner toda una LAN detrás de un túnel VPN es la parte fácil; decidir cómo ve el lado remoto a esos clientes no lo es. La mascarada reescribe cada origen de la LAN a la dirección del túnel de la puerta de enlace, de modo que el extremo remoto responde a un solo par. El enrutamiento por políticas conserva las direcciones originales y exige que el extremo remoto sepa cómo llegar a ellas. Ninguna de las dos es la opción predeterminada; la elección depende de quién es dueño del lado remoto y de si importa la identidad por dispositivo.

Los dos diseños prometen cosas distintas

La mascarada reduce la LAN a un único host visible: la puerta de enlace. La red remota responde a esa única dirección, y la puerta de enlace traduce las respuestas de vuelta al cliente que inició el flujo. No se necesita ninguna ruta a tus prefijos privados en el lado remoto, y por eso este diseño sobrevive a un proveedor que se niega a transportarlos. La puerta de enlace también se convierte en el origen de cada conexión, así que el lado remoto no puede distinguir dos clientes.

El enrutamiento por políticas mantiene intacta la dirección de cada cliente. La red remota ve el origen real y puede registrarlo, aplicar una regla por host o enviar la respuesta directamente a esa dirección. Esa visibilidad es todo el objetivo, y viene con una obligación: el lado remoto debe tener una ruta para el prefijo de la LAN que apunte de vuelta por el túnel. Planifica esa ruta antes de habilitar la regla, porque el túnel se levantará de todos modos y solo faltarán las respuestas.

Los modos de fallo difieren tanto como las promesas. Una regla de mascarada ausente produce paquetes que salen con orígenes privados y nunca vuelven. Una ruta de retorno ausente produce el mismo síntoma con enrutamiento por políticas, pero la corrección corresponde al router remoto y no a la puerta de enlace.

Mascarada: un solo par en el lado remoto

La ruta de la mascarada tiene un orden que importa. El reenvío debe estar habilitado antes de que ninguna regla NAT sirva de algo, la tabla de filtrado debe permitir el tránsito en ambos sentidos, y solo entonces se aplica la traducción en la interfaz del túnel.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Los clientes siguen necesitando un camino hacia la puerta de enlace. O la puerta de enlace es su router predeterminado, o llevan una ruta específica para el prefijo remoto; si un router separado sigue siendo el predeterminado, ese router necesita una ruta estática para los destinos del túnel, de lo contrario el paquete va al salto equivocado antes de que la puerta de enlace lo vea.

El DNS es una decisión aparte. Un resolutor del lado remoto solo responde si su respuesta puede viajar de vuelta al cliente. Con mascarada la consulta parece venir de la puerta de enlace, así que la ruta de retorno del resolutor ya está cubierta; con enrutamiento por políticas el resolutor necesita la misma ruta de retorno que cualquier otro servicio remoto.

Enrutamiento por políticas: conserva el origen, añade una ruta de retorno

El enrutamiento por políticas empieza con una tabla y una regla que la selecciona. El tráfico que entra por la interfaz de la LAN se envía a una tabla dedicada, y esa tabla lleva una ruta predeterminada por el túnel. La tabla principal queda intacta, así que el tráfico originado por la propia puerta de enlace puede seguir otro camino.

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

El lado remoto debe entonces encaminar el prefijo de la LAN de vuelta por el túnel. Eso es una configuración en el router remoto, no en esta puerta de enlace. La puerta de enlace también debe aceptar respuestas que llegan por una interfaz distinta de la que predeciría la tabla principal; el filtrado laxo de ruta inversa (rp_filter ajustado a 2) es el ajuste habitual cuando el modo estricto descarta esos paquetes.

Cuando hay dos túneles activos, etiqueta cada flujo al entrar y deja que la etiqueta elija la tabla. Una regla que solo mira la interfaz de entrada envía el tráfico de ambos túneles a la misma tabla, así que el segundo túnel roba flujos al primero. Prueba esa etiqueta con una conexión que sobreviva a una reconexión, que es cuando se manifiesta una política mixta.

Decide por propiedad y por lo que registra el lado remoto

Si el túnel termina en un proveedor, usa mascarada. Ese operador no va a encaminar tus rangos privados de LAN, y no tiene motivo para distinguir clientes individuales detrás de tu puerta de enlace. Un solo par visible es el único modelo que admite su política, así que dale eso y mantén la traducción en tu borde. El proveedor ve un par, que es exactamente lo que espera su política, y tus clientes heredan esa única identidad.

Si ambos extremos son tuyos y los servicios remotos actúan sobre direcciones de origen, el enrutamiento por políticas se gana su ruta adicional. Las reglas del cortafuegos, el acceso por usuario y los registros de auditoría pueden entonces distinguir clientes. Si el lado remoto solo necesita alcanzabilidad, la mascarada es más simple y elimina una clase de errores de ruta de retorno.

Los diseños híbridos son normales: enrutamiento por políticas dentro de tu propia red, mascarada en el borde del proveedor. Lo importante es anotar qué salto traduce y qué salto encamina, porque una regla NAT accidental añadida para un cliente oculta el origen para todos los clientes de la misma cadena.

Verifica desde un cliente y luego desde un segundo cliente

Ejecuta la prueba donde empieza el tráfico. Comprueba la ruta que usa el host, observa cómo el paquete aparece en la interfaz del túnel e inspecciona conntrack para la traducción. Esa secuencia demuestra que el paquete tomó el camino previsto y no que simplemente llegó a algún sitio.

Repite la prueba tras una reconexión. Una regla de mascarada que nombra la interfaz sobrevive a una nueva dirección de túnel; una regla que nombra la dirección antigua no. Luego prueba un segundo host de la LAN, porque un diseño que funciona en una máquina a menudo depende de la ruta propia de esa máquina y no de la política de la puerta de enlace.

Anota el modelo elegido, el origen traducido o conservado y el propietario de la ruta de retorno en las notas de la puerta de enlace. Si no, la siguiente persona que añada un cliente o un túnel adivinará, y adivinar es cómo una configuración LAN-a-VPN que funciona se vuelve parcial.