Always On VPN n’est pas un accès au LAN : liste de vérification des ressources

Always On décrit un cycle de vie de connexion : le profil se connecte au moment de l’ouverture de session ou avant, et se reconnecte sans que l’utilisateur appuie sur quoi que ce soit. Cela ne signifie pas que toutes les destinations privées, tous les protocoles et tous les utilisateurs sont autorisés. La vraie question est de savoir quelles ressources le profil déployé fournit réellement, et cette réponse exige une vérification par ressource, pas un coup d’œil au badge Connecté.

Étape 1 : notez la ressource avant de la tester

Commencez par une fiche courte par application, tirée de l’environnement réel : nom, préfixe de destination, service et port, rôle du tunnel, groupe d’identité et chemin du résolveur.

Name: portal.corp.example
Destination: 10.20.5.0/24
Service: HTTPS 443
Tunnel role: user access after sign-in
Identity: assigned employee group
Resolver: corporate private DNS

La fiche impose quatre questions distinctes. Une route décide où va l’adresse ; une stratégie DNS décide comment le client apprend l’adresse ; un filtre de trafic décide si ce trafic peut utiliser la connexion ; le pare-feu de la destination et les autorisations de l’application décident si la demande est acceptée. Aucune des quatre ne découle d’un tunnel connecté.

Étape 2 : déterminez quel tunnel doit le porter

Windows Always On VPN dispose d’un tunnel d’appareil et d’un tunnel utilisateur, configurés comme des profils séparés avec des certificats et des portées séparés. Le tunnel d’appareil ne transporte généralement que l’infrastructure nécessaire avant l’ouverture de session, comme la gestion et les services de domaine ; l’accès large des employés aux applications relève du tunnel utilisateur.

Les filtres de trafic sont une fonction du tunnel d’appareil, c’est pourquoi l’exemple Microsoft les utilise pour le trafic de gestion. Copier cet exemple dans un profil général de ressources donne un tunnel qui se connecte mais transporte le mauvais ensemble. Confirmez la connexion active avec Get-VpnConnection et testez sous cette connexion.

Étape 3 : vérifiez la route pour l’adresse réelle

Résolvez le nom une fois, puis contrôlez la route : Find-NetRoute -RemoteIPAddress 10.20.5.10 indique l’interface retenue, le prochain saut et l’adresse source. Si l’interface est l’adaptateur physique, le préfixe manque dans le jeu de routes du tunnel ou le client l’a exclu via un tunnel fractionné. Comparez avec la définition du profil au lieu d’ajouter une route locale.

Une route add locale peut faire réussir le test et disparaître au prochain rafraîchissement de stratégie ; la modification doit donc être portée par le profil géré. Vérifiez le préfixe dans le profil utilisateur et dans le profil d’appareil, ainsi que le réglage de tunnel fractionné : un tunnel complet n’a pas besoin de route par préfixe, un tunnel fractionné en a besoin d’une par préfixe privé.

Étape 4 : testez la résolution des noms privés séparément

Les noms privés constituent leur propre chemin de stratégie. Le profil peut fournir des règles NRPT et une liste de suffixes DNS à rechercher, valables tant que le tunnel est établi. Lisez avec Get-DnsClientNrptPolicy ce que le client a réellement reçu, puis testez un nom et une adresse dans la même session. Si les noms échouent alors que les adresses fonctionnent, c’est le résolveur ; si les deux échouent, c’est la route.

Un nom peut aussi se résoudre vers une adresse hors des routes du tunnel, ce qui mélange réussite et délai dépassé. Comparez l’adresse renvoyée avec le préfixe de votre fiche ; si elles diffèrent, la zone privée répond par une adresse publique ou alternative et la route correspondante n’est pas celle prévue.

Étape 5 : contrôlez les filtres, l’identité et la porte de l’application

Les filtres de trafic limitent les protocoles et ports autorisés à utiliser le tunnel d’appareil, et un ensemble étroit peut bloquer une ressource que la route transporterait. Le profil affecte la connexion à un groupe, mais la ressource possède sa propre autorisation : un utilisateur qui peut se connecter n’est pas accepté automatiquement par le serveur de fichiers.

Modifiez le profil géré par son propriétaire, qu’il s’agisse d’Intune, d’un déploiement ProfileXML ou d’un script d’exploitation, puis retestez après une reconnexion normale et après un redémarrage : la panne habituelle est une route locale obsolète ou un profil appliqué une seule fois. Conservez la version du profil à côté du résultat du test.