El túnel completo mató tu sesión SSH: fija la ruta de retorno

Inicia un OpenVPN cliente en la máquina en la que trabajas por SSH, y a mitad de comando la sesión se congela. El túnel se declara conectado, el host llega a internet a través de él y tus pulsaciones siguen llegando mientras no vuelve nada. Lo que cambió no es el túnel: es la ruta de retorno de los paquetes dirigidos a ti, que ahora coincide con la nueva ruta por defecto y entra en un túnel que la pasarela remota no usará para llegar a tu escritorio.

Qué instala en realidad redirect-gateway

En su forma def1, redirect-gateway añade 0.0.0.0/1 y 128.0.0.0/1 en lugar de sobrescribir la ruta por defecto. Esas dos mitades cubren todo el espacio de direcciones y ambas siguen siendo prefijos más largos que 0.0.0.0/0, así que cualquier destino sin una coincidencia más específica entra ahora en el túnel. Ese es el mecanismo que hay que retener, porque cada arreglo de los siguientes funciona instalando una coincidencia más específica.

Tu dirección administrativa es uno de esos destinos.

El servidor VPN reenvía el tráfico de sus clientes hacia internet. No tiene ruta para la dirección pública desde la que te conectas, ni motivo para tratar esos paquetes como algo distinto del tráfico que llega de un cliente, así que los descarta. Mientras tanto, la petición que enviaste sí llegó al host, y por eso la sesión parece viva solo en un lado.

ip route show table main | head -n 20
ip route get 198.51.100.23

Encuentra tu dirección de origen y la ruta anterior al túnel

En el servidor, lista la conexión SSH establecida y anota la dirección del par desde la que llegó. Esa dirección es la que debe cubrir tu ruta de retorno, y no siempre es la que crees: un host de salto, una pasarela NAT o un traductor de operador pueden sustituir el origen por otro.

Después busca la pasarela física y la interfaz que transportaban el tráfico antes de que arrancara el túnel. En la def1 disposición la ruta por defecto sigue presente bajo las medias rutas por defecto, así que la información está disponible, aunque leer a ojo una tabla de rutas larga invita a errores.

Anota los dos valores y el nombre de la interfaz juntos, porque la ruta que vas a añadir necesita los tres. Si el host usaba una regla de enrutamiento por políticas para elegir su enlace ascendente, puede que una ruta simple no se consulte en absoluto, y esa posibilidad cambia el arreglo.

Fija una ruta de host que supere a las medias rutas por defecto

Una ruta /32 es más larga que cualquiera de las dos medias rutas por defecto, así que las respuestas a tu dirección la toman con preferencia al túnel. El siguiente salto es la pasarela anterior al túnel y el dispositivo es la interfaz física, lo que mantiene el paquete en el camino que usaba antes de que existiera el túnel.

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

Verifica con una consulta en lugar de inspeccionar la tabla: la respuesta debe nombrar eth0 y la pasarela, nunca tun0.

OpenVPN ya añade una ruta de host hacia la propia dirección del servidor VPN por la misma razón, así que el patrón resulta familiar y la dirección administrativa es simplemente otra excepción. No recurras a route-nopull para arreglar esto, porque descarta las rutas empujadas que el túnel necesita, incluida la red remota y las opciones de DNS.

Haz que sobreviva a una reconexión

Una ruta añadida a mano desaparece cuando el cliente se reconecta y reinstala la suya, lo que convierte un arreglo en una caída recurrente. Engancha el comando a algo que se ejecute después de instalarse las rutas.

Tanto un script route-up como el hook pre-up del gestor de red sirven, y la comprobación fiable es una reconexión seguida de la misma consulta.

En Windows el equivalente es una ruta persistente añadida con -p, que sobrevive a los reinicios pero aún debe apuntar a la pasarela correcta tras un cambio de red. Sea cual sea la plataforma, escribe el motivo junto a la ruta: el siguiente administrador necesita saber que existe para proteger una sesión de gestión, no porque el diseño de la red lo exigiera.

Cuando una ruta fijada todavía no basta

El filtrado de ruta inversa puede descartar un paquete que llega por una interfaz y sale por otra, que es justo lo que crea una ruta fijada. Comprueba el valor efectivo de rp_filter antes de desactivar nada de forma global, y prefiere corregir la asimetría a apagar la comprobación. La configuración por interfaz es la que se aplica, y el modo loose a menudo solo registra la asimetría en lugar de descartar el paquete. Lee ambas cosas antes de concluir que el filtro tiene la culpa.

Los hosts con enrutamiento por políticas necesitan una regla además de una ruta, porque la base de reglas elige la tabla antes de que se consulte la ruta que contiene. Una ruta de la tabla main es invisible para un flujo que coincide con una regla que apunta a otra tabla. Lee las reglas antes de añadir nada a main. Si una regla ya cubre el tráfico de gestión, la excepción pertenece a la tabla de esa regla.

Mantén abierta una consola fuera de banda mientras pruebas, y vuelve a comprobarlo desde un segundo inicio de sesión antes de desconectar el que estás usando. Una ruta que manda tu propio tráfico de gestión al túnel corta la conexión a través de la cual la estás reparando. Volver a entrar entonces exige una consola serie o un arranque de rescate, que es un mal cambalache por saltarse un paso de verificación.