Exécutez les tâches après le VPN depuis le dispatcher, pas depuis if-up

Un script qui doit s’exécuter après la montée du VPN a besoin d’un événement de la part du composant qui possède la connexion. Un fichier déposé dans un ancien répertoire de hooks réseau n’est pas un rappel pour chaque VPN que NetworkManager, pppd ou un processus OpenVPN autonome peuvent créer. Chacun de ces propriétaires signale un événement différent avec un environnement différent, il faut donc identifier le propriétaire avant de choisir le hook. Sinon le script est correct et ne s’exécute simplement jamais.

Pour un VPN géré par NetworkManager, le dispatcher est le bon endroit, et vpn-up est la bonne action.

Utilisez vpn-up, pas l’événement de l’interface

Le dispatcher distingue up de vpn-up. Le premier signale une interface activée ; le second signale une connexion VPN activée. Que le Wi-Fi monte signifie seulement que la liaison sous-jacente existe ; le tunnel peut encore négocier, ou ne jamais s’authentifier.

Le script reçoit l’interface et l’action, tandis que les détails de connexion arrivent par l’environnement, dont l’UUID du profil et l’interface IP du VPN. Lisez ces variables au lieu de déduire l’identité à partir des noms de périphériques.

Limitez la correspondance à une connexion

Faites correspondre l’UUID de la connexion, ou une autre identité fournie par le dispatcher, plutôt qu’un préfixe tun ou ppp0. Les noms d’interface ne sont pas stables, plusieurs tunnels peuvent exister en même temps, et deux profils peuvent porter le même nom affiché. Faire correspondre un préfixe tun signifie que le script finira par se déclencher pour une connexion que personne ne voulait toucher. Il peut aussi se déclencher deux fois pour un profil lorsqu’une reconnexion reconstruit le périphérique.

Rendez la tâche idempotente. Un rappel qui ajoute une route à chaque appel finit par remplir la table de doublons, et c’est la seconde copie qui casse le routage.

Sachez ce que l’activation ne prouve pas

vpn-pre-up s’exécute avant que NetworkManager signale le VPN comme entièrement activé, et le gestionnaire attend ces scripts. N’utilisez une étape bloquante que lorsque la tâche y a réellement sa place, car une vérification lente retarde l’activation que tous les autres composants attendent.

La présence de routes ne prouve pas qu’une application écoute, qu’un nom privé se résout ou qu’une session utilisateur existe. Vérifiez-le séparément avec un délai borné, et signalez quelle couche a échoué au lieu de réessayer toute la chaîne.

Respectez le contexte dans lequel le script s’exécute

Les scripts du dispatcher s’exécutent en root, hors de toute session utilisateur. Ne supposez pas que l’environnement de l’utilisateur connecté, sa session graphique ou un trousseau déverrouillé soient disponibles. Personne ne devrait répondre à un contexte de bureau manquant en rendant chaque identifiant lisible par chaque processus. Gardez le travail de session utilisateur dans un service utilisateur ou un assistant de session que le rappel peut signaler sans usurper l’utilisateur.

La propriété et les permissions du script comptent aussi. Un fichier exécuté en root que n’importe quel utilisateur peut remplacer est une voie d’élévation de privilèges, et c’est une constatation indépendante de l’exactitude de la logique VPN.

Prévoyez la déconnexion qui ne se déclenche jamais

NetworkManager documente que vpn-pre-down n’est pas émis pour les déconnexions forcées, comme une fin inattendue ou une perte de connectivité. Un nettoyage construit uniquement autour d’un pre-down propre est donc incomplet par construction. Tout état partagé que le script modifie a besoin d’un autre propriétaire capable de le restaurer après un plantage, et ce chemin de rétablissement doit être testé plutôt que supposé.

Éprouvez le hook avec une connexion normale, une reconnexion, une déconnexion volontaire et un câble arraché. Enregistrez l’UUID, l’action et l’interface déclenchée, sans journaliser de secrets. Cet enregistrement est la seule preuve fiable que le hook s’est exécuté pour la connexion voulue, et c’est lui qui rend la prochaine modification sûre.