Windows affiche Réseau non identifié pour toute interface qu’il ne peut pas classer dans un emplacement, et un adaptateur VPN est un candidat courant parce qu’il n’a souvent pas sa propre passerelle par défaut. L’étiquette est une catégorie de pare-feu, pas une affirmation sur le fait que le tunnel se soit authentifié ou que votre application puisse atteindre quoi que ce soit. La traiter comme un message d’erreur, c’est ainsi que les gens finissent par réinitialiser un adaptateur qui fonctionne et perdre la session qui allait bien. Deux commandes vous disent si l’étiquette mérite la moindre attention.

L’étiquette est une catégorie de pare-feu, pas un voyant d’état

La reconnaissance de l’emplacement réseau décide si une interface appartient à un domaine, à un réseau privé ou à un réseau public, puis le pare-feu applique le jeu de règles de cette catégorie. Non identifié est le résultat quand la classification échoue, ce qui place généralement l’interface dans le profil public. Le profil public est celui qui bloque la plupart du trafic entrant par défaut.

Public est le profil restrictif, donc la question pratique est de savoir si votre service y est autorisé. Un tunnel peut être parfaitement sain et afficher quand même l’étiquette, parce que la classification dépend de la forme de l’interface et non de l’état de la connexion.

Cette distinction explique les rapports les plus déroutants : un partage de fichiers qui fonctionnait hier et plus aujourd’hui, sur un adaptateur que personne n’a modifié, parce qu’une règle était limitée au profil privé et que l’interface est désormais en public.

Lisez trois choses avant de changer quoi que ce soit

Vérifiez la catégorie, la configuration de l’adresse et la route vers la destination, dans cet ordre. Si la ressource fonctionne, l’étiquette est cosmétique pour vos besoins et la réponse honnête est de la laisser tranquille.

Ces commandes affichent le profil actuel, l’inventaire des interfaces et la configuration d’un adaptateur :

Get-NetConnectionProfile
Get-NetAdapter | Format-Table Name,InterfaceIndex,Status
Get-NetIPConfiguration -InterfaceAlias "My VPN Adapter"

L’index d’interface compte parce que les cmdlets de profil adressent les interfaces par index, et un portable avec un adaptateur physique, un adaptateur Wi-Fi et un tunnel en a trois. Lire le mauvais produit un diagnostic confiant d’un réseau que personne n’utilise.

Pourquoi l’adaptateur paraît non identifié

La classification cherche des preuves que l’interface appartient quelque part : un contrôleur de domaine qu’elle peut joindre, une passerelle qui se comporte comme un réseau domestique ou une identité résoluble. Une interface de tunnel n’a souvent ni entrée de passerelle ni domaine de diffusion, donc les sondes n’ont rien avec quoi travailler.

Les clients en tunnel complet évitent parfois l’étiquette en attribuant une passerelle ou en portant une route qu’une sonde de classification peut suivre. Les clients en tunnel divisé la montrent plus souvent, parce que le tunnel ne porte que les préfixes pour lesquels il a été configuré et que le reste du trafic sort ailleurs.

Rien de tout cela n’est un défaut. C’est le moteur de classification qui décrit une interface qui ne ressemble pas à un LAN, et c’est exactement ce qu’est un tunnel.

Là où l’étiquette commence à compter, c’est dans la stratégie. Un outil de gestion, un agent de point de terminaison ou une règle de pare-feu qui sélectionne par profil traitera l’interface non identifiée comme publique, et le blocage qui en résulte est réel même si la cause est une étiquette.

Changer la catégorie a des conséquences

Marquer l’interface comme privée est une décision de confiance, et elle applique le jeu de règles privées au trafic qui arrive sur cet adaptateur. Si le tunnel se termine chez un fournisseur que vous ne contrôlez pas, ou si l’appareil peut rejoindre des réseaux non fiables, ce changement élargit ce qui est joignable depuis cette interface. Il rend aussi l’appareil détectable sur un segment de réseau que vous ne possédez peut-être pas. Cela fait beaucoup de conséquences pour une étiquette cosmétique.

Un script large qui met chaque interface non identifiée en privé est pire, parce qu’il applique la même confiance à des adaptateurs que vous n’avez jamais inspectés. Sur un appareil géré, le changement peut aussi être écrasé par la stratégie à la prochaine actualisation, vous laissant un correctif qui fonctionne jusqu’à ce qu’il cesse.

Réparez le flux qui échoue, pas le nom

Partez d’une panne concrète : un partage qui ne s’ouvre pas, un site qui ne charge pas, une imprimante introuvable. Puis séparez les causes — la résolution de noms, la sélection de route, la portée du pare-feu et l’autorisation utilisateur échouent différemment et produisent des messages différents.

Si la panne est un nom, testez la résolution depuis cet adaptateur précisément plutôt que depuis la machine en général. Si c’est une route, affichez la route sélectionnée pour la destination exacte. Si c’est le pare-feu, lisez le profil en vigueur et la règle qui devrait autoriser le trafic, puis décidez si une règle étroite limitée au programme vaut mieux qu’un changement de catégorie.

Ce n’est qu’après avoir éliminé ces trois éléments que la catégorie devient la cause probable, et même alors la réparation devrait être la plus petite qui fasse fonctionner le flux requis. Un nom de réseau plus familier n’est pas l’objectif ; un partage qui fonctionne sous une règle approuvée l’est.

Articles similaires