Por qué una VPN de túnel completo oculta tus VLAN locales enrutadas

El interruptor “allow local network” de un cliente VPN suena como si cubriera todo lo que hay en el edificio. En la práctica suele añadir unas cuantas excepciones de direcciones privadas a la ruta predeterminada del túnel y detenerse ahí. Tu VLAN de almacenamiento solo sigue siendo accesible si una ruta para ese prefijo concreto sobrevive a la llegada del túnel, y en muchos clientes no lo hace.

Es una cuestión de enrutamiento y no un ajuste de la VPN, lo cual es una buena noticia: tiene una respuesta concreta.

Qué cubre realmente allow-local-network

Los clientes implementan esa opción de forma distinta. Algunos añaden rutas para la subred a la que está conectada la máquina, otros añaden los rangos RFC 1918 y unos pocos solo excluyen la puerta de enlace predeterminada. Ninguno sabe que el router de tu oficina también sirve una VLAN de almacenamiento, un segmento de laboratorio o una subred de impresoras, porque esos prefijos no están en el cable que el cliente puede ver. Lee la documentación del propio cliente para conocer el comportamiento exacto en lugar de suponer que la etiqueta describe tu topología.

La distinción importa sobre todo en un diseño de túnel completo, donde el cliente sustituye deliberadamente la ruta predeterminada para que todo el tráfico pase por la VPN. Ese es el objetivo de todo el diseño, y también es lo que hace desaparecer las redes locales enrutadas. Nunca estuvieron cubiertas por una ruta propia; iban montadas sobre la ruta predeterminada que acaba de ser sustituida. Un cliente no puede enrutar lo que no sabe que existe, y solo aprende los prefijos conectados a su propia interfaz. Todo lo demás lo tiene que describir alguien que conozca la topología.

Las rutas conectadas se detienen en el primer router

Una estación de trabajo en 192.168.10.20/24 con puerta de enlace 192.168.10.1 obtiene automáticamente una ruta conectada para 192.168.10.0/24. La VLAN de almacenamiento en 192.168.20.0/24 es un prefijo distinto, accesible solo a través de esa puerta de enlace, y la estación no tiene ninguna ruta para ella más allá de la predeterminada. Antes de que suba el túnel, la ruta predeterminada ordinaria envía por casualidad el tráfico de almacenamiento a 192.168.10.1 y todo funciona.

Cuando la VPN instala una ruta predeterminada de túnel completo, los paquetes para 192.168.20.1 siguen la nueva ruta predeterminada hacia el túnel. La puerta de enlace remota no tiene ni idea de dónde vive ese prefijo, así que los descarta o los reenvía a un lugar inútil. Nada estaba mal configurado en la VLAN de almacenamiento; su camino era prestado, y el préstamo fue reclamado.

La tentación es recurrir a una excepción amplia, como un par de rutas /1 o una segunda ruta predeterminada. Resístete. Cuanto más estrecha es la excepción, más fácil resulta explicarla, auditarla y eliminarla cuando la red cambia.

Pon la excepción en la tabla que gana

Dentro de una sola tabla de enrutamiento, una /24 vence a una /0 o una /1 por coincidencia de prefijo más larga, así que una ruta concreta hacia la VLAN de almacenamiento por la puerta de enlace local basta, siempre que la tabla se consulte. En Linux la forma habitual es breve:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

El enrutamiento por políticas complica esa garantía. Una regla anterior puede enviar el tráfico a una tabla cuya propia ruta predeterminada apunta hacia el túnel, y entonces la tabla principal que contiene tu /24 nunca se alcanza. Revisa las reglas antes de dar por hecho que la ruta es autoritativa, porque una entrada que parece correcta en la tabla equivocada explica un fallo que parece una ruta rota.

Después haz que la entrada sea persistente mediante el mecanismo que admita el cliente o el gestor de red que posee la interfaz. Una ruta escrita en el indicador desaparece en la siguiente reconexión, y una ruta atada a una sola puerta de enlace Wi-Fi no es portable a la siguiente red que visite el portátil.

Los nombres y las políticas no siguen las rutas

Arreglar la ruta restaura los paquetes, no los nombres. Si los dispositivos locales se resuelven mediante un resolutor impuesto que no sabe nada de ellos, el montaje sigue fallando aunque la dirección sea alcanzable. Los nombres locales necesitan un arreglo local o de DNS dividido, y esa es una decisión separada de la excepción de ruta.

La política vuelve a ser otra cosa. El filtro de acceso local de un cliente VPN puede prohibir deliberadamente el tráfico hacia rangos privados, y una ruta no anula esa regla. En una red no confiable, una dirección privada tampoco es prueba de que el destino sea tu servidor de almacenamiento, así que la excepción debería ser tan concreta como la propia ruta.

Un contrato que puedes entregar

El diseño terminado debería leerse como una lista corta: el tráfico general de internet sigue el túnel, y estos prefijos locales con nombre conservan su camino por el router local. Anota los prefijos, el siguiente salto y el sufijo DNS que va con ellos, y mantén la lista lo bastante corta para que alguien pueda verificarla sin leer una tabla de enrutamiento.

Ojo con el solapamiento entre rangos locales y remotos. Una VLAN de almacenamiento que comparte prefijo con algo detrás de la VPN se resolverá a la ruta que sea más específica, y el comportamiento resultante es confuso de una forma que parece intermitente. Renumerar un lado suele ser más barato que depurar la ambigüedad para siempre.

Prueba el contrato dos veces: una con el túnel levantado y otra con él bajado. Si el camino local solo funciona en uno de esos estados, la excepción todavía no es un contrato.