SSH no escucha tras reiniciar: la dirección VPN llega tarde

Vincula SSH a la dirección del túnel durante la configuración, funciona, y tras el siguiente reinicio nadie puede iniciar sesión hasta que alguien reinicia el servicio a mano. Las credenciales no son el problema. El demonio pidió al núcleo una dirección que aún no existía, el enlace falló y el mensaje pasó de largo en el registro de arranque. Lo que parece un problema de autenticación es un problema de orden de arranque.

Qué dice realmente el error de enlace

Un socket de escucha debe crearse en una dirección que exista en ese momento. Cuando la interfaz VPN aparece más tarde, un demonio configurado para enlazarse solo a la dirección del túnel no tiene a qué adherirse. La configuración sigue siendo sintácticamente válida; simplemente el entorno no estaba listo. Un servicio que lleva funcionando desde un arranque manual nunca recorre la ruta de arranque, por eso el fallo solo aparece en el siguiente reinicio. Compare la marca de tiempo del enlace fallido con la de la asignación de la dirección y el orden se vuelve obvio.

La validez de la configuración y la disponibilidad en tiempo de ejecución son propiedades distintas. Pruebe ambas, porque una de ellas falla sin decir nada.

Qué proceso posee el puerto

El demonio no siempre es el componente que crea el oyente. La activación de sockets traslada esa responsabilidad a una unidad, y entonces reiniciar el demonio no cambia nada.

ss -ltnp 'sport = :22'
systemctl cat ssh.socket

El listado de sockets muestra qué proceso retiene el puerto y en qué dirección, mientras que el volcado de la unidad muestra si existe una unidad de socket. Cuando la activación está en juego, la dirección pertenece a la unidad de socket y el archivo del demonio no es autoritativo. Lea el registro de arranque para conocer el error de enlace real en lugar de inferirlo del síntoma. Una unidad de socket ausente simplemente significa la disposición clásica, en la que el demonio se enlaza directamente.

Haga explícita la disponibilidad, no una espera

Un retardo fijo es una conjetura que trata igual el hardware rápido y las redes lentas. Exprese la dependencia en su lugar: espere la dirección y luego inicie.

ip -4 addr show dev tun0
systemctl edit ssh.service

Añada un comando ExecStartPre que se repita hasta que aparezca la dirección, u ordene la unidad después del objetivo de red concreto al que pertenece la interfaz. Ambos enfoques registran la dependencia en algún lugar que el siguiente administrador pueda leer. El bucle necesita un tiempo de espera, o un VPN fallido deja una unidad colgada en lugar de informar de un fallo. Luego confirme que el demonio enlaza la dirección del túnel mientras la interfaz ordinaria sigue regida por sus reglas de filtrado.

Pruebe un arranque limpio y una reconexión

Un reinicio manual cuando todo está en línea no demuestra nada sobre el orden de arranque. Reinicie la máquina con el túnel configurado para levantarse automáticamente y observe si el oyente aparece sin intervención.

systemctl status ssh.service
ss -ltnp 'sport = :22'

Luego baje y restablezca el túnel, porque una reconexión puede cambiar la dirección y un enlace codificado de forma fija no la seguirá. Mantenga una ruta de recuperación fuera de banda durante las pruebas, para que un mal cambio de orden no pueda dejarlo fuera del host.

El criterio de éxito es un oyente que aparece bajo su dependencia documentada, no uno que alguien recordó reiniciar.