Enruta una subred LAN por OpenVPN y conserva la ruta predeterminada

Los equipos que enrutan para una LAN y además marcan una VPN acaban en la misma discusión consigo mismos: el túnel quiere poseer la ruta predeterminada y la LAN la necesita de vuelta. Cuando OpenVPN se conecta, puede instalar una ruta predeterminada por el túnel o un par de medias rutas predeterminadas, lo cual es correcto para un portátil e incorrecto para una puerta de enlace cuyos vecinos esperan respuestas desde su dirección LAN. La respuesta no es saltarse la VPN. La respuesta es dar a las dos decisiones tablas distintas.

Una ruta predeterminada, dos propietarios

El tráfico reenviado y el tráfico originado localmente no tienen que seguir el mismo camino. Los clientes de la LAN solo necesitan el túnel para los destinos que elijas, mientras que las sesiones de gestión del propio host y sus respuestas a esos clientes necesitan la ruta predeterminada de la LAN. Mezclar ambas en la tabla principal obliga a una sola respuesta a responder dos preguntas distintas.

OpenVPN tiene un interruptor justo para esto. route-noexec impide que el cliente toque la tabla principal, y los valores que habría usado se exportan a un script route-up como route_vpn_gateway, dev y las direcciones de la interfaz. Después decides qué tabla recibe qué ruta, en código que podrás leer más adelante.

Tabla de políticas frente a reescribir la principal

La tabla separada es la única opción que escala más allá de una subred. Dale un nombre una vez y luego refiérete a ella por el nombre para que nadie tenga que recordar un número:

echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpn

Las direcciones de aquí son marcadores. Sustituye el prefijo LAN, la puerta de enlace del túnel y el nombre del dispositivo de tu propio despliegue antes de ejecutar nada.

La regla también tiene que coincidir con el host

Una regla que solo coincide con el prefijo LAN cubre los paquetes reenviados. No cubre el tráfico que origina la propia puerta de enlace ni las respuestas que envía a los clientes de la LAN, que llevan la dirección LAN de la puerta de enlace como origen. Esas consultas caen a main y todavía pueden salir por el túnel.

Añade una segunda regla para la dirección LAN propia de la puerta de enlace o amplía la primera regla a un conjunto que incluya ambas. El orden importa: pon primero la regla más específica y comprueba el resultado con una consulta que nombre el origen explícitamente.

ip route get 203.0.113.9 from 192.168.50.1

Si eso informa del dispositivo del túnel para un destino que debería quedarse local, el conjunto de reglas es incorrecto independientemente de lo que contenga la tabla.

NAT o una ruta en el lado remoto

El servidor VPN conoce la subred del túnel y nada más. Los paquetes que llegan con una dirección de origen LAN no tienen camino de vuelta a menos que alguien lo proporcione, y hay exactamente dos formas de proporcionarlo. Añadir una ruta para el prefijo LAN en el servidor mantiene el origen original visible de extremo a extremo, que es lo que suele querer un diseño auditado. El enmascaramiento en la puerta de enlace reescribe el origen a la dirección del túnel y no necesita ninguna cooperación del servidor.

iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Elige NAT cuando no controlas el servidor y no puedes añadir rutas allí. Elige la ruta en el lado del servidor cuando importen los registros, el control de acceso o la simetría del camino de vuelta, porque el enmascaramiento borra la dirección original de todo lo que registra el lado remoto.

En cualquier caso, el reenvío tiene que estar activado, y el filtrado estricto de camino inverso puede descartar la respuesta cuando main no habría elegido el túnel para ese origen. Comprueba el valor efectivo antes de culpar al túnel.

Haz que la división sobreviva a una reconexión

Las reglas y rutas añadidas a mano desaparecen cuando se recrea la interfaz, y una entrada de tabla obsoleta puede sobrevivir a la sesión que la justificaba. Pon la regla de tabla, la ruta del túnel y la entrada de enmascaramiento dentro del script route-up del cliente, y vacía la tabla al principio del script para que una puerta de enlace antigua no pueda sobrevivir a la nueva sesión.

Verifica desde ambos extremos: una consulta en la puerta de enlace con el origen LAN y una petición real de un cliente de la LAN a un destino que deba atravesar el túnel. Una ruta que existe pero nunca se selecciona se comporta exactamente como ninguna ruta hasta que leas los contadores.