SSH non escoita tras reiniciar: a dirección VPN chega tarde

Liga SSH á dirección do túnel durante a configuración, funciona, e tras o seguinte reinicio ninguén pode iniciar sesión ata que alguén reinicia o servizo á man. As credenciais non son o problema. O daemon pediu ao núcleo unha dirección que aínda non existía, o enlace fallou e a mensaxe pasou de longo no rexistro de arranque. O que parece un problema de autenticación é un problema de orde de arranque.

Que di realmente o erro de enlace

Un socket de escoita debe crearse nunha dirección que exista nese momento. Cando a interface VPN aparece máis tarde, un daemon configurado para enlazarse só á dirección do túnel non ten a que adherirse. A configuración segue sendo sintacticamente válida; simplemente a contorna non estaba lista. Un servizo que leva funcionando desde un arranque manual nunca percorre a ruta de arranque, por iso o fallo só aparece no seguinte reinicio. Compare a marca de tempo do enlace fallido coa da asignación da dirección e a orde vólvese obvia.

A validez da configuración e a dispoñibilidade en tempo de execución son propiedades distintas. Probe ambas, porque unha delas falla sen dicir nada.

Que proceso posúe o porto

O daemon non sempre é o compoñente que crea o escoitador. A activación de sockets traslada esa responsabilidade a unha unidade, e entón reiniciar o daemon non cambia nada.

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

A listaxe de sockets mostra que proceso retén o porto e en que dirección, mentres que o volcado da unidade mostra se existe unha unidade de socket. Cando a activación está en xogo, a dirección pertence á unidade de socket e o ficheiro do daemon non é autoritativo. Lea o rexistro de arranque para coñecer o erro de enlace real en lugar de inferilo do síntoma. Unha unidade de socket ausente simplemente significa a disposición clásica, na que o daemon se enlaza directamente.

Faga explícita a dispoñibilidade, non unha espera

Un atraso fixo é unha conxectura que trata igual o hardware rápido e as redes lentas. Exprese a dependencia no seu lugar: espere a dirección e logo inicie.

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

Engada un comando ExecStartPre que se repita ata que apareza a dirección, ou ordene a unidade despois do obxectivo de rede concreto ao que pertence a interface. Ambos os enfoques rexistran a dependencia nalgún lugar que o seguinte administrador poida ler. O bucle necesita un tempo de espera, ou un VPN fallido deixa unha unidade colgada en lugar de informar dun fallo. Logo confirme que o daemon enlaza a dirección do túnel mentres a interface ordinaria segue rexida polas súas regras de filtrado.

Probe un arranque limpo e unha reconexión

Un reinicio manual cando todo está en liña non demostra nada sobre a orde de arranque. Reinicie a máquina co túnel configurado para levantarse automaticamente e observe se o escoitador aparece sen intervención.

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

Logo baixe e restableza o túnel, porque unha reconexión pode cambiar a dirección e un enlace codificado de forma fixa non a seguirá. Manteña unha ruta de recuperación fóra de banda durante as probas, para que un mal cambio de orde non o poida deixar fóra do host.

O criterio de éxito é un escoitador que aparece baixo a súa dependencia documentada, non un que alguén lembrou reiniciar.