Kill switch sous Windows sans logiciel supplémentaire : profils ou routes ?

Les profils du pare-feu suivent la catégorie du réseau, les routes suivent l’adaptateur. Comparez les deux, puis testez le cas du plantage avec le tunnel disparu et l’icône qui ment.

Le client meurt en pleine mise à jour et l’icône de la zone de notification disparaît. Le transfert continue par la connexion de la maison. C’est exactement cette séquence qui justifie l’existence d’un kill switch, et Windows peut s’en approcher sans second produit.

Deux méthodes méritent d’être connues. Elles échouent à des endroits différents, et aucune n’est une réponse complète.

Première méthode : autoriser le programme sur un seul profil

Le pare-feu Windows limite les règles aux profils Domain, Private et Public. L’astuce consiste à donner une catégorie à l’adaptateur du tunnel et une autre à l’adaptateur physique. Vous écrivez ensuite une règle sortante qui autorise le programme protégé sur le profil du tunnel et le bloque partout ailleurs. Le pare-feu lit la catégorie, pas le nom de l’adaptateur.

Réglez d’abord la connexion VPN sur Private et le réseau physique sur Public. Ajoutez ensuite une règle de blocage pour le programme qui s’applique aux profils non désirés. Confirmez l’affectation avec Get-NetConnectionProfile, car c’est cette affectation que la règle suit.

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory

New-NetFirewallRule -DisplayName 'Block browser off VPN' -Direction Outbound `
  -Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Block -Profile Public

New-NetFirewallRule -DisplayName 'Allow browser on VPN' -Direction Outbound `
  -Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Allow -Profile Private

La faiblesse est structurelle. Une règle de profil suit la catégorie, donc quand Windows reclasse un réseau d’hôtel, le blocage peut cesser de s’appliquer. Rien dans la liste des règles ne change lorsque cela arrive.

Deuxième méthode : supprimer la route par défaut physique

L’approche par routes est plus brutale et bien plus facile à auditer. Notez la passerelle physique, laissez le VPN installer sa propre route par défaut avec une métrique plus basse, puis supprimez la route par défaut physique. Plus rien ne peut alors porter le trafic.

route print -4
route delete 0.0.0.0 mask 0.0.0.0 192.168.50.1
route print -4 | findstr /c:"0.0.0.0"

Quand le client meurt, la route du VPN part avec son adaptateur. La machine passe hors ligne au lieu de fuir, et c’est exactement ce qu’un kill switch est censé produire.

Deux détails décident s’il tient une semaine. Le DHCP remet la passerelle en place chaque fois que la liaison tremble. Un adaptateur physique à adresse statique évite cette surprise. L’adresse du serveur VPN lui-même doit aussi rester joignable. Sans ce chemin vers l’hôte, le client ne pourra jamais se reconnecter après la coupure qui a déclenché le blocage.

Troisième méthode : pas de passerelle, une route d’hôte persistante

La troisième option commence par effacer la passerelle des paramètres de l’adaptateur. Une seule route persistante vers le point de terminaison du VPN la remplace ensuite. La machine peut alors parler au serveur et à rien d’autre jusqu’à ce que le tunnel monte.

route -p add 198.51.100.44 mask 255.255.255.255 192.168.50.1 metric 1
route print -4 | findstr 198.51.100.44

Restaurer la passerelle restaure l’internet ordinaire, ce qui en fait un interrupteur propre. Il ne dépend pas d’un script qui surveille les événements de l’interface. Il ne se soucie pas non plus de la façon dont le réseau est catégorisé.

Le prix est un isolement total tant que le tunnel est arrêté. Les mises à jour s’arrêtent, et le téléchargement même qui a motivé l’exercice aussi. Sur un portable de travail, c’est souvent correct, alors que sur une machine personnelle c’est une décision à prendre délibérément.

Pourquoi l’icône du globe ne prouve rien

Windows signale l’accessibilité par une sonde vers un point de terminaison Microsoft. Cette sonde ne dit rien de votre tunnel. Un tunnel connecté peut se trouver derrière un globe qui annonce l’absence d’internet, et un tunnel mort peut afficher une connexion saine.

Testez en tuant le processus du client puis essayez de joindre une adresse publique par numéro. Une recherche de nom peut être répondue depuis le cache, donc ni l’icône ni une réponse DNS ne sont des preuves.

Ce qu’il faut consigner après une vraie coupure

Menez le test comme une séquence et non comme une vérification unique. Tuez le processus au lieu de vous déconnecter, puis essayez une adresse numérique sur les deux familles. Restaurez ensuite le client et confirmez qu’il joint encore son propre serveur par la route conservée.

taskkill /IM openvpn-gui.exe /F
ping -4 198.51.100.44
ping -6 2606:4700:4700::1111
route print -4 | findstr /c:"0.0.0.0"

Répétez la séquence après une veille, après un changement de Wi-Fi et après le passage du câble au sans-fil. C’est lors de ces transitions que la méthode des profils et le comportement du DHCP échouent tous les deux. Une règle qui tient sur un bureau ne tient pas forcément dans un hôtel.

Écrivez l’étape d’annulation à côté de chaque règle et de chaque route. Microsoft documente la création de règles sortantes dans sa référence des règles du pare-feu Windows, et c’est une meilleure source qu’un tutoriel uniquement en captures d’écran.

Articles similaires