Én VPN, to Windows-konti: hvorfor den anden session bryder sammen

To personer er logget ind, en af dem opretter forbindelse til virksomhedens tunnel, og den anden kontoes browser holder op med at indlæse sider, der var i orden for et minut siden. På samme maskine er posten Skift bruger også forsvundet fra logon-skærmen, så den anden person kan ikke komme tilbage til sin egen session. At følge det fra den anden session og udefter er den hurtigste måde at forstå det på, fordi intet ved den første brugers forbindelse er skjult, og intet ved den anden brugers problem er mystisk, når først du ser, hvilke objekter der deles.

Begynd i den session, der brød sammen

Gå til den anden kontos skrivebord, ikke den førstes. Åbn en terminal der og se på routingtabellen og resolverlisten, mens den anden session er forbundet. Alt, hvad du ser, tilhører maskinen, ikke den anden bruger, og det er det første spor.

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

Hvis standardruten nu peger på tunnelgrænsefladen, følger den anden brugers trafik den også. Hvis resolverlisten har fået en privat server, går deres opslag nu et sted hen, som de ikke kan nå, når tunnelen falder. Ingen af delene er en fejl i klienten; de er konsekvenserne af en enkelt, delt netværksstak.

Den tredje kommando forklarer en anden klasse af klager. Når en adapter skifter maskinen fra en offentlig til en privat netværkskategori, ændres firewallregler, der er afgrænset til en profil, for alle konti på én gang, så programmer, der var tilladt om morgenen, kan blive blokeret om eftermiddagen, uden at nogen rører en regel.

Forbindelsen hører til brugeren, netværket gør ikke

Windows opbevarer forbindelsesobjektet i profilen for den bruger, der oprettede det. Den virtuelle adapter, den frembringer, de ruter, den installerer, og de DNS-servere, den registrerer, gælder for hele maskinen. Den opdeling er kilden til begge symptomer i titlen.

Det forklarer også, hvorfor det normalt løser den anden at logge den første bruger ud. At fjerne forbindelsen fjerner adapteren og ruterne med den, og maskinens samlede tilstand vender tilbage til det, den var, før nogen ringede ind. Det er en nyttig diagnose: hvis udlogning reparerer den anden konto, ser du på delt tilstand og ikke på en ødelagt profil.

Det, du ikke kan, er at give den anden session en anden routingtabel. Der er én tabel, og to vilkårlige sessioner deler den. Det er en egenskab ved operativsystemet og ikke en begrænsning i en bestemt klient. Det betyder også, at ethvert design, der antager det modsatte, bliver ved med at fejle, og fejlene vil se ud som urelaterede programfejl.

Find ud af, hvad der fjernede Skift bruger, i denne rækkefølge

Hurtigt brugerskift forsvandt af en helt anden grund, og rettelsen har intet med routing at gøre. Gå gennem de fire kandidater i rækkefølge, fordi de to første kan vendes på sekunder, og de senere har en pris.

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

Registreringsværdien er den enkleste forklaring. Hvis den findes og læses som 1, er posten skjult af politik, og gruppepolitikstien er Computerkonfiguration, Administrative skabeloner, System, Logon og indstillingen opkaldt efter at skjule indgangspunkter for hurtigt brugerskift. Sæt den til Ikke konfigureret, og opdater med gpupdate /force.

Den anden kommando fortæller, om den politik leveres fra et domæne i stedet for at være skrevet lokalt. Hvis den optræder i rapporten med en vindende GPO, er redigering af den lokale værdi en midlertidig rettelse, der vender tilbage ved næste opdatering, og samtalen hører til den, der ejer politikken.

Den tredje kommando dækker den anden mekanisme. En legitimations- eller netværksadgangsudbyder, der installerer et logonmodul, kan undertrykke posten, mens den kører, og nogle klienter registrerer også en komponent, der starter før logon, og som holder et krav på logon-skærmen. Hvis tjenesten deaktiveres, gendannes skiftet, og det fjerner også de præ-logon- eller posturefunktioner, som modulet findes for at levere.

Skift det uden at låse dig selv ude

Hold en administrativ session åben, mens du arbejder, og lav aldrig en ændring på logon-skærmen på en maskine, du kun kan nå gennem den skærm. Log de andre sessioner ud først, anvend ændringen, opdater, og test derefter ved at skifte bruger i stedet for at genstarte.

Noter, hvilke posturefunktioner du deaktiverede. En klientopdatering kan geninstallere eller genaktivere logonmodulet, og symptomet vender tilbage uden åbenlys årsag, normalt midt i et supportvindue, når ingen husker den tidligere ændring.

På en administreret enhed bør du antage, at indstillingen leveres ovenfra. At tjekke politikrapporten først sparer en time med lokale ændringer, der vender tilbage. Det fortæller dig også, hvem du skal spørge, når svaret er nej. En sag, der navngiver den vindende politik, bliver løst dobbelt så hurtigt som en, der beskriver en registreringsnøgle, som nogen allerede har ændret.

Bekræft begge konti, og vælg modellen

Test resultatet i den rækkefølge, de to brugere oplever det. Log ind som den anden konto, mens den første er afbrudt, bekræft normal adgang, og tilslut derefter den første kontos tunnel, og bekræft, at den anden kontos forventede rute stadig er den, du havde til hensigt.

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

Hvis begge konti virkelig har brug for forskellige netværksruter på samme tid, er det ærlige svar to maskiner, to virtuelle maskiner eller en politik, hvor kun én rute kræves. En split tunnel på den delte forbindelse kan indsnævre, hvad der flyttes, men den kan ikke give hver session sin egen tabel. At nå dertil tidligt er billigere end at opdage det efter tre forsøg på omveje.

Det er beslutningen, der skal træffes eksplicit i stedet for at lappe rundt om den. Én routingtabel, én resolverliste, én firewallprofil: alt andet følger af det, og rettelsen, der respekterer det, virker stadig i næste måned.