SSH por una segunda ruta privada mientras la VPN sigue activa

Una máquina llega a otra por una VPN, y ahora alguien quiere el mismo shell por una red privada de un proveedor. La ruta existe, el ping funciona y SSH sigue negándose. La causa habitual es que el demonio nunca escuchó en la dirección nueva, así que no hay nada a lo que conectarse. Este es un problema de vinculación de direcciones antes que un problema de cortafuegos.

Por qué una ruta nueva no crea un nuevo escucha

Un socket en escucha lo crea un proceso que nombra las direcciones que aceptará. Una ruta solo indica a los paquetes por dónde viajar; no crea un escucha en el destino. Cuando sshd se configura con un único ListenAddress, se rechazan las conexiones a cualquier otra dirección local aunque la interfaz esté activa. Lo mismo ocurre con una unidad de socket que posee el puerto, y por eso la primera comprobación siempre es qué está escuchando realmente.

Compare las dos rutas por la dirección de destino en lugar del nombre de la interfaz. Un cliente se conecta a una dirección, y esa dirección debe estar vinculada antes de que importe cualquier regla de cortafuegos.

Enumere las direcciones y los escuchas

Antes de editar nada, anote las direcciones del host y los sockets que existen ahora.

ip -br addr
ss -ltnp | grep ':22'

La lista de direcciones muestra qué dirección privada es real y en qué interfaz, mientras que la lista de sockets muestra si algo está vinculado a ella. Un escucha en 0.0.0.0:22 ya acepta todas las direcciones, así que una vinculación nueva no añade nada. Un escucha en una dirección concreta explica el rechazo de inmediato. Si el puerto pertenece a una unidad de socket y no al demonio, la configuración del demonio no es toda la historia.

Añada la vinculación y mantenga la antigua

OpenSSH acepta varias entradas ListenAddress, así que la ruta de la VPN puede quedarse mientras se añade la privada. Pruebe el archivo antes de recargarlo.

sshd -t
systemctl reload sshd

Una prueba de configuración fallida deja intacto el demonio en ejecución, y eso es justo lo que quiere mientras está conectado por la ruta que edita. Mantenga la entrada existente, añada la nueva dirección local y confirme que el servicio se recarga sin perder la sesión actual. En instalaciones activadas por socket, añada la dirección a la unidad de socket en su lugar y recargue esa unidad. Después vuelva a leer la lista de escuchas, porque una vinculación que nunca apareció significa que se editó el componente equivocado.

Verifique la sesión nueva antes de cerrar la antigua

Conéctese a la dirección nueva mientras la sesión original sigue abierta, usando salida detallada para ver qué dirección y qué clave se utilizaron. Mantenga la sesión original abierta hasta que la prueba tenga éxito dos veces.

ssh -v [email protected]

Lea las líneas de depuración de la dirección de destino y la clave de host que se presentó. Confirme la huella de la clave de host con un valor en el que ya confía, en lugar de aceptar una clave desconocida porque la red se describe como privada. El destino nuevo necesita su propia entrada en known_hosts, y eso es de esperar. Solo cuando funcione la ruta privada debería cerrarse la sesión de gestión antigua.

SSH protege el transporte, pero no hace que dos redes sean equivalentes por sí solo. Decida si la confianza del tránsito privado encaja con los datos antes de depender de ella.