Isang VPN, dalawang account sa Windows: bakit nasisira ang kabilang session

Dalawang tao ang naka-sign in, kinokonekta ng isa sa kanila ang corporate tunnel, at ang browser ng kabilang account ay tumitigil sa pag-load ng mga pahina na maayos pa isang minuto lang ang nakalipas. Sa parehong makina, nawala rin ang entry na Lumipat ng user sa sign-in screen, kaya hindi na makabalik ang pangalawang tao sa sarili nitong session. Ang pagsunod dito mula sa pangalawang session pakanlabas ay ang pinakamabilis na paraan upang maunawaan ito, dahil wala namang nakatago sa koneksyon ng unang user, at wala ring misteryo sa problema ng pangalawang user kapag nakita mo kung aling mga bagay ang ibinabahagi.

Magsimula sa session na nasira

Pumunta sa desktop ng pangalawang account, hindi ng una. Magbukas ng terminal doon at tingnan ang routing table at ang listahan ng resolver habang nakakonekta ang kabilang session. Ang lahat ng nakikita mo ay pag-aari ng makina, hindi ng kabilang user, at iyon ang unang bakas.

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

Kung ang default route ay tumuturo na ngayon sa tunnel interface, sinusundan din ito ng trapiko ng pangalawang user. Kung may naidagdag na pribadong server sa listahan ng resolver, ang kanilang mga paghahanap ay pumupunta na ngayon sa lugar na hindi nila maabot kapag bumaba ang tunnel. Wala sa mga ito ang bug sa client; mga bunga ito ng isang shared network stack.

Ipinaliwanag ng ikatlong utos ang ikalawang uri ng reklamo. Kapag binago ng adapter ang makina mula sa pampublikong patungo sa pribadong kategorya ng network, sabay na nagbabago ang mga firewall rule na nakatali sa isang profile para sa lahat ng account, kaya ang mga aplikasyong pinayagan sa umaga ay maaaring harangan sa hapon nang walang sinumang humawak sa isang rule.

Ang koneksyon ay per user, ang network ay hindi

Itinatago ng Windows ang connection object sa profile ng user na gumawa nito. Ang virtual adapter na nililikha nito, ang mga rutang ini-install nito at ang mga DNS server na iniirehistro nito ay saklaw ng buong makina. Ang paghahating iyon ang pinagmulan ng dalawang sintomas sa pamagat.

Ipinapaliwanag din nito kung bakit karaniwang inaayos ng pag-sign out ng unang user ang pangalawa. Kapag inalis ang koneksyon, naaalis din ang adapter at ang mga ruta, at ang estado sa buong makina ay bumabalik sa dati bago may kumonekta. Kapaki-pakinabang na diagnostic iyon: kung inaayos ng pag-sign out ang kabilang account, shared state ang tinitignan mo at hindi sirang profile.

Ang hindi mo magagawa ay bigyan ang pangalawang session ng ibang routing table. Isang table lang, at pinaghahatian ito ng kahit aling dalawang session. Property iyon ng operating system at hindi limitasyon ng isang partikular na client. Nangangahulugan din ito na ang anumang disenyong nag-aakalang kabaligtaran ay patuloy na mabibigo, at ang mga pagkabigong iyon ay magmumukhang walang kaugnayang bug ng aplikasyon.

Alamin kung ano ang nag-alis ng entry na Lumipat ng user, sa ganitong pagkakasunod-sunod

Ang mabilisang paglilipat ng user ay nawala sa ganap na ibang dahilan, at ang lunas ay walang kinalaman sa routing. Daanan ang apat na kandidato sa pagkakasunod-sunod, dahil ang unang dalawa ay maibabalik sa ilang segundo at ang mga huli ay may gastos.

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

Ang halaga sa registry ang pinakasimpleng paliwanag. Kung mayroon ito at nagbabasa ng 1, nakatago ang entry dahil sa patakaran, at ang landas ng Group Policy ay Computer Configuration, Administrative Templates, System, Logon, at ang setting na pinangalanan para itago ang mga entry point ng mabilisang paglilipat ng user. Itakda ito sa Not Configured at i-refresh gamit ang gpupdate /force.

Sinasabi ng ikalawang utos kung ang patakarang iyon ay ipinapadala mula sa isang domain sa halip na isinulat nang lokal. Kung lumilitaw ito sa ulat na may nanalong GPO, ang pag-edit ng lokal na halaga ay pansamantalang pag-aayos na bumabalik sa susunod na refresh, at ang usapan ay para sa may-ari ng patakaran.

Sinasaklaw ng ikatlong utos ang kabilang mekanismo. Ang provider ng kredensyal o access sa network na nag-i-install ng login module ay maaaring pigilan ang entry habang tumatakbo ito, at ang ilang client ay nagrerehistro rin ng component na nagsisimula bago ang login at nagpapanatili ng claim sa sign-in screen. Ang pag-disable sa serbisyong iyon ay nagbabalik ng paglilipat, at inaalis din ang mga function na bago ang login o posture na dahilan ng pag-iral ng module.

Baguhin ito nang hindi nakakandado sa labas

Panatilihing bukas ang isang administratibong session habang nagtatrabaho, at huwag kailanman gumawa ng pagbabago sa sign-in screen sa makinang maaabot mo lamang sa pamamagitan ng screen na iyon. I-sign out muna ang ibang session, ilapat ang pagbabago, i-refresh, at pagkatapos ay subukan sa pamamagitan ng paglilipat ng user at hindi sa pamamagitan ng pag-restart.

Itala kung aling mga function ng posture ang na-disable mo. Maaaring i-install muli o i-enable muli ng update ng client ang login module, at bumabalik ang sintomas nang walang malinaw na dahilan, kadalasan sa gitna ng isang window ng suporta kapag walang nakakaalala sa naunang pagbabago.

Sa isang pinamamahalaang device, ipagpalagay na ang setting ay ipinapadala mula sa itaas. Ang pagsuri sa ulat ng patakaran muna ay nakakatipid ng isang oras ng lokal na pag-edit na bumabalik. Sinasabi rin nito kung sino ang tatanungin kapag ang sagot ay hindi. Ang isang ticket na nagpangalan sa nanalong patakaran ay nalulutas nang doble kabilis kaysa sa isang naglalarawan ng registry key na may ibang nagbago na.

I-verify ang dalawang account at piliin ang modelo

Subukan ang resulta sa pagkakasunod-sunod na nararanasan ng dalawang user. Mag-sign in gamit ang pangalawang account habang nakadiskonekta ang una, kumpirmahin ang normal na access, pagkatapos ikonekta ang tunnel ng unang account at kumpirmahin na ang inaasahang landas ng pangalawang account ay siya pa rin ang nilalayon mo.

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

Kung talagang kailangan ng dalawang account ang magkaibang landas ng network nang sabay, ang tapat na sagot ay dalawang makina, dalawang virtual machine, o isang patakarang isang landas lang ang kailangan. Ang split tunnel sa shared na koneksyon ay makapagpapaliit ng dumadaan, ngunit hindi nito mabibigyan ang bawat session ng sarili nitong table. Ang makarating doon nang maaga ay mas mura kaysa matuklasan ito pagkatapos ng tatlong pagtatangkang lumihis.

Iyon ang desisyong dapat gawin nang malinaw sa halip na tapalan sa paligid. Isang routing table, isang listahan ng resolver, isang firewall profile: ang lahat ng iba ay sumusunod mula doon, at ang pag-aayos na gumagalang dito ay gagana pa rin sa susunod na buwan.