Pourquoi votre adaptateur VPN reste sur le profil public du pare-feu

Le tunnel est établi, le compte s’est authentifié auprès du domaine, et Windows étiquette toujours la connexion comme publique. Une règle de pare-feu écrite pour le profil de domaine ne s’applique donc pas, et le partage de fichiers reste inaccessible. La tentative de correction habituelle consiste à passer l’adaptateur en privé, ce qui change les règles applicables sans rien changer à l’authentification. L’étiquette comme la correction sont largement mal comprises, et les séparer demande trois commandes.

Le compte qui s’est connecté n’est pas la catégorie du réseau

Deux décisions différentes sont prises pendant une connexion VPN, et il est facile de les confondre. La passerelle décide si le compte peut se connecter. Windows décide comment classer le réseau qui en résulte, et cette classification détermine quelles règles de pare-feu s’appliquent à l’interface.

Une authentification de domaine réussie au niveau de la passerelle est une preuve concernant le compte. Ce n’est pas la preuve que le point de terminaison a authentifié le réseau auprès d’un contrôleur de domaine, et c’est exactement ce que représente la catégorie de domaine.

C’est pourquoi une machine peut être jointe au domaine, se connecter avec un compte de domaine et afficher quand même Public. La classification est une détermination locale sur le réseau, pas une déclaration sur les informations d’identification qui ont ouvert le tunnel. Le compte peut être parfaitement valide tandis que l’étiquette reste là où elle a commencé.

Trois catégories, dont l’une ne peut pas être définie

Windows expose trois catégories et seules deux d’entre elles peuvent être attribuées par un administrateur. La troisième est décidée par le système d’exploitation après qu’il a authentifié avec succès le réseau auprès d’un contrôleur de domaine.

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory,IPv4Connectivity
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory Private
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory DomainAuthenticated

La troisième commande échoue, et c’est le comportement documenté et non un problème d’autorisations. La référence de la cmdlet elle-même indique que la catégorie de domaine ne peut pas être attribuée de cette façon, car Windows la déduit de l’authentification de domaine. Voir l’erreur est une confirmation utile que la catégorie est une conséquence et non un réglage.

Lisez la première commande sur le point de terminaison dont le trafic est bloqué. La classification de l’interface de la passerelle elle-même ne vous dit rien sur la façon dont chaque poste de travail a classé son tunnel.

Les règles suivent le profil pour lequel elles ont été écrites

Une fois la catégorie connue, l’accès manquant s’explique généralement de lui-même. Chaque règle du Pare-feu Windows porte une étendue de profil, et une règle limitée au domaine ne s’applique pas lorsque l’interface est publique. Trois commandes transforment cela en réponse plutôt qu’en théorie, et la troisième attrape le cas où le profil n’a jamais été le problème :

(Get-NetFirewallRule -DisplayName 'Allow File Share').Profile
Get-NetFirewallRule -DisplayName 'Allow File Share' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

La deuxième commande est celle qui transforme un rapport vague en correction. Si la règle est limitée à une plage d’adresses distantes qui n’inclut pas le pool VPN, changer le profil n’aidera pas non plus.

Vérifiez aussi l’action d’entrée par défaut. Sur une machine où l’entrée est bloquée par défaut, une règle d’autorisation absente produit du silence plutôt qu’un rejet. Côté client, cela ressemble exactement à un échec de routage, et c’est pourquoi tant de ces tickets commencent par la mauvaise hypothèse.

Déterminez quelle machine applique la règle

Avant de changer de catégorie, établissez où le blocage se produit. Le serveur qui héberge le partage peut avoir son propre pare-feu, et ses règles s’appliquent au trafic provenant du pool VPN, quelle que soit la façon dont le client a étiqueté son adaptateur. Un rejet à cet endroit est invisible pour toutes les commandes locales que vous exécutez, et le côté client signale seulement que la ressource est indisponible. Testez les règles propres à la destination avant de toucher à la classification du client.

Testez depuis le client vers le port précis, puis comparez avec un test depuis un autre hôte du même VPN. Si les deux échouent, le problème est à la destination ou sur le chemin. Si un seul échoue, la différence est locale à cette machine, et la catégorie de profil devient une cause plausible.

Gardez aussi le sens en tête. Une règle qui autorise le SMB entrant ne fait rien pour un client dont sa propre règle sortante bloque le même trafic. Depuis une fenêtre d’explorateur de fichiers, les deux échecs sont indiscernables, alors testez chaque sens séparément avant de modifier quoi que ce soit.

Que faire au lieu de tout réétiqueter

Rendre privé un réseau non identifié pour satisfaire une règle large est un vrai changement avec de vraies conséquences. Le profil privé autorise généralement plus de découverte et plus de trafic entrant que le public.

Si l’objectif est de laisser un service précis atteindre les clients VPN, limitez la règle par adresse distante plutôt que par profil. Cela exprime l’intention avec précision, fonctionne indépendamment de la classification et ne dépend pas de la capacité de Windows à deviner correctement un adaptateur virtuel. Cela survit aussi à une mise à jour client qui reclasse l’interface. Écrivez le pool dans la règle et la personne suivante pourra lire l’intention sans demander.

Si la catégorie de domaine est réellement attendue et n’apparaît jamais, c’est une enquête distincte. Vérifiez que la machine est jointe au domaine, qu’elle peut atteindre un contrôleur de domaine par le tunnel et que le canal sécurisé est sain. Ces trois commandes y répondent sans une seule modification du registre :

Get-CimInstance Win32_ComputerSystem | Select-Object PartOfDomain,Domain
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:corp.example.com

Ces trois répondent à la question de savoir si le point de terminaison pouvait authentifier le réseau. S’il ne peut pas atteindre un contrôleur, la catégorie de domaine ne sera jamais attribuée, quel que soit le nombre de réinitialisations de l’adaptateur. La règle de pare-feu que vous poursuiviez n’a jamais été le vrai problème, et l’étiquette était un symptôme d’un chemin cassé, pas une cause.