Cómo enviar un destino IPv4 fuera de un túnel OpenVPN

La mayoría de las configuraciones de túnel completo envían cada paquete por la VPN, y redirect-gateway es la directiva que lo hace posible. Un solo destino aún puede exceptuarse. Añadir una ruta de host para esa dirección con el marcador net_gateway le dice al cliente que llegue a ella por la puerta de enlace original de la máquina, mientras todo lo demás sigue usando el túnel.

La línea parece inofensiva y a menudo lo es, pero solo resuelve una pregunta: adónde van los paquetes de esa dirección IPv4 exacta. No cambia el DNS, IPv6, la política del cortafuegos ni qué proceso abrió la conexión, y cada uno de esos puede anular la excepción en silencio.

Qué nombra realmente net_gateway

La entrada del perfil para esa excepción es una línea: route 198.51.100.77 255.255.255.255 net_gateway. La primera dirección es un marcador de documentación para el destino, la máscara la convierte en una ruta de un solo host, y el último token nombra el marcador de la puerta de enlace. OpenVPN resuelve los marcadores de puerta de enlace cuando instala rutas. vpn_gateway significa la puerta de enlace propia del túnel, el lado lejano del enlace VPN. net_gateway significa la puerta de enlace predeterminada que tenía el host antes de que la VPN cambiara nada, que suele ser el router local de la red física.

Un tercer marcador, remote_host, se refiere a la dirección del servidor VPN, y existe para que el túnel pueda alcanzar el servidor por la ruta física. Confundir estos tres es la razón más común de que una excepción vaya al lugar equivocado o no se instale en absoluto.

El valor se lee en el momento de la conexión, no se escribe en el archivo. Si la máquina se traslada a otra red, la puerta de enlace previa a la VPN cambia y la ruta sigue a la nueva. Eso suele ser lo que se quiere, pero también significa que el comportamiento de la excepción depende de la red desde la que arrancó el cliente.

Por qué una ruta de host gana a la ruta predeterminada del túnel

El enrutamiento se decide por el prefijo coincidente más específico. redirect-gateway def1 normalmente no sustituye la ruta predeterminada; añade dos mitades, una ruta para la mitad inferior del espacio de direcciones y otra para la mitad superior, de modo que la ruta predeterminada original se conserva para otros usos. Esas mitades son más amplias que una sola dirección.

Una ruta para una dirección con máscara 255.255.255.255 es una /32, que es lo más específico que puede ser IPv4. Cuando se evalúa un paquete para esa dirección, la /32 coincide y gana sin importar qué ruta se instaló primero. Ese es el mecanismo detrás de la excepción, y funciona igual en Linux, macOS y Windows siempre que la ruta esté realmente presente.

Windows añade una segunda dimensión. Cuando dos rutas son igual de específicas, gana la de menor métrica, y un adaptador VPN puede llevar una métrica de interfaz que cambia el resultado. Una /32 sigue siendo más específica que las mitades, así que la excepción normalmente se mantiene, pero una ruta obsoleta de una sesión anterior puede producir un resultado confuso si es igual de específica.

Lo que la excepción no cubre

El DNS es la primera brecha. El cliente puede empujar ajustes de resolución internos, y el sistema operativo seguirá usándolos para las consultas. Una aplicación que resuelve un nombre antes de conectar puede recibir una dirección interna para un servicio que debería ir directo, o una dirección externa que se resuelve correctamente pero luego tropieza con la siguiente brecha.

IPv6 es la segunda. La directiva de ruta solo maneja IPv4. Un destino de doble pila puede preferir IPv6, que sigue el túnel o la ruta predeterminada IPv6 del host según la política, así que la excepción IPv4 nunca entra en juego. Necesita una ruta IPv6 coincidente, o una decisión deliberada de desactivar IPv6 para ese cliente.

El alcance de aplicación es la tercera. La regla se basa en el destino, así que cada proceso que se conecta a esa dirección usa la ruta directa, sea o no el que tenía en mente. A la inversa, un sitio web puede responder desde varias direcciones, así que exceptuar una /32 no exceptúa el sitio. Si el requisito real es el enrutamiento por aplicación, la tabla de rutas del cliente Community es la herramienta equivocada.

Comprobar la excepción sin engañarse

Empiece por la ruta instalada, no por un navegador. En Linux, pregunte al núcleo qué ruta y qué siguiente salto usará para la dirección concreta; en Windows, lea la tabla de rutas para esa /32. Confirme que la puerta de enlace es la física y no el túnel. Si falta la entrada, el perfil no se aplicó o el cliente no tenía el privilegio de cambiar rutas.

Luego pruebe dos destinos. Una petición a la dirección exceptuada debería salir por la interfaz física, y una petición a una dirección interna de control debería seguir usando el túnel. Probar solo la dirección exceptuada no demuestra nada sobre el resto del túnel, y probar un sitio web público prueba la dirección a la que ese sitio resolvió, que puede no ser la de la regla.

Por último, revise los controles que pueden anular la ruta. Un kill switch del lado del cliente o un ajuste block-outside-dns de Windows puede prohibir el tráfico directo, lo que se manifiesta como una conexión que falla aunque la ruta sea correcta. No desactive esos controles para que la excepción parezca funcionar; si la política prohíbe la ruta directa, la excepción es un problema de diseño para quien sea dueño del servicio VPN.

Vuelva a comprobarlo tras reconectar o cambiar de red, porque la puerta de enlace previa a la VPN y la ruta disponible son propiedades del momento, no del perfil.