Pourquoi votre client OpenVPN reste arrêté après un seul délai d’attente

Lundi matin : le tunnel monté vendredi a disparu, l’interface est toujours listée et rien dans le journal ne dit que quelqu’un l’a remarqué. L’hôte est en ligne, le tableau de bord est vert, et tout ce qu’il a envoyé pendant le week-end est sorti par l’interface physique. Deux décisions indépendantes manquent ici : l’une sur la survie du processus client à une défaillance passagère, l’autre sur le redémarrage du processus par quelque chose au-dessus après sa sortie. Corriger une seule des deux laisse l’autre trou ouvert.

Partez de ce que l’unité a réellement fait, pas de ce que la supervision prétend. systemctl status openvpn-client@office et journalctl -u openvpn-client@office -n 50 montrent la raison de la sortie et la dernière ligne écrite par le client avant de partir.

Le processus s’est arrêté avant que quiconque le remarque

Un client qui disparaît sans erreur est généralement sorti exprès. Le profil décide de ce comportement, pas le gestionnaire de services : ping-exit termine le processus dès que le pair cesse de répondre, tandis que ping-restart conserve le processus et se reconnecte à l’intérieur. Les limites de session et les minuteries d’inactivité produisent de l’extérieur la même image : sans tunnel et sans alarme.

Les deux directives ping ne peuvent pas figurer ensemble dans un profil, choisissez-en donc une et consignez le choix. Regardez aussi le serveur, car son propre ping-exit ferme une session quoi que le client ait demandé, et seul le journal du serveur note qui a pris cette décision.

Choisir entre ping-exit et ping-restart

Choisissez ping-restart pour un portable ou un site distant qui doit se réparer seul, et réservez ping-exit aux cas où un tunnel mort doit arrêter le processus pour que quelque chose d’autre puisse agir dessus. Les chiffres comptent moins que la relation : ping 10 avec ping-restart 60 signifie dix secondes de silence avant une sonde et soixante avant le redémarrage, ce qui est agressif sur une liaison mobile avec pertes et raisonnable sur une liaison filaire. Écrivez la raison à côté de la ligne, sinon le lecteur suivant supposera que les valeurs par défaut étaient délibérées.

Confirmez ensuite que c’est bien le processus qui est sorti. Une unité qui se déclare active alors que le tunnel est mort est une autre panne, traitée plus bas.

Une supervision qui redémarre vraiment l’unité

Sur un hôte systemd, le plus petit changement durable est un seul fichier drop-in : Restart=on-failure et RestartSec=10 dans /etc/systemd/system/[email protected]/restart.conf. Un drop-in n’est lu que lorsque systemd recharge ses propres définitions, exécutez donc systemctl daemon-reload ensuite. Vérifiez avec systemctl show -p Restart -p ExecMainStatus openvpn-client@office au lieu de supposer que la valeur est arrivée. L’instance du nom de fichier doit être le profil que l’unité charge réellement, aussi un fichier écrit pour office ne fait rien pour openvpn-client@home.

on-failure ignore un cas : une sortie propre dont le statut est zéro. Certaines séquences de démontage finissent ainsi, lisez donc le statut enregistré au lieu de croire la formulation d’une page de manuel. Si votre client abandonne avec un zéro, il vous faut Restart=always, et le coût est qu’un profil vraiment cassé revient sans cesse jusqu’à ce que la limite de débit de démarrage se déclenche et que le journal se remplisse.

Restart=always se déclenche aussi après un arrêt délibéré. Utilisez systemctl stop pour la maintenance, et masquez l’unité si elle doit rester arrêtée pendant votre travail.

Attraper la fuite pendant que le tunnel est arrêté

La supervision ramène le tunnel ; elle n’empêche pas le trafic de sortir pendant que le tunnel est absent. persist-tun conserve l’appareil et ses routes entre les reconnexions, ce qui est pratique et ouvre une fenêtre. L’appareil survit, les routes pointent toujours vers lui et les paquets s’écoulent sans protection et sans rapport. C’est un choix de politique, pas une valeur par défaut neutre.

Quand un hôte ne doit à aucun prix émettre de paquets non protégés, seul le pare-feu peut le garantir. Une règle de sortie qui autorise l’interface du tunnel et l’adresse du serveur VPN tout en rejetant le reste tient encore après la mort du client, et rien dans la configuration du client ne peut filtrer un trafic que le client ne transporte pas.

Testez-le en arrêtant le client exprès. Exécutez systemctl stop openvpn-client@office, puis curl -m 5 https://example.com, qui devrait échouer au lieu de réussir par la liaison physique. Un succès signifie que la règle de pare-feu manque ou est trop permissive.

Reconnectez, confirmez que le tunnel transporte de nouveau du trafic, et seulement alors ajoutez le contrôle à la supervision. Sonder ip addr depuis cron pour un appareil tun est la supervision qui échoue le plus souvent, car avec persist-tun l’appareil survit à la session et la sonde signale la santé alors que rien n’est transporté.