L’adaptateur VPN de Windows doit-il être privé ou public ?
Décidez si un adaptateur VPN Windows relève du profil privé grâce à trois tests : chemin de confiance, classification stable et règles dont vous avez réellement besoin.
Régler un adaptateur VPN Windows sur Privé est juste pour un tunnel d’entreprise et faux pour un client VPN commercial, et la différence n’est pas cosmétique. La catégorie de réseau sélectionne un profil de pare-feu, si bien qu’un seul changement admet tout un jeu de règles d’un coup. J’ai vu un script d’ouverture de session mettre chaque adaptateur non identifié en Privé, ce qui a discrètement exposé le partage de fichiers sur un réseau sans fil d’hôtel. Trois conditions décident la réponse, et toutes doivent être réunies avant de toucher au réglage.
Ce que la catégorie décide vraiment
Network Location Awareness construit une signature pour chaque réseau connecté à partir de ce que l’adaptateur peut rapporter : l’adresse de passerelle et la MAC, le suffixe DNS, la réponse éventuelle d’un contrôleur de domaine et l’accès du réseau à internet. Windows attache un profil à cette signature, puis le pare-feu applique le jeu de règles de ce profil. Public est la valeur de repli lorsque l’identification échoue, ce qui explique qu’un tunnel fonctionnel puisse encore être étiqueté réseau non identifié.
Un adaptateur TUN ou TAP donne généralement très peu d’informations à l’identification. Le pair du tunnel est souvent une adresse unique plutôt qu’une passerelle, le DNS n’est parfois poussé que dans le tunnel, et l’adaptateur n’a pas de route par défaut propre. L’étiquette obtenue décrit l’entrée du pare-feu, pas la santé du tunnel, et c’est la raison pour laquelle les règles du profil privé cessent de correspondre à l’instant où le VPN se connecte.
Première condition : le tunnel est le chemin de confiance
Choisir Privé affirme que tout ce qui est joignable par cette interface est au moins aussi digne de confiance que votre propre LAN, car la découverte et les règles d’entrée traiteront ce sous-réseau comme local. Pour un tunnel d’entreprise vers un sous-réseau administré avec des serveurs de fichiers et des imprimantes, l’affirmation tient généralement. L’adaptateur est une porte vers un réseau que votre organisation contrôle, et la machine d’en face a été admise par la même stratégie que la vôtre.
Une sortie VPN commerciale échoue à ce test. D’autres abonnés partagent le sous-réseau de sortie, et le marquer Privé place la découverte réseau, LLMNR et la résolution de noms NetBIOS sur un segment plein d’inconnus. Le tunnel divisé peut aussi échouer : lorsque l’adaptateur ne porte qu’une route d’hôte vers une application, il n’y a pas de sous-réseau de confiance dont parler, et le changement de catégorie ne vous apporte rien.
Deuxième condition : la classification survit aux reconnexions
Une nouvelle passerelle ou un nouveau suffixe DNS produit une nouvelle signature, et Windows prend une décision de profil inédite pour elle. Un Set-NetConnectionProfile ponctuel ne survit donc que jusqu’à la reconnexion suivante, pas indéfiniment. Vérifiez le profil après une reconnexion plutôt qu’après la première connexion, car c’est là que le réglage revient de lui-même.
Trois méthodes permettent de le rendre durable. La plus propre est la stratégie : ouvrez secpol.msc, allez dans Network List Manager Policies et définissez le type d’emplacement du réseau, y compris la stratégie des réseaux non identifiés, afin que le profil soit appliqué par stratégie et non par commande. La deuxième est un script par connexion ou une tâche planifiée qui exécute la cmdlet PowerShell une fois le tunnel monté. La troisième est la vieille astuce de route, qui donne à l’identification une passerelle à sonder :
route -p add 0.0.0.0 mask 0.0.0.0 10.8.0.1 metric 50 IF 24
Get-NetConnectionProfileL’astuce de route est un contournement, pas une classification. Elle se casse lorsque le rapport de métriques change ou que le client VPN réécrit les routes à la reconnexion, et elle modifie silencieusement la sélection de chemin pour tout ce qui retombe sur la seconde route par défaut.
Troisième condition : vous avez besoin du jeu de règles privé
Privé porte généralement le partage de fichiers et d’imprimantes, la découverte réseau et les groupes d’administration à distance. Si la tâche est d’atteindre un partage SMB ou une imprimante à travers le tunnel, c’est la vraie raison de changer de catégorie. Si la tâche est un accès sortant à une application web, la catégorie est sans objet : écrivez la règle sortante, gardez Public et arrêtez-vous là.
| Scenario | Category | Why |
|---|---|---|
| Corporate tunnel to a file server or printer | Private | Private rules carry the sharing you need |
| Commercial VPN for privacy | Public | The exit subnet is shared with strangers |
| Split tunnel with a single host route | Public | No trusted subnet and an unstable signature |
| Site-to-site tunnel to a branch LAN | Private | The far subnet is managed like the local one |
| Lab adapter you control end to end | Private | Discovery helps and nothing else is exposed |
Lisez le tableau comme un point de départ, puis vérifiez quelles règles privées sont réellement activées sur votre image. Une image durcie a peut-être supprimé entièrement le partage de fichiers du profil privé, auquel cas le changement de catégorie n’apporte rien tant que vous n’ajoutez pas la règle. Cette vérification coûte une commande et fait gagner un long après-midi.
Faire le changement sans élargir tout le reste
Ciblez l’index d’interface, pas un caractère générique, et lisez la liste avant et après :
Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex 24 -NetworkCategory Private
Get-NetFirewallProfileLes profils enregistrés vivent sous la clé NetworkList du registre, où la valeur Category sépare les réseaux publics, privés et de domaine. La modifier est possible et facile à rater : vous devez changer l’entrée qui correspond à la signature actuelle de l’adaptateur, pas une entrée plus ancienne laissée par une adresse précédente. Une entrée périmée paraît correcte dans l’éditeur et ne fait rien à la reconnexion.
Quoi que vous fassiez, ne livrez pas un script qui met chaque adaptateur non identifié en Privé. C’est la version en une ligne de l’ouverture de la découverte sur un sans-fil non fiable. Si vous n’avez besoin de partage qu’avec le sous-réseau du tunnel, gardez le profil Public et ajoutez des règles d’entrée limitées à la plage d’adresses distantes du tunnel ; la règle de pare-feu est plus étroite que la catégorie.
Vérifiez le partage, pas l’étiquette
Après le changement, testez la ressource elle-même au lieu de faire confiance à l’étiquette :
Test-NetConnection files.corp.example -Port 445
Resolve-DnsName files.corp.exampleSi le partage échoue encore alors que l’adaptateur affiche Privé, la catégorie n’est plus votre problème. La résolution de noms, une route manquante ou les droits de partage produiront le même symptôme, et un nouveau changement de profil ne peut réparer aucun d’eux. Reconnectez-vous une fois et relancez Get-NetConnectionProfile pour confirmer que le réglage a tenu, puis traitez la panne restante comme un problème SMB ordinaire.
Liste de contrôle : confirmez que le tunnel est un chemin administré, que le profil survit à une reconnexion, que les règles privées nécessaires existent sur l’image et que le partage se résout et répond sur le port 445. Si l’une des trois premières est fausse, laissez l’adaptateur en Public et résolvez le problème d’accès avec une règle limitée.