Conserva el SSH local cuando el host usa una VPN de salida

Un pequeño servidor Linux ejecuta una VPN de salida para la aplicación que aloja, y el administrador todavía quiere llegar a él por SSH desde el escritorio de al lado. Es un requisito razonable, y normalmente no necesita ni redirección de puertos, ni dirección del proveedor, ni un agujero en el túnel. Lo que necesita es una ruta de gestión diseñada a propósito en lugar de heredada de lo que el cliente VPN hizo con la tabla de enrutamiento.

Los pasos siguientes asumen que el administrador está en la misma LAN.La administración remota es otro problema con otra respuesta.

Ata el SSH a la dirección que usan los administradores

Empieza por el listener.ss -ltnp | grep :22 muestra a qué está ligado sshd, y un listener en 0.0.0.0 acepta conexiones de todas las interfaces, incluido el túnel. Atarse a la dirección de la LAN es más estrecho y hace visible la intención:ListenAddress 192.168.10.20 en sshd_config, seguido de una prueba de configuración y una recarga. Una errata en esa dirección es más visible que un comodín, porque sshd se niega a arrancar cuando la dirección no existe.

Mantén la comprobación de clave de host y la autenticación por usuario exactamente como están. «Solo es la red local» no es un método de autenticación, y un canal de gestión que se salta la verificación de clave porque la ruta es corta es un canal de gestión esperando ser abusado. Una reserva DHCP o una dirección estática hace predecible el objetivo sin convertirlo en la identidad pública del servidor.

Mantén la ruta de la LAN fuera del túnel

Un host con una dirección en 192.168.10.0/24 tiene una ruta conectada para ese prefijo, y una ruta más específica gana a la predeterminada de la VPN dentro de la misma tabla. Por eso el SSH local a menudo sigue funcionando solo cuando el túnel sube. Verifícalo en lugar de asumirlo:ip route get 192.168.10.50 nombra la interfaz y la dirección de origen que usaría el núcleo, y la respuesta debería ser el dispositivo de la LAN, no el túnel. Repite la comprobación también desde la máquina del administrador, porque su propia tabla decide si los paquetes llegan siquiera. Dos hosts en el mismo cable pueden discrepar sobre qué dirección es alcanzable.

La suposición se rompe en dos lugares. Una regla de enrutamiento por política puede enviar tráfico a una tabla cuya predeterminada apunta al túnel antes de que se consulte la tabla principal. Un cliente VPN con función de bloqueo o kill-switch también puede bloquear tráfico que no entra en el túnel, sin importar lo que diga la tabla de enrutamiento.

Las VLAN de gestión enrutadas son el otro caso. Si el administrador está en 192.168.50.0/24 detrás del router local, el servidor necesita una ruta explícita para ese prefijo a través de 192.168.10.1, y esa ruta tiene que sobrevivir a una reconexión. Mantén la excepción específica para el prefijo de gestión; una excepción amplia para rangos privados anula el propósito del túnel.

Haz la excepción del cortafuegos tan estrecha como la regla

Si el host ejecuta un cortafuegos, permite SSH solo desde la fuente de gestión y solo en la interfaz de la LAN. Una regla que permite el puerto 22 desde cualquier lugar es más amplia que el requisito y más difícil de justificar en una revisión. En un host nftables la regla va en la cadena de entrada con la interfaz y la fuente coincidentes; en un host iptables el equivalente es un par de coincidencias en -i y -s. Comenta la regla con el grupo de administradores al que sirve, para que la próxima auditoría no tenga que adivinar por qué el puerto 22 está abierto.

Comprueba también el filtro propio del cliente VPN. Algunos clientes instalan reglas que descartan tráfico local por diseño, y una regla de cortafuegos correcta encima de un descarte a nivel de cliente no cambia nada. Lee la configuración del cliente antes de editar el cortafuegos del host, porque dos filtros en serie producen un fallo que no se parece a ninguno de los dos.

Prueba ambos estados

Ejecuta la prueba dos veces: una con el túnel conectado y otra con el túnel desconectado. En cada estado, confirma el listener, la ruta y un inicio de sesión SSH real desde la máquina del administrador. Una ruta que solo funciona mientras el túnel está levantado no es una ruta de gestión local; es una coincidencia.

Después reinicia el túnel mientras hay una sesión SSH abierta. Una sesión que sobrevive demuestra que el enrutamiento es estable; una sesión que cae te dice que el cliente reescribe rutas o filtros al reconectar, lo que vale la pena saber antes de un incidente más que durante uno.

Anota la dirección de origen desde la que probaste, porque una regla escrita para 192.168.10.50 falla en silencio cuando el portátil del administrador se mueve a otra subred.

Escribe la ruta de recuperación en el runbook

Decide ahora qué pasa si la VPN de salida rompe la ruta local. El acceso por consola, una segunda dirección de gestión o un procedimiento documentado para detener el cliente son todas respuestas legítimas, y cualquiera de ellas es mejor que descubrir el problema en el momento en que necesitas iniciar sesión. Si el servidor es remoto, la ruta local no existe, y el diseño correcto es una ruta de acceso remoto aprobada y separada o un bastión en lugar de un puerto público expuesto.

Mantén los dos papeles separados en la documentación: el SSH local para el administrador que está cerca, y el túnel de salida para el tráfico de la aplicación. Cuando esos papeles están escritos, un cambio futuro en cualquiera de los dos tiene un lugar obvio donde ser comprobado, y la siguiente persona no tiene que redescubrir por qué un servidor con una VPN sigue respondiendo en su dirección de la LAN.