SSH n’écoute pas après le redémarrage : l’adresse VPN arrive trop tard

Vous liez SSH à l’adresse du tunnel pendant l’installation, cela fonctionne, et après le redémarrage suivant plus personne ne peut se connecter tant que quelqu’un ne redémarre pas le service à la main. Les identifiants ne sont pas le problème. Le démon a demandé au noyau une adresse qui n’existait pas encore, la liaison a échoué, et le message a défilé dans le journal de démarrage. Ce qui ressemble à un problème d’authentification est un problème d’ordre de démarrage.

Ce que dit réellement l’erreur de liaison

Une socket d’écoute doit être créée sur une adresse qui existe à cet instant. Lorsque l’interface VPN apparaît plus tard, un démon configuré pour ne se lier qu’à l’adresse du tunnel n’a rien à quoi s’accrocher. La configuration reste syntaxiquement valide ; l’environnement n’était simplement pas prêt. Un service qui tourne depuis un démarrage manuel ne parcourt jamais le chemin de démarrage, ce qui explique que la panne n’apparaisse qu’au redémarrage suivant. Comparez l’horodatage de l’échec de liaison à celui de l’attribution de l’adresse, et l’ordre devient évident.

La validité de la configuration et la disponibilité à l’exécution sont des propriétés distinctes. Testez les deux, car l’une d’elles échoue sans rien dire.

Quel processus possède le port

Le démon n’est pas toujours le composant qui crée l’écouteur. L’activation par socket transfère cette responsabilité à une unité, et redémarrer le démon ne change alors rien.

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

La liste des sockets montre quel processus détient le port et sur quelle adresse, tandis que le vidage de l’unité montre si une unité socket existe. Lorsque l’activation est en jeu, l’adresse appartient à l’unité socket et le fichier du démon ne fait pas autorité. Lisez le journal de démarrage pour l’erreur de liaison réelle au lieu de la déduire du symptôme. Une unité socket absente signifie simplement la disposition classique, où le démon se lie directement.

Rendez la disponibilité explicite, pas une attente

Un délai fixe est une supposition qui traite le matériel rapide et les réseaux lents de la même façon. Exprimez plutôt la dépendance : attendez l’adresse, puis démarrez.

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

Ajoutez une commande ExecStartPre qui boucle jusqu’à ce que l’adresse apparaisse, ou ordonnez l’unité après la cible réseau spécifique à laquelle appartient l’interface. Les deux approches consignent la dépendance quelque part que le prochain administrateur pourra lire. La boucle a besoin d’un délai d’expiration, sinon un VPN en échec laisse une unité qui bloque au lieu de signaler une panne. Confirmez ensuite que le démon lie l’adresse du tunnel tandis que l’interface ordinaire reste régie par vos règles de filtrage.

Testez un démarrage propre et une reconnexion

Un redémarrage manuel une fois que tout est en ligne ne prouve rien sur l’ordre de démarrage. Redémarrez la machine avec le tunnel configuré pour monter automatiquement et observez si l’écouteur apparaît sans intervention.

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

Coupez ensuite le tunnel et rétablissez-le, car une reconnexion peut changer l’adresse et une liaison codée en dur ne la suivra pas. Gardez un chemin de récupération hors bande pendant les tests, afin qu’un mauvais changement d’ordre ne puisse pas vous verrouiller hors de l’hôte.

Le critère de réussite est un écouteur qui apparaît sous sa dépendance documentée, pas celui dont quelqu’un a pensé à redémarrer.