Pourquoi une unité VPN démarre avant le réseau puis meurt

Démarrez la machine, connectez-vous et découvrez que le tunnel est monté puis mort quelques secondes plus tard. Le profil était correct, le certificat était correct, et la seule trace restante est le journal de ce démarrage. Ce qui s’est généralement produit est une course : l’unité a démarré avant que la machine ait une adresse, et l’ordre qu’elle déclarait ne signifiait pas ce qu’il paraît. Tout ce qui suit porte sur la preuve de cette course par les faits, puis sur sa fermeture correcte.

La cible est un point de rendez-vous, pas un gestionnaire

network-online.target n’a aucune idée de ce qu’est un réseau. C’est un point de coordination qui rassemble le service censé retarder le démarrage jusqu’à ce que le lien soit utilisable, et il délègue la définition au gestionnaire de réseau qui possède la machine. Sur la plupart des postes de travail et des serveurs, cela signifie un service d’attente fourni par NetworkManager ou par systemd-networkd. N’en activez aucun et la cible n’a rien à attendre : elle se termine donc à l’instant où quelque chose la tire, ce qui peut arriver bien avant que DHCP ne réponde. La ligne d’ordre de votre unité était honnête et malgré tout inutile.

La première question n’est donc pas ce que votre unité déclare. C’est si quelque chose sur cette machine fait réellement l’attente.

Lisez le dernier démarrage plutôt que le fichier d’unité

Les fichiers d’unité décrivent l’intention, et le journal décrit ce qui s’est passé. Demandez uniquement ce démarrage, avec des horodatages monotones afin que chaque message repose sur une seule horloge. Cherchez ensuite deux lignes : le moment où l’unité du tunnel a commencé à démarrer, et le moment où l’adresse est apparue ou où le service d’attente s’est terminé. Ordonnez ces deux nombres et la course est soit confirmée, soit écartée.

La vue des dépendances le corrobore. Si une chaîne critique pour l’unité du tunnel ne contient aucun service d’attente, rien sur ce chemin n’a retardé le démarrage, et la cible n’a pas fait le travail que vous supposiez. Deux vues, une conclusion.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

Ajoutez l’attente, puis la nouvelle tentative

Utilisez un drop-in plutôt que de modifier une unité empaquetée, afin qu’une mise à jour du paquet n’écarte pas le changement en silence. Deux directives comptent : l’unité doit être ordonnée après la cible, et elle doit tirer la cible dans la même transaction. L’ordre seul n’invoque pas la cible ; le désir le fait.

L’unité empaquetée du client OpenVPN porte déjà les deux. Les unités écrites à la main n’en portent généralement qu’une, ou aucune, ce qui vaut la peine d’être vérifié avant d’ajouter quoi que ce soit.

[Service]
Restart=on-failure
RestartSec=15

Pourquoi un sommeil fixe est un piège

Un sommeil dans ExecStartPre ressemble à une correction d’ordre et se comporte comme un délai avec des étapes en plus. Il ralentit chaque démarrage, y compris ceux qui étaient sains, et il perd encore lorsque le lien prend plus de temps que le nombre que vous avez choisi.

Pire, il cache si le service d’attente fonctionne, si bien que la panne suivante se présente comme un problème tout neuf plutôt que comme le même avec un autre minutage. Un court délai de redémarrage est le meilleur instrument : il ne coûte rien sur un démarrage sain et transforme une course perdue en une tentative de plus. Gardez l’intervalle modeste et laissez l’unité réussir. Si elle redémarre sans fin, le profil est cassé et aucune quantité de nouvelles tentatives n’y changera rien, alors lisez le journal au lieu d’augmenter l’intervalle.

Quand l’ordre est correct et que les noms échouent encore

Une unité active avec une route de tunnel signifie que l’ordre a fait son travail et que la panne restante se situe une couche au-dessus. La forme habituelle est un réglage de résolveur appliqué par le script up du tunnel avant que le lien ou le résolveur ne soit prêt à le conserver. Comparez l’état du résolveur pendant la panne à l’état après un redémarrage de l’unité du tunnel.

Si le redémarrage répare les résolutions, vous avez un défaut d’ordre de démarrage et non un mauvais serveur DNS, et ces deux cas demandent des corrections différentes. Prouvez ensuite l’ensemble par un démarrage à froid plutôt qu’un redémarrage de service, car un redémarrage s’exécute contre un réseau déjà monté et masquera exactement le défaut que vous traquez. Répétez-le avec un lien volontairement lent, et considérez comme toujours cassée une unité qui ne fonctionne que lorsque le réseau est rapide.