El túnel completo de OpenVPN corta tu sesión SSH: arregla el camino de vuelta

Activar un cliente OpenVPN de túnel completo en una máquina a la que llegas por SSH puede cortar la sesión en un segundo, y la máquina no hace nada mal. El túnel no cambia cómo llegan los paquetes al servidor; cambia cómo salen las respuestas. En cuanto la ruta por defecto apunta a tun0, una respuesta a tu cliente SSH entra en la red del proveedor, que no tiene ruta de vuelta a tu dirección. La conexión se cuelga, el siguiente intento expira y el demonio sigue escuchando en el puerto 22 todo el tiempo.

Lee la tabla de enrutamiento antes de leer el registro del VPN. El registro dirá que el túnel subió, y tiene razón. La pregunta es a qué interfaz se entrega cada respuesta, y eso es una consulta por paquete contra una tabla que el túnel acaba de reescribir.

Por qué la respuesta sale por la puerta equivocada

Los paquetes entrantes siguen llegando por la interfaz física, porque un cliente VPN no puede cambiar cómo llega internet a la dirección pública de tu servidor. Las respuestas son una decisión aparte: para cada paquete, el núcleo busca el destino, y tras --redirect-gateway la entrada por defecto dice túnel. La salida del proveedor ve un destino que no sirve y descarta el paquete.

La propia protección de OpenVPN cubre exactamente un destino. El manual de la 2.6 describe --redirect-gateway como una secuencia: añade una ruta de host para el peer VPN a través de la puerta de enlace en uso antes del túnel, para que el tráfico cifrado no pueda volver dentro de sí mismo, y después sustituye la ruta por defecto. Esa ruta de host es solo para el peer. Tu cliente SSH es solo otra dirección de internet y no recibe excepción alguna.

Conviene descartar pronto un error de prefijo. ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 sin longitud coincide con la dirección única 0.0.0.0, no con internet; debe ser 0.0.0.0/0. Y si tomar la ruta por defecto rompe el transporte propio del túnel, añade el extremo como ruta de host por la interfaz física, usando la dirección real del proveedor.

Fija la dirección de tu cliente SSH para un arreglo inmediato

La reparación más rápida es una ruta de host para la dirección de tu cliente a través de la puerta de enlace que el servidor usaba antes de que existiera el túnel. Por tu parte, busca la dirección que verá el servidor y luego lee la tabla del servidor para conocer la puerta antigua:

curl -s https://ifconfig.co
ip route

En el servidor, añade la excepción antes de que arranque el cliente. Las direcciones de aquí son marcadores de posición; la forma es lo que importa:

sudo ip route add 80.128.240.55 via 192.168.178.1

Esta es la reparación usada en el caso reportado, y funciona de inmediato. También es frágil de dos maneras previsibles: la ruta desaparece al reiniciar y se vuelve incorrecta en el momento en que tu ISP te da otra dirección. Trátala como medida de emergencia y hazla duradera a propósito, mediante una unidad de red o un gancho del despachador, o acepta que es temporal y anota el camino de recuperación.

Impide que el cliente tome la ruta por defecto

La opción más limpia es impedir que el túnel sustituya la ruta por defecto. route-nopull, usado con --client o --pull, acepta las opciones empujadas excepto las rutas, block-outside-dns y las opciones de estilo DHCP como los servidores DNS, así que solo añades los prefijos que necesitas. Una herramienta más estrecha es un filtro de tracción, que descarta una directiva problemática y conserva el resto:

route-nopull
pull-filter ignore "redirect-gateway"

Usa una u otra, no ambas, y ten claro qué cambia. Sin ruta por defecto por el túnel, el servidor ya no navega por internet a través del proveedor; solo llega a lo que has enrutado explícitamente. Si el túnel completo era todo el propósito de la configuración, esta es la palanca equivocada y la ruta de host de arriba es la correcta.

Divide el camino de vuelta por origen o por conexión

Cuando la dirección entrante es estable, una regla de origen mantiene las respuestas locales sin tocar las rutas propias del túnel. Da a la dirección de la interfaz física su propia tabla con el prefijo LAN y la ruta por defecto física, y luego selecciona esa tabla para el tráfico que proviene de ella:

ip rule add from 192.168.1.11 table 128
ip route add table 128 to 192.168.1.0/24 dev eth0
ip route add table 128 default via 192.168.1.1

Esto funciona porque las respuestas a una conexión SSH entrante salen de la dirección a la que se conectó el cliente. Un caso reportado en el que cada servicio entrante debía seguir funcionando usó exactamente esta forma. Cuando la dirección entrante fluctúa o el camino es dinámico, marca la conexión: pon una marca conntrack en el primer paquete que llega por la interfaz física, cópiala a los paquetes de respuesta en OUTPUT y enruta los paquetes marcados por una tabla que apunta a la puerta de enlace física.

iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
ip route add default via 192.168.1.1 dev eth0 table 3412
ip rule add fwmark 4321 table 3412

Mantén distintas la marca de conexión, la marca de cortafuegos y el número de tabla mientras pruebas. Reutilizar un número para dos papeles produce una regla que parece correcta y acierta los paquetes equivocados. La entrada por defecto de la tabla también necesita via con la puerta de enlace LAN en un enlace Ethernet normal; una entrada dev eth0 desnuda solo funciona cuando la interfaz es punto a punto o el siguiente salto se resuelve de otra manera. El host Jessie reportado estaba en un enlace donde la forma desnuda funcionaba, lo que no es una regla de distribución que copiar.

Verifica sin quedarte fuera

No pruebes desconectando. Mantén la primera sesión abierta, sube el túnel y pregunta al núcleo qué camino tomaría tu propia dirección:

ip route get 80.128.240.55

La respuesta debería nombrar la interfaz física y la puerta de enlace antigua, no el túnel. Luego abre una segunda conexión SSH; esa es la prueba real, porque la sesión antigua puede sobrevivir con un estado que una conexión nueva no puede reproducir. Si la segunda se cuelga mientras la primera aún responde, la regla nunca coincidió con el tráfico que importa, y las marcas o la dirección de origen son donde hay que mirar.

Ten una consola fuera de banda disponible durante todo el ejercicio. Un servidor cuyo único camino de acceso es el túnel que acabas de romper no se puede reparar por ese túnel, y la reversión es más fácil cuando has anotado los números de tabla y los prefijos que añadiste.