L’application VPN a planté : le kill switch est-il toujours actif ?

Partez de là où part l’utilisateur : la fenêtre du client a disparu, l’icône de la zone de notification s’est volatilisée et le navigateur charge ou ne charge pas. Cette seule observation ne vous dit pas si le blocage a survécu. La réponse dépend du composant qui détient les règles, de savoir s’il est mort avec la fenêtre et si la plateforme garde l’application des règles hors de l’application. Avancez de la fenêtre vers le processus, puis vers le pare-feu, puis vers le chemin réel.

Ne redémarrez pas d’abord ; un redémarrage détruit généralement les preuves.

Partez de ce qui tourne encore

Ouvrez la liste des processus avant de toucher quoi que ce soit. Un client de bureau se scinde généralement en un processus d’interface utilisateur et un service ou démon, et un plantage du premier n’arrête pas forcément le second. Sous Windows le service peut encore être listé, sous Linux l’unité peut encore être active, et sous Android le tunnel appartient au système une fois le consentement donné. Lisez ces trois faits dans cet ordre.

Si le démon est vivant, le tunnel l’est probablement aussi, et la fenêtre manquante n’est que cosmétique.

Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40

Lisez le blocage chez celui qui l’applique, pas dans l’application

Si le client implémente son kill switch en insérant des règles de pare-feu, ces règles appartiennent au système d’exploitation et survivent au processus qui les a créées. Un plantage vous laisse alors bloqué sans aucune interface pour le désactiver, ce qui ressemble à un réseau cassé plutôt qu’à une protection. Si en revanche le blocage vit dans le chemin de paquets propre au client, tuer le processus retire le blocage au même instant.

Android gère cela encore autrement : le VPN always-on avec lockdown est un réglage de la plateforme, donc le blocage persiste indépendamment du processus de l’application, et le système peut redémarrer le service. Consultez la documentation de la plateforme pour le comportement exact au lieu de supposer qu’il correspond à un client de bureau.

Distinguer une sortie propre d’un plantage

Un Quit normal exécute généralement le chemin d’arrêt du client, qui retire les règles et ferme le tunnel exprès. Un plantage saute ce chemin et laisse tout ce que l’applicateur a déjà installé. La différence se voit dans les horodatages des règles par rapport à la sortie du processus, et dans l’existence éventuelle d’une interface de tunnel orpheline.

Cette distinction décide de votre récupération : une sortie propre peut nécessiter une nouvelle connexion, tandis qu’un plantage peut nécessiter le retrait des règles restantes via l’action de réparation prise en charge du client.

Récupérer sans casser les autres contrôles

Redémarrez le client via son flux de travail documenté, puis vérifiez les deux moitiés de l’exigence : le tunnel transporte du trafic, et le blocage s’applique encore quand il le doit. Vider tout le pare-feu pour retrouver la connectivité retire aussi des contrôles sans rapport, et ce compromis en vaut rarement la peine.

Pour un plantage répété, rassemblez la version du client, la build de la plateforme et les journaux limités que demande le fournisseur. Un profil client, une clé privée ou un journal de connexion complet d’un autre compte ne sont pas nécessaires pour un rapport de plantage, et les inclure transforme un cas de support en problème de traitement de données.

Un plantage n’est pas la preuve d’une fuite. La preuve est un paquet observé sortant par un chemin que la politique était censée empêcher, capturé au moment où le client était arrêté. Testez-le délibérément, avec une destination inoffensive, et notez quelle couche d’application a tenu.