OpenVPN : la liaison locale échoue au démarrage — attendre ou réessayer

Pour un serveur OpenVPN qui ne démarre pas au boot, deux correctifs sont proposés : attendre l'adresse, ou laisser le service réessayer jusqu'à ce que la liaison réussisse. Les deux traitent le même symptôme avec un comportement d'échec différent. L'attente encode un prérequis précis et échoue bruyamment quand il manque ; la nouvelle tentative cache le prérequis et continue d'essayer. Laquelle appartient à votre unité dépend de si cette adresse est une dépendance conçue ou un accident de timing.

Les deux valent mieux qu'un sommeil fixe, qui n'attend rien et ne rapporte pas ce qu'il attendait.

Ce que l'option local exige réellement

local nomme l'adresse à laquelle le démon lie sa socket, et se lier à une adresse qui n'existe pas encore échoue immédiatement avec une erreur sur l'adresse demandée. Quand l'option est absente, le démon écoute sur toutes les adresses, ce qui explique pourquoi le même profil fonctionne sur une machine dont l'interface n'est pas encore montée : il écoute partout au lieu de l'unique adresse que vous avez nommée. Cette différence est tout l'échec, et elle reste invisible jusqu'à un redémarrage.

L'exigence n'est pas que l'interface soit active au sens général. L'adresse doit être attribuée à la bonne interface au moment de la liaison, et il doit s'agir de l'interface sous-jacente, non d'un tunnel que le même démon créerait plus tard. Une vérification faite quelques minutes après la connexion ne prouve rien sur la séquence de boot.

Attendre l'adresse ou réessayer la liaison

Attendre signifie un ExecStartPre qui interroge jusqu'à ce que l'adresse apparaisse, avec un nombre borné de tentatives et une sortie non nulle quand le temps est écoulé. Réessayer signifie laisser le processus principal échouer et demander au gestionnaire de services de le relancer, par exemple Restart=on-failure avec RestartSec=5. Le premier signale un prérequis manquant comme une unité en échec, tandis que le second le signale comme une série de redémarrages qui finit par s'arrêter, ce qui est plus bruyant dans le journal mais survit à une adresse qui arrive tard pour des raisons que vous ne pouvez pas prévoir.

Préférez l'attente quand l'adresse est une dépendance conçue, et la nouvelle tentative quand l'adresse apparaît habituellement mais que son timing varie. Les combiner est raisonnable : une attente bornée couvre le cas courant et une politique de redémarrage l'exception. Ce qu'aucune des deux ne doit faire, c'est tourner indéfiniment, car une unité qui réessaie sans fin masque une mauvaise configuration au lieu de la signaler.

Pourquoi network-online.target ne suffit pas

network-online.target promet ce que l'implémentation réseau active entend par en ligne, et rien de plus. Avec systemd-networkd, systemd-networkd-wait-online décide quand cette cible est atteinte, et sa notion par défaut d'être en ligne peut être satisfaite avant que votre adresse précise existe. Sous NetworkManager, le service wait-online applique ses propres règles. Ordonner après la cible est une base saine, pas une garantie qu'une adresse, une réponse DNS ou un pair distant soit prêt.

Le même raisonnement écarte les alternatives habituelles. Une entrée de démarrage automatique de bureau attend une session utilisateur qui ne s'ouvrira peut-être jamais sur un serveur, et une commande cron différée ajoute du temps écoulé sans nommer la ressource dont elle espérait l'apparition. Les deux peuvent sembler réussir pendant des mois puis échouer au seul boot qui compte.

Vérifiez la liaison après un démarrage à froid

Vérifiez par un vrai démarrage à froid plutôt que par un redémarrage du service, car un redémarrage hérite d'une adresse que la séquence de boot a dû créer. Après le démarrage, ss -lntp ou ss -lunp montre l'adresse locale à laquelle chaque écouteur s'est réellement lié, et journalctl -b -u openvpn-server@server montre si la première tentative a échoué. Comparez l'adresse liée à celle du profil, puis répétez la comparaison après une reconnexion réseau.

Si le profil n'a jamais eu besoin d'une adresse fixe, supprimer local est une simplification légitime, mais faites-en une décision de sécurité plutôt qu'une habitude de dépannage.

Élargir l'écouteur change qui peut l'atteindre, alors associez ce changement à la politique de pare-feu qui aurait dû le restreindre. Un service qui démarre de façon fiable sur toutes les interfaces n'a pas résolu le problème d'origine ; il a déplacé le problème vers la bordure du réseau.