Pourquoi Always On VPN cesse de se déclencher sur le réseau du bureau

L’ordinateur portable rejoint le Wi-Fi du bureau, et le profil Always On qui se connectait depuis la maison reste inactif. Rien dans le journal des événements ne parle d’échec, car du point de vue du client le réseau est approuvé et le tunnel est inutile. La détection de réseau approuvé est la fonction qui prend cette décision, et elle compare des valeurs précises plutôt que de reconnaître un SSID familier. Quand la décision est erronée, il faut voir quelle comparaison a réussi.

Ce que le déclencheur compare réellement

Trois éléments doivent concorder avant que le client ne considère un réseau comme approuvé. Premièrement, le suffixe DNS propre à la connexion que Windows enregistre pour l’adaptateur physique doit figurer dans la liste de suffixes du profil. Deuxièmement, le profil de connexion que Windows conserve pour ce réseau doit être celui que la stratégie attend, car la correspondance se fait avec ce profil et non avec un nom qu’un utilisateur aurait saisi dans une boîte de dialogue sans fil. Troisièmement, le réseau doit être classé comme la stratégie l’exige, ce qui signifie en pratique un réseau de domaine ou privé, ou un appareil dont la stratégie est arrivée par la gestion. Retirez l’un des trois et le déclencheur s’active.

C’est un test plus étroit que la comparaison de l’adresse de sortie publique du VPN, et bien plus étroit que la confiance accordée à un SSID. Un point d’accès qui reprend le nom de l’entreprise ne satisfait pas à lui seul les comparaisons de suffixe et de profil. Cela signifie aussi que la fonction ne dit rien sur la sécurité d’un réseau ; elle dit si cet appareil croit qu’il est déjà chez lui.

Lisez l’état actuel avant de modifier le profil

Commencez par ce que Windows croit actuellement. L’applet de commande de profil de connexion indique le nom du réseau, l’interface et la catégorie que Windows a attribuée, soit la troisième comparaison ci-dessus. Lisez ensuite le profil VPN et cherchez la liste des suffixes approuvés, avec un vidage complet des propriétés plutôt qu’en devinant leurs noms :

Get-NetConnectionProfile
Get-VpnConnection -Name "Corp VPN" | Format-List *

Si ce vidage n’expose pas le suffixe approuvé sur votre version, revenez au XML du profil, qui est la copie de référence lorsque la surface des propriétés diffère selon les versions. Lisez le XML depuis la stratégie de gestion ou depuis le magasin de profils de tous les utilisateurs, et comparez ses entrées de suffixe avec le suffixe d’adaptateur indiqué ci-dessus. Notez les deux valeurs avant de toucher à l’une d’elles.

Testez la frontière dans les deux sens

Testez sur le rattachement d’entreprise prévu et sur un autre réseau approuvé, et notez si le tunnel s’est levé. Testez ensuite le même appareil après l’avoir quitté. Un portable qui se déclenche à la maison et se supprime au bureau se comporte comme prévu, tandis que celui qui ne se déclenche nulle part présente un autre défaut. Vérifiez que les ressources derrière le tunnel sont joignables lorsque le déclenchement a lieu, car un tunnel démarré ne prouve pas qu’un chemin fonctionne.

N’ajoutez pas un suffixe large simplement pour faire disparaître une notification. Un suffixe présent sur de nombreux réseaux apprend au client à supprimer le tunnel presque partout, et la charge de support qui suit est pire que la notification. Changez les critères par l’intermédiaire du propriétaire du profil, qui dans un parc géré est l’administrateur MDM et non la personne devant le portable.

Conservez les deux réseaux de test dans le dossier avec le résultat. Une frontière jamais testée n’est qu’une affirmation.

Distinguez la suppression du blocage

Un tunnel qui n’a pas démarré n’est pas une connexion bloquée. La détection de réseau approuvé pilote le déclenchement automatique, tandis que le filtrage du trafic et le comportement de kill-switch sont des paramètres de stratégie distincts avec leurs propres modes de défaillance. Un appareil sur un réseau approuvé peut légitimement émettre du trafic hors du tunnel, et qualifier cela de fuite sans lire la stratégie confond deux conceptions. Vérifiez les règles de trafic du profil avant d’accuser la détection d’une fuite.

La même distinction explique la plainte inverse. Les utilisateurs qui signalent que le VPN s’est arrêté au hasard décrivent généralement un changement de réseau qui satisfaisait les critères, et non une panne de service. Le suffixe correspondant et la catégorie de réseau sont les preuves à recueillir, et les deux figurent dans la sortie ci-dessus.

Recueillez ces preuves avant de modifier la stratégie. Un commutateur qui masque le symptôme masque aussi la cause.

Notez sur quoi la décision reposait

Inscrivez le suffixe correspondant, le nom du profil de connexion et la catégorie de réseau dans les notes de déploiement de chaque site. Quand le tunnel ne se lève pas, cette trace transforme un mystère en comparaison : soit l’une des trois valeurs a changé, soit la stratégie. Elle donne aussi au prochain ingénieur un moyen de confirmer la conception au lieu de désactiver la détection pour clore le ticket.

Revoyez la liste de suffixes lorsqu’un site est renommé ou qu’un domaine est consolidé, car une entrée obsolète continue de supprimer le tunnel en silence. La référence Microsoft sur la détection de réseau approuvé énumère les éléments de profil et les prérequis de déploiement, et c’est le document à citer quand quelqu’un propose d’élargir la liste.