Un hook de veille seul ne rétablit pas le VPN

Un hook qui sort avec zéro ne prouve qu'une chose : le script a tourné. Placez-le après le réseau, utilisez la bonne identité et vérifiez si le profil est même éligible.

Mettez une commande de reconnexion dans le hook de veille et le problème semble réglé. Il n'est réglé que si le hook s'exécute après l'existence du réseau, avec une identité que le client reconnaît, par un chemin que le client implémente réellement. La plupart des échecs après reprise sont l'un de ces trois, et aucun n'apparaît comme une erreur dans le hook lui-même. Le hook renvoie un succès dans tous les cas.

Un script qui sort avec zéro ne vous a rien dit sur le retour éventuel d'un tunnel.

Le hook s'exécute, et ensuite ?

#!/bin/sh
case "$1" in
  pre)
    vpn-client disconnect
    ;;
  post)
    vpn-client connect
    ;;
esac

Chaque événement appelle le hook deux fois, avant et après la transition, en lui remettant la phase et le nom de l'événement. Il s'exécute en root avec un environnement minimal, donc des chemins absolus sont nécessaires et aucune variable de session de bureau ne doit être attendue. Le retour rapide des deux appels dit seulement que le script a tourné. Que le profil soit monté ensuite est une observation distincte et exige sa propre preuve dans le journal.

Traitez l'argument de phase comme partie du design. Une tentative de reconnexion en phase pre se produit alors que la machine est sur le point de tout perdre, et elle ne peut pas réussir.

Root, environnement minimal, mauvais utilisateur

Si le client conserve son jeton de connexion par utilisateur, exécuter le hook en root le laisse sans rien à présenter. Vérifiez l'état sous l'identité que le hook utilise réellement, pas celle que vous avez testée depuis un terminal de bureau. Certaines versions laissent aussi un démon tenir l'interface après une déconnexion, si bien qu'une reconnexion atterrit dans un état périmé, et nettoyer le processus au préalable le rétablit au prix d'un arrêt sale. Aucun des deux comportements n'est visible si vous ne testez que le chemin heureux.

Écrivez le hook avec des chemins absolus, gardez-le propriété de root et exécutable, et journalisez ce qu'il a fait. Sans ce journal, l'enquête suivante repart de zéro.

La connexion automatique n'est pas le chemin du VPN

NetworkManager propose deux mécanismes d'activation : un indicateur de connexion automatique sur le profil, et des connexions secondaires qui démarrent lorsqu'un profil primaire s'active. Les types de périphériques natifs implémentent le premier ; les greffons VPN n'ont historiquement implémenté que le second, donc cocher la connexion automatique sur un profil OpenVPN peut n'avoir aucun effet. Inspectez les deux propriétés, puis rattachez plutôt le VPN comme secondaire du profil Wi-Fi ou Ethernet.

[Unit]
PartOf=NetworkManager.service
Requires=NetworkManager-wait-online.service
After=NetworkManager-wait-online.service

Une interface WireGuard gérée par une unité systemd a besoin de ce fichier complémentaire plutôt que d'un hook, ordonné après la mise en ligne du réseau.

Attendez le réseau, avec un plafond

timer=1
while ! ping -c1 -n -w1 203.0.113.1 >/dev/null; do
  sleep 1; timer=$((timer+1))
  [ $timer -ge 300 ] && exit 0
done
nmcli connection up "work-vpn"

À la reprise, le tunnel peut être demandé pendant que le Wi-Fi se réassocie encore, ce qui fait de toute attente fixe une conjecture. Attendez une adresse joignable, montez ensuite le profil, et plafonnez l'attente pour qu'un hook ne puisse pas garder le chemin de reprise ouvert indéfiniment. Préférez le nom du profil à un index numérique, et si le bon profil varie selon le réseau, faites consigner son choix dans un fichier à l'avance par le tunnel sain.

Prémunissez-vous aussi des tempêtes de redémarrage, en comptant les tentatives et en arrêtant. Un chien de garde qui réagit à chaque sonde échouée transforme une panne en boucle.

Suspendez une fois, puis lisez le journal pour la sortie propre du hook. C'est le seul test qui prouve l'ordre.

Articles similaires