Un VPN, deux comptes Windows : pourquoi l'autre session casse

Deux personnes sont connectées, l'une d'elles établit le tunnel d'entreprise, et le navigateur de l'autre compte cesse de charger des pages qui fonctionnaient une minute plus tôt. Sur la même machine, l'entrée Changer d'utilisateur a aussi disparu de l'écran de connexion, si bien que la seconde personne ne peut pas revenir à sa propre session. Suivre cela depuis la seconde session vers l'extérieur est le moyen le plus rapide de le comprendre, car rien dans la connexion du premier utilisateur n'est caché, et rien dans le problème du second utilisateur n'est mystérieux dès que l'on voit quels objets sont partagés.

Commencez par la session qui a cassé

Allez sur le bureau du second compte, pas celui du premier. Ouvrez-y un terminal et regardez la table de routage et la liste des résolveurs pendant que l'autre session est connectée. Tout ce que vous voyez appartient à la machine, pas à l'autre utilisateur, et c'est le premier indice.

Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric | Select-Object -First 12 DestinationPrefix,NextHop,InterfaceAlias
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias,ServerAddresses
Get-NetConnectionProfile | Select-Object Name,NetworkCategory,IPv4Connectivity

Si la route par défaut pointe désormais vers l'interface du tunnel, le trafic du second utilisateur la suit aussi. Si la liste des résolveurs a gagné un serveur privé, leurs requêtes vont maintenant là où ils ne pourront pas atteindre une fois le tunnel tombé. Ni l'un ni l'autre n'est un défaut du client ; ce sont les conséquences d'une pile réseau unique et partagée.

La troisième commande explique une seconde catégorie de plaintes. Quand un adaptateur fait passer la machine d'une catégorie de réseau public à privé, les règles de pare-feu limitées à un profil changent pour tous les comptes à la fois, si bien que des applications autorisées le matin peuvent être bloquées l'après-midi sans que personne ne touche à une règle.

La connexion est par utilisateur, le réseau ne l'est pas

Windows garde l'objet de connexion dans le profil de l'utilisateur qui l'a créé. L'adaptateur virtuel qu'elle produit, les routes qu'elle installe et les serveurs DNS qu'elle enregistre sont à l'échelle de la machine. Cette séparation est la source des deux symptômes du titre.

Cela explique aussi pourquoi fermer la session du premier utilisateur corrige généralement le second. Retirer la connexion retire l'adaptateur et les routes avec elle, et l'état de toute la machine revient à ce qu'il était avant que quiconque se connecte. C'est un diagnostic utile : si la fermeture de session répare l'autre compte, vous regardez un état partagé et non un profil cassé.

Ce que vous ne pouvez pas faire, c'est donner à la seconde session une autre table de routage. Il y a une seule table, et deux sessions quelconques la partagent. C'est une propriété du système d'exploitation et non une limite d'un client particulier. Cela signifie aussi que toute conception qui suppose le contraire continuera d'échouer, et les échecs ressembleront à des bogues d'application sans rapport.

Trouvez ce qui a supprimé Changer d'utilisateur, dans cet ordre

Le changement rapide d'utilisateur a disparu pour une raison complètement différente, et le correctif n'a rien à voir avec le routage. Parcourez les quatre candidats dans l'ordre, car les deux premiers sont réversibles en quelques secondes et les suivants ont un coût.

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' -Name HideFastUserSwitching
gpresult /h $env:TEMP\gp.html
Get-Service | Where-Object { $_.DisplayName -match 'Logon|Access|Credential' } | Select-Object Status,Name,DisplayName

La valeur de registre est l'explication la plus simple. Si elle existe et lit 1, l'entrée est masquée par stratégie, et le chemin de stratégie de groupe est Configuration de l'ordinateur, Modèles d'administration, Système, Ouverture de session, et le paramètre nommé d'après le masquage des points d'entrée du changement rapide d'utilisateur. Mettez-le sur Non configuré et actualisez avec gpupdate /force.

La deuxième commande vous dit si cette stratégie est fournie par un domaine plutôt qu'écrite localement. Si elle apparaît dans le rapport avec un GPO gagnant, modifier la valeur locale est un correctif temporaire qui revient à la prochaine actualisation, et la conversation appartient au propriétaire de la stratégie.

La troisième commande couvre l'autre mécanisme. Un fournisseur d'informations d'identification ou d'accès réseau qui installe un module d'ouverture de session peut supprimer l'entrée pendant qu'il fonctionne, et certains clients enregistrent aussi un composant qui démarre avant l'ouverture de session et conserve une revendication sur l'écran de connexion. Désactiver ce service rétablit le changement, et supprime aussi les fonctions de pré-ouverture de session ou de posture pour lesquelles le module existe.

Modifiez-le sans vous verrouiller dehors

Gardez une session administrative ouverte pendant que vous travaillez, et ne faites jamais de modification de l'écran de connexion sur une machine à laquelle vous n'accédez que par cet écran. Fermez d'abord les autres sessions, appliquez la modification, actualisez, puis testez en changeant d'utilisateur plutôt qu'en redémarrant.

Notez les fonctions de posture que vous avez désactivées. Une mise à jour du client peut réinstaller ou réactiver le module d'ouverture de session, et le symptôme revient sans cause évidente, généralement au milieu d'une fenêtre de support quand personne ne se souvient du changement précédent.

Sur un appareil géré, supposez que le paramètre est fourni d'en haut. Vérifier d'abord le rapport de stratégie épargne une heure de modifications locales qui reviennent. Cela vous dit aussi à qui demander quand la réponse est non. Un ticket qui nomme la stratégie gagnante est résolu deux fois plus vite qu'un qui décrit une clé de registre que quelqu'un a déjà modifiée.

Vérifiez les deux comptes et choisissez le modèle

Testez le résultat dans l'ordre où les deux utilisateurs le vivent. Connectez-vous en tant que second compte avec le premier déconnecté, confirmez l'accès normal, puis connectez le tunnel du premier compte et confirmez que le chemin attendu du second compte est toujours celui que vous vouliez.

qwinsta
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Select-Object InterfaceAlias,NextHop,RouteMetric
Test-NetConnection -ComputerName intranet.example.internal -Port 443

Si les deux comptes ont réellement besoin de chemins réseau différents en même temps, la réponse honnête est deux machines, deux machines virtuelles ou une stratégie où un seul chemin est requis. Un tunnel divisé sur la connexion partagée peut réduire ce qui circule, mais il ne peut pas donner à chaque session sa propre table. Y arriver tôt coûte moins cher que le découvrir après trois tentatives de contournement.

C'est la décision à prendre explicitement plutôt qu'à contourner par des rustines. Une table de routage, une liste de résolveurs, un profil de pare-feu : tout le reste en découle, et le correctif qui respecte cela fonctionnera encore le mois prochain.