Tunnel d’appareil ou tunnel d’utilisateur dans Windows Always On VPN ?

Un portable qui doit joindre un serveur d’administration depuis l’écran de connexion et un portable qui doit joindre des partages de fichiers après l’authentification de l’utilisateur sont deux problèmes différents. Windows les résout avec deux tunnels différents, et la différence n’est pas celui qui apparaît dans la liste des profils. Le tunnel d’appareil s’exécute en tant que machine, avant que quiconque se connecte. Le tunnel d’utilisateur s’exécute en tant que personne, après que la plateforme dispose d’une identité avec laquelle travailler. Choisir entre les deux commence par le moment où le trafic doit circuler, pas par les ressources à joindre.

Deux identités, deux moments

Le tunnel d’appareil s’établit dans le contexte machine, ce qui lui permet de porter le trafic nécessaire pour authentifier un utilisateur ou pour que les agents d’administration se signalent avant l’ouverture de session. Le tunnel d’utilisateur s’établit dans le contexte utilisateur, après l’ouverture de session, avec les informations d’identification de l’utilisateur et la stratégie qui s’applique à ce compte.

Cet écart de temporalité est tout le design. Tout le reste en découle, y compris les méthodes d’authentification disponibles et les ressources qui ont un sens.

Si le besoin est une application métier utilisée par une personne connectée, le tunnel d’utilisateur y répond. Si le besoin est un contrôleur de domaine, une autorité de certification ou un service d’administration joignable depuis l’écran de connexion, seul le tunnel d’appareil est assez précoce.

Le carnet d’adresses n’est pas la distinction

Enregistrer un profil natif dans le carnet d’adresses de tous les utilisateurs ne crée pas un tunnel d’appareil. Le profil devient disponible pour chaque utilisateur de la machine, ce qui est une question de portée de stockage, et il se connecte toujours dans le contexte utilisateur.

Un véritable tunnel d’appareil se configure comme tel, avec les exigences de plateforme, de protocole et de certificat que Microsoft documente pour lui. Ces exigences incluent une édition qui le prend en charge, un appareil joint au domaine, IKEv2 et l’authentification par certificat machine. Un profil nommé device, copié d’un tunnel d’utilisateur et renommé, ne satisfait rien de tout cela.

La documentation Microsoft du tunnel d’appareil est la référence pour la forme du profil, et elle mérite d’être lue avant de supposer qu’un profil utilisateur fonctionnel peut être réutilisé.

Gardez chaque chemin étroit

Le tunnel d’appareil ne devrait joindre que ce dont la machine a besoin avant l’ouverture de session : l’annuaire, l’autorité de certification, le point de terminaison d’administration et les enregistrements DNS qui les résolvent. Ses routes et règles de pare-feu devraient refléter cette courte liste plutôt que la plage d’entreprise complète.

Le tunnel d’utilisateur porte l’accès de la personne et peut être limité par groupe, application ou destination selon les besoins du déploiement. Mélanger les deux portées est la façon dont un tunnel établi avant l’ouverture de session finit par disposer d’un accès aux partages de fichiers qu’aucun compte machine ne devrait jamais avoir.

Les deux tunnels peuvent être déployés ensemble, et dans la plupart des conceptions Always On ils le sont. Le tunnel d’appareil monte en premier et reste étroit. Le tunnel d’utilisateur monte à l’ouverture de session et porte le trafic de travail. Si vous n’en déployez qu’un, décidez à quelle panne vous pouvez survivre. Un écran de connexion sans réseau et un tunnel d’utilisateur portant du trafic d’administration sont tous deux mauvais, mais un seul des deux est généralement acceptable dans votre environnement.

Testez l’étape, pas le navigateur

Une requête de navigateur qui aboutit après l’ouverture de session prouve le tunnel d’utilisateur et ne dit rien du tunnel d’appareil. Testez les étapes séparément : démarrage à froid jusqu’à l’écran de connexion, l’ouverture de session elle-même, la connexion utilisateur et la reprise après une veille ou un changement de réseau.

À l’écran de connexion, le contrôle consiste à savoir si la machine peut joindre le point de terminaison d’administration sans aucun utilisateur connecté. C’est le seul moment où le tunnel d’appareil existe seul, et c’est l’étape que les gens sautent parce que la tester exige un redémarrage.

Après l’ouverture de session, vérifiez le tunnel d’utilisateur séparément, y compris le cas où le tunnel d’appareil est actif mais où le tunnel d’utilisateur a échoué. Deux tunnels avec deux états produisent quatre combinaisons, et une seule d’entre elles paraît saine.

Quand cela échoue, nommez d’abord le tunnel

Le renouvellement du certificat machine et la récupération d’un compte utilisateur sont des tâches différentes avec des responsables différents. Un tunnel d’appareil qui échoue après l’expiration d’un certificat ne sera pas réparé en réinitialisant les informations d’identification de l’utilisateur, et un tunnel d’utilisateur qui échoue après un changement de mot de passe ne sera pas réparé en réémettant le certificat machine.

Notez quel tunnel était actif, quelle identité il utilisait et quelle étape a échoué, puis comparez cela aux exigences documentées pour l’édition et l’environnement d’administration utilisés. Copier un vieil assistant VPN générique est la façon dont les déploiements finissent avec un tunnel d’appareil qui ne fonctionne que pour les administrateurs.

Ordre du travail : nommez le moment où le trafic doit circuler, choisissez le tunnel qui existe à ce moment-là, resserrez ses routes, testez chaque étape du cycle de vie séparément et gardez séparées les procédures de récupération des deux identités.