Profils pare-feu et sortie VPN : pourquoi public n'est pas un chemin
Un profil de pare-feu choisit quel jeu de règles s'applique. Il ne dit rien sur l'interface qui a transporté le paquet, et un blocage explicite prime sur une autorisation plus étroite.
La règle semble précise : autoriser le trafic local sur le profil privé et uniquement le trafic VPN sur le public. Elle ne l'est pas, car un profil réseau choisit quel jeu de règles de pare-feu s'applique et ne dit rien sur l'adaptateur qui a transporté un paquet. Traiter le nom du profil comme une exigence de chemin est l'erreur qui fait paraître terminée une conception de sortie restreinte alors qu'elle ne l'est pas.
Notez d'abord les flux, puis décidez quel mécanisme peut réellement imposer chacun d'eux. Cette liste de flux est le seul artefact qui survive au prochain changement de règles.
La catégorie choisit les règles, pas les routes
Quand Windows classe un réseau comme public ou privé, le pare-feu applique le jeu de règles configuré pour ce profil. Le classement suit le réseau auquel l'adaptateur s'est joint, et le jeu de règles décide de ce qui y est autorisé. Aucun de ces faits ne dépend de l'utilisation du tunnel par le trafic d'une application. Cette indépendance est toute la difficulté.
Le choix du chemin revient au routage, via la métrique de l'interface et le préfixe qu'installe le tunnel. Un profil peut donc être étiqueté public alors que la connexion d'une application emprunte le chemin physique, et le pare-feu signalera quand même que le jeu de règles public a été appliqué.
C'est pourquoi une règle limitée au profil ne peut pas vouloir dire tunnel uniquement. Les deux propriétés sont décidées par des composants différents et l'une ne peut pas remplacer l'autre.
| Flow | What decides it | What a rule can enforce |
|---|---|---|
| VPN client to its endpoint | Routing plus the outer transport | Allow the client process before the tunnel exists |
| Application to an internet host | Interface metric and prefix length | Block the process unless the tunnel interface is up |
| Application to a LAN host | Local subnet route | Allow one destination, not the whole category |
Un blocage explicite prime sur une autorisation plus étroite
Les recommandations de Microsoft sur les règles de pare-feu distinguent une autorisation conçue comme exception à une action de blocage par défaut d'un blocage explicite qui entre en conflit avec une autorisation. Les blocages explicites gagnent ce conflit, et les règles de sortie obéissent à la même préséance.
La recette populaire consistant à ajouter une règle qui bloque tout et à compter sur une autorisation plus étroite placée au-dessus ne fait donc pas ce que son auteur attend. Le Pare-feu Windows ne résout pas le conflit par l'ordre des règles attribué par l'administrateur. Le blocage s'applique simplement, et l'application qui se connecte signale un délai d'attente dépassé. La règle qui ressemblait à l'exception n'a jamais été en jeu.
La forme prise en charge est une politique de refus par défaut avec des règles d'autorisation approuvées, où chaque autorisation nomme un programme, un service ou une destination assez précisément pour être vérifiable. Cette conception résiste à un audit, car chaque exception est visible et aucune ne dépend de l'ordre dans lequel elle a été créée.
Deux règles qui se contredisent sont pires qu'une seule règle, car le comportement obtenu est à la fois correct et inexplicable.
Donnez à la politique de sortie un seul propriétaire
Un client VPN pris en charge tient déjà son propre comportement de blocage et ses propres exceptions de point de terminaison. Ajouter des règles manuelles non coordonnées peut laisser ce client hors du tunnel dont il a besoin pour s'installer, ou laisser ouvert un second chemin que personne n'a remarqué.
Décidez qui possède la politique de sortie avant d'écrire des règles : la configuration propre du client, une politique de pare-feu gérée ou une liste locale d'exceptions documentée avec un propriétaire. Réconciliez ensuite les couches au lieu d'empiler des expériences jusqu'à ce que quelque chose se connecte. Un propriétaire nommé est aussi la personne que l'on interroge quand deux couches ne sont pas d'accord.
Préservez un canal de récupération avant de changer quoi que ce soit. Une machine distante verrouillée hors de son propre chemin d'administration est un résultat pire que le trou de politique que vous combliez. La règle de récupération est plus facile à justifier lorsqu'elle est écrite à l'avance, et plus facile à trouver quand un changement tourne mal à une heure que personne n'apprécie.
Testez quatre résultats au lieu de lire l'étiquette
Une politique ne vaut que par les cas qu'elle distingue, alors traitez l'étiquette du profil comme un point de départ plutôt qu'un résultat. Quatre résultats vous disent si elle fonctionne : la requête LAN prévue réussit, une requête internet couverte réussit, une requête directe interdite échoue, et le cas de panne du tunnel se comporte comme prévu au lieu de retomber en silence. Notez les quatre résultats à côté du changement de règles. Un plan de test à quatre cas nommés est assez court pour être exécuté chaque fois et assez précis pour échouer bruyamment.
Get-NetConnectionProfile | Select-Object Name,NetworkCategory,InterfaceAlias Get-NetFirewallProfile | Select-Object Name,DefaultOutboundAction Get-NetFirewallRule -Direction Outbound -Enabled True | Where-Object Action -eq Block | Select-Object DisplayName,Profile
La première commande montre comment chaque réseau connecté est classé, ce qui n'est souvent pas ce que supposait la personne qui a écrit la règle. La seconde montre l'action par défaut de chaque profil, et la troisième liste les blocages de sortie activés, y compris ceux qui annuleront silencieusement une autorisation plus étroite.
Exécutez de nouveau les quatre cas après un changement de réseau, car un profil peut être reclassé quand la machine rejoint un autre réseau. Une étiquette de profil concordante n'est pas la preuve que le chemin était celui que vous vouliez.