Le pare-feu Windows seul comme coupe-circuit VPN : tient-il ?
Les règles par type d’interface peuvent bloquer les cartes physiques, mais un tunnel tiers apparaît souvent comme filaire. Vérifiez la classification, la route du point de terminaison, puis le DNS.
Demandez si le pare-feu Windows peut à lui seul servir de coupe-circuit et vous obtiendrez deux réponses assurées et incompatibles. L’une affirme que la règle par type d’interface fait tout le travail ; l’autre qu’il ne peut pas fonctionner sans scripts. Les deux décrivent la moitié du même mécanisme. Le pare-feu peut exprimer le blocage, et savoir si le résultat échoue réellement en position fermée dépend de trois choses : comment Windows classe l’adaptateur du tunnel, si l’exception du point de terminaison survit et si la résolution de noms et IPv6 sont couvertes. Trompez-vous sur une seule et la machine fuit ou perd toute connectivité.
Trois conditions, dans cet ordre
La première condition est la classification, et elle décide si la règle souhaitée est même exprimable. Les règles du pare-feu Windows peuvent être limitées par type d’interface : filaire, sans fil ou accès distant. Une stratégie qui bloque le trafic sortant sur les types physiques tout en autorisant le tunnel ne fonctionne que si Windows reconnaît le tunnel comme un accès distant.
La deuxième condition est l’exception du point de terminaison. Avant qu’un tunnel existe, le client doit joindre le serveur VPN par la carte physique, donc un blocage total de cette carte empêche précisément la connexion qui rendrait le blocage inutile. L’exception doit nommer le serveur et son port, et le paquet doit sortir par la passerelle physique plutôt que d’entrer dans un tunnel encore inactif.
La troisième est la couverture. Un jeu de règles qui bloque IPv4 et oublie IPv6, ou qui autorise le résolveur local à chercher le point de terminaison et autorise donc toute autre requête, échoue ouvert exactement dans la fenêtre que le coupe-circuit existe pour couvrir. C’est une lacune de conception, pas un défaut du pare-feu. C’est aussi la lacune qui survit à chaque essai sur un bureau.
La classification est la première porte
Regardez ce que Windows pense des adaptateurs avant d’écrire une seule règle. Une connexion VPN native de Windows apparaît normalement comme un accès distant. Un client tiers qui crée son propre adaptateur virtuel apparaît souvent comme filaire, ce qui signifie qu’un blocage limité aux cartes filaires bloque aussi le tunnel.
Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundActionLa troisième commande indique si un blocage sortant par défaut est déjà en vigueur, ce qui change toute la forme de la conception. Si le défaut est déjà de bloquer, vous écrivez des règles d’autorisation plutôt que des exceptions à une base permissive, et c’est une posture bien plus facile à raisonner.
Si votre adaptateur de tunnel se déclare filaire, le pare-feu seul n’est pas le bon outil pour une conception à échec fermé, et aucun réglage de règles n’y change rien. C’est le cas où le second avis de chaque fil de forum est correct.
L’exception du point de terminaison a besoin d’une route autant que d’une règle
Supposons que la classification fonctionne. L’exception se compose de deux pièces, et elles vivent dans des sous-systèmes différents. La règle du pare-feu autorise le trafic ; la route de l’hôte le fait sortir par la bonne interface tant que le tunnel est baissé.
New-NetFirewallRule -DisplayName "VPN endpoint allow" -Direction Outbound -Action Allow \
-Protocol TCP -RemoteAddress 203.0.113.9 -RemotePort 443 -InterfaceType Wired,Wireless
New-NetRoute -DestinationPrefix 203.0.113.9/32 -InterfaceIndex 12 -NextHop 192.168.1.1
Get-NetRoute -DestinationPrefix 203.0.113.9/32Sans la route, l’exception ne sert que tant qu’une route par défaut pointe encore vers la passerelle physique. Une fois que le client installe sa propre route par défaut puis meurt, les paquets autorisés n’ont nulle part où aller de façon sensée et la connexion ne peut pas être rétablie. Cette panne ressemble à un client cassé et n’est en réalité qu’une route manquante.
Gardez l’exception aussi étroite que le client le permet. Une adresse et un port se vérifient ; une plage qui couvre tout le réseau du fournisseur non. Cette règle plus large autorise aussi tout ce qui est hébergé chez le même fournisseur, ce qui dépasse généralement votre intention.
Le DNS et IPv6 sont là où il échoue ouvert
La résolution de noms est la fuite classique. Si le point de terminaison est un nom d’hôte, le client doit le résoudre avant que le tunnel existe, ce qui oblige à autoriser la carte physique à joindre un résolveur. Cette même autorisation laisse sortir toute autre requête tant que le tunnel est baissé, et une requête suffit à révéler ce que vous alliez visiter.
IPv6 est le second. Les règles écrites pour IPv4 ne couvrent pas l’autre famille, et beaucoup de clients n’installent que des routes IPv4. Une machine dotée d’une connectivité IPv6 native peut donc continuer à parler à internet alors que le côté IPv4 est fermement bloqué, et le coupe-circuit signale un succès permanent.
| Gap | What leaks | Control |
|---|---|---|
| Resolver permitted for endpoint lookup | Every name queried while down | Pin the endpoint as an address, or block non-tunnel DNS |
| Rules only for IPv4 | Full IPv6 connectivity | Add the same rules for the other family |
| Application bound to physical interface | Its own traffic | Firewall cannot fix this; change the binding |
La troisième ligne mérite d’être comprise plutôt que contournée. Un pare-feu décide des paquets, pas de l’interface qu’une application a demandé d’utiliser, et un programme qui se lie explicitement peut être difficile à contenir. C’est un argument pour un coupe-circuit côté client qui opère sous l’application, pas pour davantage de règles.
Testez en arrêtant le client, pas en tirant le câble
Le seul test qui ait du sens est celui qui imite la panne contre laquelle vous vous protégez. Arrêtez le service, tuez le processus ou désactivez l’adaptateur créé par le client, puis essayez d’atteindre internet et un nom :
Stop-Service -Name "YourVpnService" -Force
Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Resolve-DnsName example.com
Test-NetConnection -ComputerName 2606:4700:4700::1111 -Port 443Les trois devraient échouer. Si le premier réussit, le blocage n’est pas en vigueur ; si le deuxième réussit là où le premier a échoué, vous avez une fuite DNS ; si le troisième réussit, IPv6 n’est pas couvert. Chaque résultat désigne exactement l’une des lacunes ci-dessus.
Répétez le test après une veille et une reprise, car le profil du pare-feu peut changer quand Windows décide qu’un réseau est public ou privé, et les règles limitées à un profil le suivent. Une conception qui tient sur un bureau et échoue dans un train est une conception testée une fois.
Si la porte de classification ou l’exigence DNS rendent l’approche pare-feu seul inapplicable, un coupe-circuit côté client est la réponse honnête. Si le tunnel se termine plutôt sur un routeur, la stratégie devrait appartenir au routeur, car une seule règle y couvre chaque appareil derrière lui et ne dépend pas de la façon dont Windows nomme un adaptateur.