Filtre de trafic VPN ou règle IPsec : où Windows applique un port

Un utilisateur de VPN Windows doit atteindre HTTPS sur un serveur et non SMB sur le même serveur, et une route ne peut pas l'exprimer. Les deux requêtes portent la même adresse de destination, donc le préfixe qui envoie le trafic dans le tunnel porte aussi le flux que vous vouliez exclure. Les séparer exige une règle qui examine quelque chose de plus fin que la destination.

Deux intentions différentes se construisent avec deux mécanismes Windows différents. Les mélanger produit une stratégie qui semble complète tout en appliquant la moitié de ce que vous vouliez.

Une route ne peut pas séparer deux services sur une même adresse

Le routage natif du VPN repose sur des préfixes : il décide quelles destinations passent par le tunnel et lesquelles restent dehors. C'est le bon outil pour garder un sous-réseau à l'intérieur et un autre à l'extérieur, et il est aveugle aux ports par construction. Un filtre de trafic sur le profil VPN ajoute une seconde dimension : il fait correspondre le protocole, l'adresse distante et le port distant à ce qui peut franchir cette interface. Une règle IPsec travaille à une troisième place et exprime quels flux exigent une protection et avec qui ils s'authentifient. Les trois répondent à des questions différentes et aucune ne remplace les autres.

Commencez par écrire la phrase voulue. Autoriser seulement HTTPS est une phrase d'accès, tandis qu'exiger IPsec pour HTTPS est une phrase de protection, et les deux mènent à une configuration différente.

La restriction d'accès et l'exigence de protection divergent

Une restriction d'accès dit ce qui peut utiliser l'interface, et elle est appliquée en autorisant un ensemble et en refusant tout le reste. Une exigence de protection dit quels flux doivent être chiffrés et authentifiés, et elle est appliquée en négociant des associations de sécurité qui leur correspondent. La première produit une requête bloquée quand quelque chose n'est pas dans la liste, tandis que la seconde produit une connexion qui soit porte la protection exigée, soit ne s'établit pas. Traiter l'une comme l'autre est la façon dont une stratégie finit par ne rien bloquer ou ne rien protéger.

La conséquence pratique est qu'une liste de filtres est un ensemble fermé. Une fois qu'une liste existe sur le profil, le trafic sur cette interface qui ne correspond à aucune entrée est refusé, donc DNS, les échanges d'authentification et toute dépendance dont l'application a besoin exigent leurs propres entrées. Ajouter une règle large pour faire taire les refus rouvre toute l'interface et annule la restriction en silence. La liste doit être aussi courte que l'exigence le permet et aussi complète que l'application l'exige.

Construisez la liste de filtres comme un ensemble complet

Les profils VPNv2 portent la liste de filtres séparément de la liste de routes, et ses entrées sont des propriétés de profil et non des commandes. Pour l'exemple HTTPS, l'entrée a besoin du protocole 6, de l'adresse distante et du port distant, déployés par le canal de gestion ou ProfileXML pour le type de profil utilisé. La définition du filtre de trafic VPNv2 de Microsoft indique que les conditions à l'intérieur d'une règle se combinent tandis que des identificateurs de règle séparés agissent comme des alternatives.

TrafficFilterList/0/Protocol            = 6
TrafficFilterList/0/RemoteAddressRanges = 10.60.4.20/32
TrafficFilterList/0/RemotePortRanges    = 443
RouteList/0/Address                     = 10.60.4.0/24

Les valeurs de port de cette liste décrivent le port du service à l'extrémité distante, et le port local doit rester sans restriction pour que le port source éphémère du client ne soit pas filtré. Faire l'inverse produit une règle qui ne correspond à rien et une énigme qui prend un après-midi.

Écrivez la route et le filtre comme deux décisions distinctes. La route décide que ce serveur est atteint par le tunnel, et le filtre décide quels services peuvent utiliser ce chemin.

Prouvez les deux résultats avec deux requêtes

Testez le flux autorisé et le flux refusé séparément, et lisez l'échec plutôt que la page manquante. Un refus qui arrive vite est une décision de stratégie, tandis qu'un délai d'attente est plus probablement une route manquante ou un service qui n'écoute pas. Les commandes ci-dessous exécutent les deux requêtes et montrent les règles en vigueur.

Test-NetConnection 10.60.4.20 -Port 443
Test-NetConnection 10.60.4.20 -Port 445
Get-NetIPsecRule -DisplayName *Vpn*
Get-VpnConnection -Name Corp

Un rejet rapide au test SMB avec un test HTTPS réussi est le résultat que le filtre était censé produire. Un refus sur les deux ports signifie que la liste manque quelque chose dont la session a besoin, et un délai d'attente sur les deux pointe vers le routage plutôt que vers le filtrage. Si les flux protégés montrent aucune association de sécurité dans la sortie IPsec, l'exigence de protection n'est pas satisfaite même quand la connexion réussit. Lisez les quatre sorties ensemble, car chacune seule soutient une histoire différente.

Consignez le profil effectif, le jeu de règles et la stratégie du pair avec les résultats. Les notes de compatibilité historiques sur les anciens clients Windows ne décrivent pas ce que les fonctions de profil géré d'aujourd'hui prennent en charge sur une passerelle donnée. Un comportement propre à une version appartient au dossier, pas à l'hypothèse.