Eén VPN, twee Windows-accounts: waarom de andere sessie stukgaat

Twee mensen zijn aangemeld, een van hen maakt verbinding met de bedrijfstunnel, en de browser van het andere account laadt pagina's niet meer die een minuut geleden nog werkten. Op dezelfde machine is ook de vermelding Gebruiker wisselen van het aanmeldingsscherm verdwenen, zodat de tweede persoon niet terug kan naar zijn eigen sessie. Dit vanaf de tweede sessie naar buiten toe volgen is de snelste manier om het te begrijpen, want aan de verbinding van de eerste gebruiker is niets verborgen, en aan het probleem van de tweede gebruiker is niets mysterieus zodra je ziet welke objecten gedeeld worden.

Begin in de sessie die stukging

Ga naar het bureaublad van het tweede account, niet het eerste. Open daar een terminal en bekijk de routetabel en de resolverlijst terwijl de andere sessie verbonden is. Alles wat je ziet hoort bij de machine, niet bij de andere gebruiker, en dat is de eerste aanwijzing.

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

Als de standaardroute nu naar de tunnelinterface wijst, volgt het verkeer van de tweede gebruiker die ook. Als de resolverlijst een privéserver heeft gekregen, gaan hun opzoekingen nu ergens heen waar ze niet kunnen komen zodra de tunnel wegvalt. Geen van beide is een fout in de client; het zijn de gevolgen van één gedeelde netwerkstack.

De derde opdracht verklaart een tweede klasse van klachten. Wanneer een adapter de machine van een openbare naar een particuliere netwerkcategorie omschakelt, veranderen de firewallregels die aan een profiel gekoppeld zijn voor alle accounts tegelijk, zodat toepassingen die 's ochtends waren toegestaan 's middags geblokkeerd kunnen worden zonder dat iemand een regel aanraakt.

De verbinding is per gebruiker, het netwerk niet

Windows bewaart het verbindingsobject in het profiel van de gebruiker die het heeft gemaakt. De virtuele adapter die het oplevert, de routes die het installeert en de DNS-servers die het registreert zijn machinebreed. Die splitsing is de bron van beide symptomen in de titel.

Het verklaart ook waarom het afmelden van de eerste gebruiker meestal de tweede oplost. De verbinding verwijderen verwijdert de adapter en de routes mee, en de machinebrede toestand keert terug naar wat die was voordat iemand inbelde. Dat is een nuttige diagnose: als afmelden het andere account repareert, kijk je naar gedeelde toestand en niet naar een kapot profiel.

Wat je niet kunt, is de tweede sessie een andere routetabel geven. Er is één tabel, en elke twee sessies delen die. Dat is een eigenschap van het besturingssysteem en geen beperking van een bepaalde client. Het betekent ook dat elk ontwerp dat anders veronderstelt zal blijven falen, en die fouten zullen op ongerelateerde applicatiefouten lijken.

Zoek wat de vermelding Gebruiker wisselen heeft verwijderd, in deze volgorde

Snel wisselen van gebruiker is om een heel andere reden verdwenen, en de oplossing heeft niets met routing te maken. Werk de vier kandidaten in volgorde af, want de eerste twee zijn binnen seconden terug te draaien en de latere hebben een prijs.

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

De registerwaarde is de eenvoudigste verklaring. Als die bestaat en 1 leest, is de vermelding door beleid verborgen, en het groepbeleidspad is Computer Configuration, Administrative Templates, System, Logon, en de instelling die is genoemd naar het verbergen van de ingangspunten voor snel wisselen van gebruiker. Zet die op Not Configured en vernieuw met gpupdate /force.

De tweede opdracht vertelt je of dat beleid van een domein wordt aangeleverd in plaats van lokaal geschreven. Als het in het rapport verschijnt met een winnende GPO, is het bewerken van de lokale waarde een tijdelijke oplossing die bij de volgende vernieuwing terugdraait, en het gesprek hoort bij wie het beleid bezit.

De derde opdracht dekt het andere mechanisme. Een provider voor referenties of netwerktoegang die een aanmeldingsmodule installeert, kan de vermelding onderdrukken terwijl hij draait, en sommige clients registreren ook een component die vóór het aanmelden start en een claim op het aanmeldingsscherm houdt. Die service uitschakelen herstelt het wisselen, en het verwijdert ook de functies vóór aanmelding of posture waarvoor de module bestaat.

Wijzig het zonder jezelf buiten te sluiten

Houd één beheersessie open terwijl je werkt, en wijzig nooit iets op het aanmeldingsscherm op een machine die je alleen via dat scherm bereikt. Meld de andere sessies eerst af, pas de wijziging toe, vernieuw, en test daarna door van gebruiker te wisselen in plaats van door opnieuw op te starten.

Noteer welke posture-functies je hebt uitgeschakeld. Een clientupdate kan de aanmeldingsmodule opnieuw installeren of weer inschakelen, en het symptoom komt terug zonder duidelijke oorzaak, meestal midden in een supportvenster wanneer niemand zich de eerdere wijziging herinnert.

Ga op een beheerd apparaat ervan uit dat de instelling van bovenaf wordt aangeleverd. Eerst het beleidsrapport controleren bespaart een uur aan lokale bewerkingen die terugdraaien. Het vertelt je ook wie je moet vragen als het antwoord nee is. Een ticket dat het winnende beleid noemt, wordt twee keer zo snel opgelost als een dat een registersleutel beschrijft die iemand al heeft gewijzigd.

Controleer beide accounts en kies het model

Test de uitkomst in de volgorde waarin de twee gebruikers die ervaren. Meld je aan als het tweede account terwijl het eerste is losgekoppeld, bevestig normale toegang, maak dan de tunnel van het eerste account vast en bevestig dat het verwachte pad van het tweede account nog steeds is wat je bedoelde.

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

Als beide accounts echt tegelijk verschillende netwerkpaden nodig hebben, is het eerlijke antwoord twee machines, twee virtuele machines of een beleid waarbij maar één pad nodig is. Een split-tunnel op de gedeelde verbinding kan beperken wat er beweegt, maar kan niet elke sessie zijn eigen tabel geven. Daar vroeg achter komen is goedkoper dan het te ontdekken na drie geprobeerde omwegen.

Dat is de beslissing die je expliciet moet nemen in plaats van eromheen te patchen. Eén routetabel, één resolverlijst, één firewallprofiel: al het overige volgt daaruit, en de oplossing die dat respecteert werkt volgend maand nog.