Le kill switch bloque encore le trafic après la déconnexion du VPN

Le tunnel a disparu, l’icône réseau paraît normale et rien ne se charge. Vous avez déconnecté le VPN, l’avez désinstallé ou redémarré, et le blocage censé vous protéger pendant une coupure tient toujours. La fenêtre du client ne peut pas l’expliquer, car ce n’est pas le client qui vous bloque : la décision a été écrite dans le noyau en votre nom, et rien n’a été laissé pour la retirer. Sous Windows, cet état siège dans la plateforme de filtrage Windows ; sous Linux, c’est un jeu de règles dans iptables ou nftables, souvent avec un instantané rejoué au démarrage. Voici l’ordre que j’utilise : lire l’état, supprimer l’objet le plus étroit qui explique la panne, puis trouver tout ce qui le remet en place.

Un kill switch est un état du noyau, pas un réglage

Les clients de bureau mettent en œuvre le blocage en ajoutant des filtres qui refusent le trafic hors du tunnel. Sous Windows, ce sont des filtres WFP aux couches de redirection de connexion et de transport, et certains sont persistants : ils sont enregistrés dans le magasin de stratégies du Base Filtering Engine et restaurés au démarrage de la machine, avant qu’aucun logiciel VPN ne s’exécute. Les clients diffèrent par le moment du nettoyage. Certains retirent les filtres à la déconnexion, d’autres seulement à une sortie propre, et d’autres seulement quand le kill switch est d’abord désactivé. Désinstallez pendant que le blocage est actif, ou tuez le processus, et les filtres restent.

L’équivalent Linux est une règle de rejet ou de refus dans le chemin de sortie, parfois une règle de transfert, parfois une politique de chaîne modifiée. Ces règles survivent au processus qui les a ajoutées parce qu’elles sont un état du noyau : tuez le client, faites-le planter ou coupez l’alimentation, et le noyau continue de rejeter des paquets sans que rien ne reste pour l’annuler. Un paquet de persistance ajoute une seconde couche de permanence en prenant un instantané du jeu de règles courant et en le restaurant au démarrage, si bien que le démarrage suivant commence avec le blocage déjà installé.

Lisez l’état WFP avant de supprimer quoi que ce soit

Windows fournit les outils nécessaires. Lancez une invite élevée et videz l’état de la plateforme ; le vidage arrive sous forme de wfpstate.xml dans le répertoire de travail.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

Cherchez dans le XML le nom du fournisseur parti, une action Block et la couche. Les filtres sur la redirection de connexion et le transport sont ceux qui cassent le trafic ordinaire ; un filtre sur une couche d’acceptation de réception n’est généralement pas votre cause. Si le Base Filtering Engine ne tourne pas du tout, cherchez ailleurs, car rien d’autre ne peut appliquer ces filtres.

Vérifiez aussi la vue ordinaire du pare-feu, car la plupart des gens n’en inspectent qu’une des deux :

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Quand les profils intégrés sont actifs et qu’aucune règle ne correspond au trafic en échec, le blocage vient d’un fournisseur tiers et non du pare-feu Windows. Cette distinction décide quel outil vous utiliserez pour la réparation.

Lisez les règles Linux dans la syntaxe avec laquelle vous supprimerez

iptables -S affiche les règles sous la même forme que celle utilisée pour les ajouter, ce qui rend la sortie directement réutilisable pour une suppression. iptables -L -v -n ajoute des compteurs de paquets, et ces compteurs vous disent si une règle correspond vraiment à vos requêtes en échec ou si elle reste simplement dans la chaîne.

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

Lisez les politiques des chaînes, pas seulement les règles : -P OUTPUT DROP bloque le trafic même quand aucune règle ne correspond. Inspectez IPv6 séparément, car un client qui installe les deux familles peut laisser le blocage IPv6 en place après la disparition des règles IPv4, et le symptôme dépend alors de la famille qu’une application préfère. Là où nftables est utilisé, lancez aussi nft list ruleset ; les deux outils coexistent via une couche de compatibilité, et une seule liste ne montre pas forcément toutes les règles susceptibles de rejeter un paquet.

Supprimez l’objet le plus étroit qui explique la panne

Sous Windows, la première étape reste le propre chemin de suppression du fournisseur : relancez l’installateur et utilisez réparation ou désinstallation, ou lancez l’outil de nettoyage si le fournisseur en publie un. Les services et tâches planifiées résiduels sont courants, et une tâche qui démarre le client à l’ouverture de session réinstalle ses filtres au prochain démarrage. Une désinstallation qui échoue en lisant la clé de registre du client signifie généralement qu’un service ou une tâche la détient encore, non que le registre soit corrompu.

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

Les filtres persistants sont le dernier recours. Ils vivent sous HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, une valeur par filtre avec une clé GUID. Exportez d’abord la clé, notez les GUID que vous retirez, ne supprimez que les valeurs qui appartiennent au client parti, puis redémarrez pour que le moteur reconstruise son état. Ne supprimez pas toute la clé et ne désactivez pas le Base Filtering Engine : le pare-feu Windows et Defender en dépendent, et vous échangeriez une panne contre une pire.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

Sous Linux, prenez la ligne affichée par iptables -S et remplacez -A par -D. Supprimer l’unique règle que vous avez identifiée vaut mieux que vider une chaîne, car cela laisse votre propre politique intacte.

sudo iptables -D OUTPUT -p udp -j REJECT

Si le rejet vit dans une chaîne définie par l’utilisateur, supprimez d’abord le saut vers cette chaîne, puis retirez la chaîne avec -X. Mettre la politique d’une chaîne à ACCEPT alors que des règles de rejet subsistent n’aide que les paquets qui atteignent la décision de politique. Vider toutes les tables est un dernier recours : cela retire aussi des règles ajoutées pour d’autres raisons, et avec ufw activé, cela laisse le service croire qu’il possède des chaînes qui n’existent plus.

Trouvez le propriétaire qui le remet en place

Après la réparation immédiate, cherchez tout ce qui pourrait restaurer l’état. Sous Linux, vérifiez si une unité de persistance est activée, si le client dispose d’un réglage de restauration du pare-feu à l’ouverture de session et si un fichier de règles enregistré existe sous /etc. Sous Windows, vérifiez de nouveau les entrées de démarrage, les services et les tâches planifiées, puis redémarrez et relisez l’état avec les mêmes commandes qu’avant.

Si le blocage revient, la suppression n’était pas la solution ; le propriétaire l’était. Notez quel client ou service l’installe et désactivez la fonction là-bas, au lieu de vous battre avec elle au niveau du pare-feu après chaque déconnexion.

Vérifiez avec du trafic réel, pas un simple ping

Testez une résolution de nom, une connexion TCP et une session de navigateur neuve, puis redémarrez et répétez les mêmes trois contrôles. Un ping qui fonctionne alors que HTTPS échoue pointe un filtre de la couche transport plutôt que le réseau, et un blocage qui ne réapparaît qu’après le redémarrage pointe un propriétaire que vous n’avez pas encore trouvé.

Conservez les preuves : la clé BFE exportée, ou la sortie d’iptables -S capturée avant le changement. Avant de le déclarer réparé, confirmez la couche d’où vous avez retiré l’objet, le propriétaire qui pourrait le réinstaller, l’état après un redémarrage propre, et que la navigation ordinaire fonctionne sans aucun processus VPN en cours. La page de manuel iptables(8) contient la syntaxe exacte de suppression et de politique si vous scriptez le nettoyage.