Pourquoi OpenVPN meurt-il au réveil de l’ordinateur portable ?

La veille peut tuer la session OpenVPN tout en laissant tun0 derrière elle. Testez le tunnel, puis redémarrez l’unité depuis un hook de veille systemd, pas l’appareil.

Mettez la machine en veille, réveillez-la, puis vérifiez trois choses dans cet ordre avant de toucher à la moindre configuration : si tun0 existe encore, si la route vers une adresse interne le choisit toujours et si le serveur liste encore ce peer. Un appareil qui survit à la veille alors que la route pointe ailleurs est un résidu, pas un tunnel. Quand la route est correcte et que le trafic meurt quand même, la faute se situe au-dessus du tunnel et redémarrer le client n’y changera rien. Automatiser un redémarrage n’a de sens qu’après qu’un test manuel a montré lequel de ces trois cas vous avez.

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

Reproduisez le réveil avant de l’automatiser

La mise en veille termine la session chiffrée plus souvent qu’elle ne retire l’appareil. Le flux UDP qui gardait le tunnel en vie s’arrête, le serveur peut abandonner le peer, et le client soit le remarque et se reconnecte, soit conserve une interface sans rien derrière elle. Un simple contrôle de l’interface prouve peu, parce que un appareil obsolète ressemble exactement à un appareil qui fonctionne tant que des paquets ne doivent pas le traverser. Lancez la recherche de route plus une requête réelle à travers le tunnel, puis lisez le journal autour du moment du réveil.

Si le client revient tout seul, un hook ajoute de l’agitation au lieu de la fiabilité. S’il ne se rétablit jamais, l’automatisation est la solution honnête.

Où vit réellement un hook de veille systemd

Beaucoup de guides anciens pointent vers /etc/pm/sleep.d, un répertoire appartenant à pm-utils et jamais consulté par une mise en veille basée sur systemd. systemd lit les hooks dans /usr/lib/systemd/system-sleep/ et /etc/systemd/system-sleep/, en passant d’abord la phase puis l’opération, si bien que pre et post sont les seules valeurs sur lesquelles un hook se branche. Gardez la copie locale sous /etc au lieu de modifier un fichier empaqueté, et rappelez-vous que le script s’exécute en root au milieu de la transition, il doit donc revenir vite.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart ne touche une unité que si elle est déjà active, donc un tunnel que vous avez arrêté exprès reste arrêté pendant le réveil. --no-block empêche le hook d’attendre pendant que le client négocie, ce qui compte quand le réseau n’est pas encore monté. Ensemble, les deux options signifient un hook qui échoue en silence au lieu de retenir toute la séquence de réveil. Quand l’unité est déjà arrêtée, il ne se passe absolument rien, ce qui est exactement le résultat souhaité.

Récupérez le service, laissez tun0 tranquille

Abaisser tun0 à la main laisse le démon surveiller une interface qu’il ne possède plus, et le changement d’état suivant produit des erreurs déroutantes. Visez le service ou son profil de connexion plutôt que l’interface ; vérifiez d’abord le nom exact de l’unité, car les paquets de distribution, OpenVPN 3 et NetworkManager choisissent tous des noms différents. Un profil NetworkManager revient quand cette connexion est recyclée, donc l’unité systemd n’est pas la cible là. Quel que soit le mécanisme, ce devrait être la même action que celle vérifiée à la main.

Un redémarrage réinstalle les routes que le client a poussées lors de la connexion. La plupart des réveils le souhaitent. Une machine où vous avez ajouté vos propres chemins non, alors revérifiez-les au lieu de supposer que la récupération les a restaurés, et notez-les là où le prochain réveil pourra les trouver.

Gérez le calendrier que vous ne contrôlez pas

L’association sans fil et le DHCP se terminent souvent après l’exécution du hook, donc un redémarrage peut échouer alors qu’aucun chemin vers le serveur n’existe encore. Attendez brièvement cette adresse, réessayez une fois et consignez le résultat.

La résolution de noms est une course séparée, car la pile réseau du bureau peut restaurer le DNS après que le tunnel est déjà monté. Testez les requêtes séparément avec resolvectl query internal.example au lieu de les déduire d’une route fonctionnelle. Un tunnel qui route correctement et ne résout rien est un problème de DNS, pas un problème de hook.

Gardez la décision du hook visible en écrivant la phase, le nom de l’unité et le résultat dans le journal. Notez dans les notes de la machine quel test de réveil vous avez exécuté, afin qu’une récupération fonctionnelle se distingue d’une récupération chanceuse. Choisissez l’action la moins perturbante qui rétablit le service, et laissez un client qui se rétablit seul le faire. Un redémarrage complet coupe les sessions en cours, ce qui est un coût réel sur un portable qui se réveille plusieurs fois par jour.

Articles similaires