OpenVPN redirect-gateway: qué hace cada indicador en las rutas

Conéctate con redirect-gateway en el perfil y la ruta predeterminada de tu máquina puede desaparecer, dividirse en dos o quedarse exactamente donde estaba, según indicadores que nadie lee dos veces. La opción cambia el estado de enrutamiento y nada más, así que la única prueba fiable de lo que hizo es la tabla que el cliente instaló después. Lo que sigue es la tabla tras una conexión, la ruta que mantiene vivo el túnel y el tráfico IPv6 que la directiva nunca afirma cubrir. Cada paso es un comando que puedes ejecutar en el cliente mientras el túnel está activo.

Qué hace cada indicador en la ruta predeterminada

Sin ningún indicador, la opción elimina la ruta predeterminada normal y pone el túnel en su lugar, así que la puerta de enlace antigua desaparece de la tabla mientras la conexión está activa. Añade def1 y esa ruta predeterminada sigue en la lista, con dos rutas más estrechas haciendo el trabajo. Añade bypass-dhcp y la ruta DHCP también sobrevive, lo que importa en una red donde el cliente todavía tiene que llegar al servidor DHCP local. La lista de indicadores de la página del manual de OpenVPN 2.6 es lo bastante corta para leerla una vez, y cada entrada cambia qué rutas acaban en la tabla.

Una opción empujada se comporta igual en cuanto llega, así que el perfil del cliente puede no contener nada mientras la tabla parece completamente redirigida. Es normal: el servidor envió los indicadores, el cliente los aplicó y el archivo local nunca mencionó la directiva. Cuando un envío parece no hacer nada, revisa el filtro del lado del cliente que acepta o descarta las opciones extraídas, porque una opción descartada no genera error en ninguno de los dos extremos.

def1 gana por especificidad sin tocar tu ruta predeterminada

Dos rutas de medio defecto cubren entre ambas el espacio IPv4, 0.0.0.0/1 y 128.0.0.0/1. Cada una es más específica que 0.0.0.0/0, así que una consulta las prefiere mientras la ruta predeterminada real se queda en la tabla para todo lo que pide la coincidencia menos específica.

Lee la tabla en lugar del perfil, porque solo la tabla muestra en cuál de esos casos estás. Dos líneas bastan para distinguirlos:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Fíjate en la interfaz y la métrica de cada línea, no solo en el destino. Una ruta predeterminada que apunta al túnel y un par de medias rutas que apuntan al túnel describen la misma intención y fallan de forma distinta cuando el túnel cae, porque en un caso el respaldo sigue existiendo. Anota ambos campos en la nota de cambio. Un respaldo superviviente es a veces lo que mantiene viva una sesión remota el tiempo suficiente para reparar el túnel, y también es lo que filtra tráfico cuando la intención era un túnel completo.

Mantén accesible el extremo del túnel

El cliente necesita una ruta hacia el extremo lejano del túnel que no pase ella misma por el túnel. OpenVPN instala esa ruta de host antes de cambiar nada más, y una edición manual de rutas o un segundo cliente VPN pueden quitarla. El síntoma posterior es una conexión que dice estar conectada y luego no pasa nada.

Pregunta al núcleo qué interfaz usaría para la dirección del extremo mientras el túnel está activo. La respuesta debe nombrar la interfaz física y su puerta de enlace, nunca tun0:

ip route get 198.51.100.20

Si esa consulta devuelve el dispositivo del túnel, el túnel lleva su propio transporte y colapsará en cuanto un paquete tenga que salir. Los prefijos locales, un segundo adaptador y el enrutamiento por políticas siguen importando aquí, por eso una redirección que funciona en un portátil limpio puede fallar en un host con una interfaz de gestión y dos rutas predeterminadas. Normalmente se culpa al perfil de lo que hizo el plan de direcciones.

El tráfico IPv6 sigue usando su propia tabla

Redirigir IPv4 deja IPv6 tranquilo, y las dos familias se cambian con indicadores distintos. En un host de doble pila con una ruta v6 predeterminada que funciona, el tráfico v4 puede quedarse completamente dentro del túnel mientras cada destino capaz de v6 sale por el enlace físico. Un host que parece correcto en una tabla filtra en la otra.

Revisa la tabla v6 después de conectar en lugar de suponer que el túnel la cubrió. La directiva lleva indicadores de familia de direcciones justo por eso, y un perfil que los omite hereda lo que la plataforma hace por defecto:

ip -6 route show default
ip -6 route get 2001:db8::10

Demuestra qué interfaz usa una aplicación

Un estado conectado no es un bloqueo, y un cambio de ruta no es un interruptor de seguridad. Si el tráfico directo tiene que detenerse cuando el túnel falla, esa política vive en el cortafuegos y necesita su propia prueba.

Prueba el camino que una aplicación sigue realmente en lugar del camino que describe el perfil. Pide primero la ruta, luego vincula una solicitud a cada interfaz por turnos y compara lo que informa el lado lejano:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Si ambas solicitudes devuelven la misma dirección, la aplicación no usa el túnel aunque la tabla de enrutamiento diga que debería. Si solo tiene éxito la solicitud vinculada al túnel, el camino físico está filtrado para ese destino y el túnel hace lo que pediste. Escribe los indicadores, las rutas instaladas, la consulta del extremo y ambos resultados de salida en el registro de cambios, para que la siguiente persona herede hechos en lugar de una captura de pantalla.