¿Inicias un cliente VPN por SSH? Fija antes tu propia ruta

Entras por SSH en un host de compilación, inicias allí el cliente VPN y la sesión deja de responder. Nada se ha caído y nada parece mal configurado en el sentido obvio. El cliente instaló una ruta predeterminada, así que las respuestas a tu estación de trabajo ahora salen por el túnel, donde la dirección de tu estación de trabajo no es enrutable. Lo interesante es que este resultado era previsible, y la solución es una ruta escrita antes de que arranque el cliente. Supongamos un servidor con una sola tarjeta de red, una puerta de enlace 192.0.2.254 y un administrador que se conecta desde 203.0.113.9.

Registra el camino antes de empezar

ip route show default nombra la puerta de enlace y la interfaz actuales, mientras que ip route get 203.0.113.9 muestra qué interfaz y qué dirección de origen usaría el núcleo para tu sesión. Guarda ambas salidas. Cuando el túnel suba, esos dos comandos deberían seguir describiendo el camino físico, y si describen el túnel en su lugar, la sesión ya vive de tiempo prestado.

La conexión ya establecida es la que importa, así que no valides solo con un inicio de sesión nuevo. Una sesión nueva puede tener éxito brevemente gracias a un estado que la antigua ya no tiene.

Fija la dirección en la propia configuración del cliente

Una ruta añadida a mano desaparece al reiniciar y compite con las actualizaciones de tabla del propio cliente, así que pon la excepción donde se gestiona la tabla. En OpenVPN la palabra clave net_gateway se resuelve a la puerta de enlace que existía antes del túnel, así que route 203.0.113.9 255.255.255.255 net_gateway mantiene exactamente una dirección fuera de él. WireGuard necesita otro enfoque porque wg-quick gestiona las rutas por sí mismo: establece Table = off y añade la excepción en PostUp, con un PostDown correspondiente que la elimine. Ambas formas expresan la misma intención, y ambas limitan la excepción a una dirección en lugar de debilitar el túnel para todo.

Para IPv6 la misma idea toma un prefijo de un solo host, y el caso del transporte encapsulado merece recordarse: si la conexión exterior del propio túnel vive en una dirección fija, esa dirección tiene que quedarse fuera del túnel que transporta, o el cliente enruta su propio transporte hacia sí mismo.

O saca la tabla principal de la ecuación

Cuando varios servicios del host deben conservar su camino normal, deja de editar la tabla principal y dale al cliente la suya. Un espacio de nombres de red con un par veth lo hace limpiamente: la ruta predeterminada del cliente vive en otra pila y solo los procesos iniciados dentro usan el túnel. El enrutamiento por políticas llega a un lugar similar para un destino, enviando el tráfico coincidente a una tabla dedicada cuya ruta predeterminada sigue apuntando a la puerta de enlace física. Cualquiera de los dos enfoques deja la tabla principal del host sin una nueva ruta predeterminada, y esa es la propiedad que mantiene a SSH respondiendo.

Ambos son más maquinaria que una sola ruta de host, y ambos valen la pena cuando más de una cosa en la máquina tiene que sobrevivir al túnel.

Asume que la fijación puede fallar

Una ruta ligada a tu dirección pública actual se rompe en el momento en que tu proveedor la reasigna. Un servidor remoto necesita entonces un camino que no dependa de esa dirección: una consola, una segunda interfaz de gestión o un host de salto que se quede fuera del túnel.

Dos salvaguardas cuestan diez minutos. Un vigilante que detiene el cliente si no aparece un inicio de sesión de confirmación en unos minutos convierte un bloqueo en un retraso, y una segunda sesión SSH mantenida abierta durante el cambio demuestra que la excepción funciona mientras el túnel está arriba. Los keepalives por sí solos no ayudan aquí, porque el camino ha desaparecido en lugar de estar inactivo; solo hacen que la muerte sea más fácil de notar.

Verifica en el orden que importa

Conecta el túnel, confirma que la ruta a tu dirección sigue saliendo por la puerta de enlace física y luego abre una sesión nueva. Si la sesión nueva funciona y la antigua muere de todos modos, la causa es el seguimiento de conexiones o un cortafuegos con estado, no el enrutamiento, lo que es una solución distinta.

Escribe la dirección fijada y el comando que lo demostró en el registro de cambios. La siguiente persona que inicie un cliente en ese host necesitará ambas cosas, y puede que la dirección ya haya cambiado para entonces.