Un kill switch de VPN survit-il à un redémarrage ? Comment le vérifier

Redémarrer est la façon la plus courante de tester un kill switch, et c’est le test qui ment le plus souvent. La case à cocher du client est une préférence ; ce qui compte, c’est de savoir si quelque chose impose un blocage entre le moment où la pile réseau monte et le moment où le tunnel est réellement établi. Sous Windows, ce quelque chose est généralement un filtre dans la Windows Filtering Platform, sous Linux un jeu de règles chargé par une unité, sous macOS une ancre pf, sous Android les indicateurs propres au système pour always-on et verrouillage. Ces dispositions se comportent très différemment au fil d’un redémarrage, et seules celles au niveau de la plateforme sont en place avant que quiconque puisse ouvrir une session.

Un redémarrage pose trois questions distinctes

Séparez la question. Premièrement, la politique existe-t-elle sur le disque sous une forme que quelque chose lit au démarrage ? Deuxièmement, ce lecteur s’exécute-t-il avant que le moindre trafic puisse sortir ? Troisièmement, la politique couvre-t-elle le trafic qui vous importe, c’est-à-dire chaque processus, les deux familles d’adresses et le DNS. Un oui à la première et un non à la deuxième produisent exactement la défaillance que les gens rapportent comme un kill switch qui ne survit pas à un redémarrage : le trafic s’échappe pendant quelques secondes au démarrage, et personne ne le remarque avant qu’on aille regarder.

Gardez les couches séparées. Un jeu de règles de pare-feu enregistré, un service qui démarre au boot et une préférence du client sont trois objets différents avec trois durées de vie différentes. La préférence survit aux redémarrages parce qu’elle est une valeur dans un fichier de configuration. Les règles sont la seule chose qui bloque les paquets, et elles disparaissent avec le noyau qui les portait.

Trouvez l’objet qui rétablit le blocage

Sous Linux, les règles netfilter vivent dans le noyau. Rien ne les réécrit au démarrage, sauf si vous l’avez organisé : iptables-save plus netfilter-persistent, nftables.service charge /etc/nftables.conf, ou une unité systemd qui exécute votre propre script. Vérifiez ce qui est activé plutôt que ce dont vous vous souvenez l’avoir configuré.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

Un jeu de règles vide quelques secondes après le démarrage est la réponse à la question du titre. Sous Windows, demandez au service client comment il démarre, puis extrayez l’état du filtre de plateforme pendant que le tunnel est en bas.

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

La seconde commande écrit wfpstate.xml dans le répertoire courant. Cherchez des filtres avec une action de blocage qui existent déjà avant que le client se connecte. Base Filtering Engine démarre tôt et restaure les filtres ajoutés avec l’indicateur persistant, c’est pourquoi certains kill switches bloquent le trafic avant qu’aucune fenêtre de client n’existe et d’autres non. Sous macOS, sudo pfctl -s info indique si pf est activé, sudo pfctl -s rules montre ce qui est chargé, et les clients VPN attachent généralement leurs règles à une ancre plutôt qu’au jeu principal. Une règle qui nomme utun3 peut pointer vers une autre interface après le redémarrage suivant, car ce numéro est attribué à l’exécution.

Surveillez l’écart entre la montée du réseau et celle du tunnel

L’intervalle dangereux n’est pas tout le redémarrage, c’est l’écart. L’interface reçoit un bail et une route par défaut à un moment, le service VPN démarre à un autre, et le tunnel s’authentifie plus tard encore, parfois seulement après qu’un utilisateur s’est connecté et qu’un agent d’informations d’identification a tourné. Si le blocage est appliqué en dernier, tout ce qui est dans l’écart sort en clair.

Sur les hôtes systemd, lisez l’ordre au lieu de le deviner. Exécutez systemctl cat sur les unités VPN et pare-feu et cherchez After= ou Before= vis-à-vis de network-pre.target et network-online.target. Une unité de pare-feu ordonnée après network-online.target perd face à l’interface ; celle qui est requise par et ordonnée avant network-pre.target gagne. Sous Windows, les questions équivalentes sont le type de démarrage du service et ses dépendances, car un service réglé sur Manual ne peut pas bloquer un processus au démarrage. Si votre exigence inclut du trafic avant l’ouverture de session, seule une disposition au niveau de l’appareil la satisfait : un tunnel d’appareil Always On VPN s’authentifie avec un certificat de machine et se connecte avant que l’utilisateur ouvre une session, et Microsoft documente la configuration du tunnel d’appareil séparément du tunnel utilisateur. Android prend l’autre voie, en imposant le VPN always-on et en bloquant les connexions sans lui depuis le système et non depuis un processus d’application.

Lancez le test, puis comparez deux chronologies

Redémarrez avec une destination qui ne coûte rien si elle fuit, et capturez l’état pendant l’écart plutôt qu’après. La méthode la plus propre est une sonde de démarrage : une unité oneshot ou une tâche planifiée qui démarre le plus tôt que la plateforme le permet, enregistre la route par défaut et l’état du pare-feu, tente une requête avec un délai court et ajoute une ligne à un fichier local. Comparez cet enregistrement à l’heure de démarrage du service VPN issue de journalctl -b -u ou du journal système.

Lancez ensuite le test ordinaire : tunnel monté, coupez la connexion, regardez si le trafic direct est bloqué, rétablissez. Réussir le second et échouer au premier est le résultat normal, et cela signifie que l’application est côté client, appliquée quand le client se connecte et non au démarrage. Sur la dernière machine que j’ai auditée, le blocage venait d’un script répartiteur de NetworkManager : présent et correct et inutile pour les secondes avant que l’interface monte. Notez les deux résultats, car survivre à un redémarrage ne veut dire quelque chose que lorsque vous précisez quelle couche a survécu et à partir de quel instant.

Comblez l’écart sans couper votre chemin de retour

Si le blocage manque au démarrage, descendez l’application d’une couche au lieu d’ajouter une seconde règle client. Enregistrez le jeu de règles et chargez-le depuis une unité ordonnée avant que le réseau soit utilisable, et assurez-vous que cette unité n’a besoin ni d’une requête DNS ni d’un montage réseau qu’elle est censée protéger. La portée compte autant que le moment : les règles qui correspondent à un identifiant utilisateur ou à un cgroup laissent chaque démon système hors du blocage, et un jeu de règles qui ne traite que l’IPv4 laisse l’IPv6 et le DNS joignables.

Gardez-vous un chemin de retour. Une machine qui bloque tout au démarrage et ne peut ensuite pas s’authentifier n’a aucun réseau, et le correctif n’est pas de supprimer le blocage mais de réparer l’identifiant ou l’ordre. Maintenez une procédure de console locale documentée et une exception étroite et délibérée pour ce dont le tunnel a réellement besoin, comme l’adresse du serveur et le résolveur utilisé avant que le tunnel existe.

Avant de faire confiance à l’installation, confirmez quatre choses dans l’ordre. La politique est stockée là où le démarrage lit. Ce lecteur s’exécute avant que l’interface soit utilisable. Le blocage couvre les deux familles d’adresses et le DNS. Le VPN peut encore s’authentifier pendant que le blocage est actif. Quand les quatre tiennent, un redémarrage ne change rien.