SSH non ascolta dopo il riavvio: l’indirizzo VPN arriva tardi

Si lega SSH all’indirizzo del tunnel durante la configurazione, funziona, e dopo il riavvio successivo nessuno può accedere finché qualcuno non riavvia il servizio a mano. Le credenziali non sono il problema. Il demone ha chiesto al kernel un indirizzo che non esisteva ancora, il binding è fallito e il messaggio è scorso nel log di avvio. Quello che sembra un problema di autenticazione è un problema di ordine di avvio.

Che cosa dice davvero l’errore di binding

Un socket in ascolto deve essere creato su un indirizzo che esiste in quel momento. Quando l’interfaccia VPN compare più tardi, un demone configurato per legarsi solo all’indirizzo del tunnel non ha nulla a cui attaccarsi. La configurazione resta sintatticamente valida; semplicemente l’ambiente non era pronto. Un servizio che gira da un avvio manuale non percorre mai il percorso di avvio, ed è per questo che il guasto compare solo al riavvio successivo. Confrontate l’ora del binding fallito con quella dell’assegnazione dell’indirizzo, e l’ordine diventa evidente.

La validità della configurazione e la prontezza a runtime sono proprietà separate. Provate entrambe, perché una delle due fallisce senza dire nulla.

Quale processo possiede la porta

Il demone non è sempre il componente che crea l’ascoltatore. L’attivazione via socket sposta quella responsabilità su un’unità, e allora riavviare il demone non cambia nulla.

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

L’elenco dei socket mostra quale processo tiene la porta e su quale indirizzo, mentre il dump dell’unità mostra se esiste un’unità socket. Quando l’attivazione è in gioco, l’indirizzo appartiene all’unità socket e il file del demone non è autorevole. Leggete il log di avvio per l’errore di binding reale invece di dedurlo dal sintomo. Un’unità socket assente significa semplicemente la disposizione classica, in cui il demone si lega direttamente.

Rendete esplicita la prontezza, non un’attesa

Un ritardo fisso è una supposizione che tratta allo stesso modo hardware veloce e reti lente. Esprimete invece la dipendenza: aspettate l’indirizzo, poi avviate.

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

Aggiungete un comando ExecStartPre che si ripete finché l’indirizzo non compare, oppure ordinate l’unità dopo il target di rete specifico a cui appartiene l’interfaccia. Entrambi gli approcci registrano la dipendenza in un punto che il prossimo amministratore può leggere. Il ciclo ha bisogno di un timeout, altrimenti un VPN fallito lascia un’unità appesa invece di segnalare un guasto. Poi confermate che il demone lega l’indirizzo del tunnel mentre l’interfaccia ordinaria resta governata dalle vostre regole di filtro.

Provate un avvio pulito e una riconnessione

Un riavvio manuale quando tutto è online non dimostra nulla sull’ordine di avvio. Riavviate la macchina con il tunnel configurato per salire automaticamente e osservate se l’ascoltatore compare senza intervento.

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

Poi abbattete e ristabilite il tunnel, perché una riconnessione può cambiare l’indirizzo e un binding codificato in modo fisso non lo seguirà. Mantenete un percorso di ripristino fuori banda durante i test, così un cattivo cambio di ordine non possa chiudervi fuori dall’host.

Il criterio di successo è un ascoltatore che compare sotto la sua dipendenza documentata, non uno che qualcuno si è ricordato di riavviare.