Redémarrer un service sur OpenVPN up : les hooks battent tun0.device

Relier un service dépendant à tun0.device ressemble à un abonnement au tunnel, et ce n’est pas le cas. Une unité de périphérique reflète l’existence de l’interface, ce qui peut rester vrai pendant une connexion échouée et la reconnexion qui suit. Le service agit alors au mauvais moment, ou jamais, selon que l’interface a disparu entre-temps. Le hook qui décrit l’événement qui vous intéresse vraiment est celui qu’appelle OpenVPN, pas celui que systemd déduit.

Décidez de la condition dont le service a besoin avant de choisir le déclencheur, car les trois candidats ne sont pas interchangeables.

Ce que suit réellement l’unité de périphérique

systemd crée une unité de périphérique à partir de la vue du noyau sur une interface réseau, donc tun0.device devient actif quand l’interface apparaît et inactif quand elle est retirée. Avec persist-tun, un redémarrage doux garde l’interface en place, donc l’unité ne flappe jamais et rien de ce qui y est lié n’est déclenché. Même sans persistance, l’unité ne dit rien des routes, du DNS ni de la réponse de l’extrémité distante.

Cela en fait un mauvais substitut de « le VPN est prêt ». Un écouteur qui n’a besoin que de l’adresse locale peut se satisfaire de l’existence de l’interface, tandis qu’un service qui appelle une application sur le réseau distant a besoin de routes et d’accessibilité, que l’unité de périphérique ne peut pas exprimer.

up, route-up et up-restart signifient des choses différentes

up s’exécute après l’ouverture du périphérique TUN/TAP et la configuration de l’interface, ce qui est le bon moment pour un écouteur qui lie l’adresse attribuée. route-up s’exécute après l’installation des routes, sous réserve d’un éventuel délai de route configuré, et convient à un travail qui exige l’étape de routage terminée. Ni l’un ni l’autre ne prouve que l’application distante répond. Choisir entre eux est une question de ce dont le service a besoin, pas de quel hook sonne le plus abouti.

Avec persist-tun, les redémarrages réutilisent le périphérique, donc up ne s’exécute pas de nouveau à moins que up-restart ne soit défini. Cette option active le script up pour le cycle de vie de redémarrage documenté, et son environnement est réduit par rapport à un premier démarrage. Un script qui suppose l’environnement complet fonctionne à la première connexion et échoue à la suivante.

Déclencher l’action sans l’attendre

Un hook qui appelle systemctl restart de façon synchrone peut se bloquer contre une unité dont l’ordre attend le tunnel. systemctl --no-block try-restart vpn-dependent.service met la tâche en file d’attente et revient, ce qui empêche le hook de bloquer la connexion à laquelle il réagissait. try-restart n’agit que sur une unité en cours d’exécution, tandis que restart démarre aussi une unité inactive ; choisissez délibérément, pas par habitude.

Mettre en file d’attente n’est pas vérifier. Le hook renvoie un succès dès que la tâche est acceptée, donc la vérification doit avoir lieu dans le journal de l’unité cible ou dans son état réel d’écoute.

La politique de redémarrage vit dans l’unité, pas dans le hook

Une unité oneshot avec RemainAfterExit=yes reste active après la sortie de sa commande, et une seconde demande de démarrage ne fait rien parce que systemd la considère déjà démarrée. C’est une propriété autour de laquelle concevoir, pas un défaut à contourner par des appels de démarrage répétés. Si l’action doit s’exécuter à chaque connexion, l’unité a besoin d’une forme qui le permet.

After= ordonne les unités, et BindsTo= lie les durées de vie, mais ni l’un ni l’autre ne signifie « redémarre ceci chaque fois que le VPN se reconnecte ». Une unité liée au tunnel s’arrête quand le tunnel s’arrête ; elle ne se redémarre pas elle-même quand le tunnel revient, sauf si quelque chose la relance.

Testez trois reconnexions, pas une

Le démarrage à froid, un redémarrage complet du client et une reconnexion douce exercent chacun un chemin différent. La reconnexion douce est celle qui révèle un up-restart manquant, un environnement réduit ou une unité de périphérique qui n’est jamais devenue inactive. Lancez les trois et confirmez les deux sens : le service agit quand le tunnel monte, et il ne redémarre pas sur des changements de liaison sans rapport comme une itinérance Wi-Fi.

Gardez un chemin de récupération indépendant lorsque le service dépendant porte votre propre accès administratif. Un hook qui redémarre ce par quoi vous êtes connecté est un changement qui peut vous verrouiller dehors.