Script d’arrêt ou règle de pare-feu : laquelle arrête la fuite ?

Deux conceptions promettent la même chose : quand le tunnel tombe, rien ne sort en clair. L’une exécute un script au démontage et coupe les interfaces. L’autre laisse une règle de pare-feu en vigueur et ne demande rien au client VPN. Elles diffèrent sur qui a le privilège d’agir, sur ce qui se passe pendant la brèche et sur la façon dont la machine revient en ligne ensuite. Les comparer sur ces trois points est plus utile que de discuter de laquelle est la plus stricte.

Le même travail par deux mécanismes

Le client peut exécuter des crochets quand le tunnel monte et quand il est démonté, à condition que le profil autorise l’exécution de scripts. Ce crochet s’exécute dans le cycle de vie du client, au moment où la connexion se ferme. Une règle de pare-feu, en revanche, appartient au système et ne se soucie pas de savoir si le client tourne, a planté ou a été tué.

Ce tableau est tout l’argument. Un script qui ne s’exécute qu’à une fermeture propre couvre le cas qui vous inquiétait le moins ; le cas qui compte est le plantage ou la disparition du réseau, et ni l’un ni l’autre ne produit un démontage propre.

Ce que le crochet de démontage peut faire et ne peut pas faire

Le schéma documenté parcourt les interfaces réseau et abaisse tout sauf loopback. Une fois l’appareil physique abaissé, rien ne peut s’échapper hors du tunnel, ce qui est exactement l’intention.

#!/bin/sh
for dev in /sys/class/net/*; do
  name=$(basename "$dev")
  [ "$name" = lo ] || ip link set dev "$name" down
done

Il abaisse aussi le réseau local, tout service hébergé par la machine et le chemin dont vous vous serviriez pour réparer le problème. Sur un portable, l’appareil sans fil a parfois besoin d’une bascule manuelle ensuite, si bien qu’une brève panne devient une séance de réparation. Pire, le crochet n’a peut-être pas le droit de faire quoi que ce soit de tout cela : lorsque le client abandonne ses privilèges, le script de démontage s’exécute sous le compte non privilégié et chaque changement d’interface échoue avec une erreur de permission écrite au moment précis où personne ne lit le journal.

Vérifiez comment le client est démarré avant de faire confiance au crochet. Un script qui fonctionne lancé à la main en root ne prouve rien sur le service qui démarre au démarrage du système.

Ce que la règle de pare-feu fait différemment

Une règle qui n’autorise que le trafic du tunnel continue de fonctionner quand le processus du client a disparu, car le noyau ne dépend pas de ce processus. La règle est aussi plus étroite : elle bloque exactement les flux qu’elle vise et laisse tranquilles loopback, le sous-réseau local et le chemin de récupération, ce qui explique pourquoi elle ne laisse pas la machine à l’abandon.

Le prix à payer est que la règle doit être écrite et maintenue par celui qui possède le pare-feu de l’hôte, et elle doit nommer l’appareil de tunnel que le client crée réellement. Cela signifie que la règle et le profil doivent être maintenus ensemble ; une interface renommée laisse un pare-feu qui bloque tout et n’explique rien.

Aucun des deux mécanismes ne rend l’autre redondant. Une règle de pare-feu jamais rechargée après une modification est aussi fictive qu’un script qui ne s’exécute jamais.

persist-tun décide s’il existe une brèche

Quand l’appareil de tunnel survit à une déconnexion, les routes qui pointent vers lui survivent aussi. Le trafic est alors rejeté plutôt que redirigé, si bien que la route par défaut ne retombe pas sur la passerelle physique. C’est ce comportement qui rend une fuite improbable avant même qu’une règle de pare-feu n’entre en jeu.

Sans ce réglage, l’appareil est supprimé et les routes avec lui, et la route par défaut peut de nouveau pointer vers la passerelle physique. Qu’elle le fasse dépend de la plateforme et du client, et c’est précisément pourquoi l’état doit être observé plutôt que supposé. Traitez le réglage comme une partie du kill switch, pas comme une option de performance.

Gardez le chemin de reconnexion vivant, puis testez quatre états

Un blocage strict peut aussi empêcher le client de se reconnecter, car le client a encore besoin d’une route vers le serveur via la passerelle physique alors que tout le reste est refusé. Installez une route d’hôte pour cette adresse unique avant que le tunnel ne monte, et résolvez d’abord le nom, car le DNS peut être bloqué au moment où vous en aurez besoin.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Vérifiez ensuite les états plutôt que l’étiquette. Exercez quatre moments délibérément : un démarrage à froid sans tunnel, une session saine, une chute que personne n’a demandée et la session après son rétablissement. À chaque moment, lisez la route par défaut et faites une requête dont l’adresse de sortie est visible. Une application qui abandonne pendant que le tunnel est bas ne dit rien d’un client de messagerie ni d’un outil de mise à jour, alors répétez la dernière vérification avec une application en arrière-plan. Notez la règle, les noms des interfaces et les étapes de récupération, car un kill switch que personne ne peut vérifier est une rumeur.