Unha VPN, dúas contas de Windows: por que rompe a outra sesión
As rutas e os resolutores son de toda a máquina, así que o túnel dunha conta redirixe as demais. Despois descubra que política ou módulo de inicio de sesión quitou a entrada de cambio de usuario.
Dúas persoas iniciaron sesión, unha delas conecta o túnel corporativo e o navegador da outra conta deixa de cargar páxinas que hai un minuto ían ben. Na mesma máquina, a entrada de cambio de usuario tamén desapareceu da pantalla de inicio de sesión, así que a segunda persoa non pode volver á súa propia sesión. Seguilo desde a segunda sesión cara a fóra é a forma máis rápida de entendelo, porque nada da conexión do primeiro usuario está oculto e nada do problema do segundo usuario é misterioso unha vez que ve que obxectos se comparten.
Comece pola sesión que rompeu
Vaia ao escritorio da segunda conta, non ao da primeira. Abra alí un terminal e mire a táboa de encamiñamento e a lista de resolutores mentres a outra sesión está conectada. Todo o que ve pertence á máquina, non ao outro usuario, e esa é a primeira pista.
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
Se a ruta predeterminada agora apunta á interface do túnel, o tráfico do segundo usuario tamén a segue. Se a lista de resolutores gañou un servidor privado, as súas consultas agora van a un lugar ao que non poderán chegar cando caia o túnel. Ningunha das dúas cousas é un erro do cliente; son as consecuencias dunha única pila de rede compartida.
O terceiro comando explica unha segunda clase de queixas. Cando un adaptador cambia a máquina dunha categoría de rede pública a privada, as regras da devasa vinculadas a un perfil cambian para todas as contas á vez, así que aplicacións que estaban permitidas pola mañá poden quedar bloqueadas pola tarde sen que ninguén toque unha regra.
A conexión é por usuario, a rede non
Windows garda o obxecto de conexión no perfil do usuario que a creou. O adaptador virtual que produce, as rutas que instala e os servidores DNS que rexistra son de ámbito de máquina. Esa división é a orixe dos dous síntomas do título.
Tamén explica por que pechar a sesión do primeiro usuario adoita arranxar a do segundo. Quitar a conexión quita o adaptador e as rutas con ela, e o estado de toda a máquina volve ao que había antes de que ninguén se conectase. É un diagnóstico útil: se pechar a sesión repara a outra conta, está a mirar estado compartido e non un perfil roto.
O que non pode facer é dar á segunda sesión unha táboa de encamiñamento distinta. Hai unha soa táboa e dúas sesións calquera compártena. É unha propiedade do sistema operativo e non unha limitación dun cliente concreto. Tamén significa que calquera deseño que asuma o contrario seguirá fallando, e as fallas parecerán erros de aplicación sen relación.
Atope que quitou o cambio de usuario, nesta orde
O cambio rápido de usuario desapareceu por un motivo completamente distinto, e a solución non ten nada que ver co encamiñamento. Repase os catro candidatos en orde, porque os dous primeiros revírtense en segundos e os últimos teñen un custo.
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
O valor do rexistro é a explicación máis sinxela. Se existe e le 1, a entrada está oculta por política, e a ruta da directiva de grupo é Configuración do equipo, Modelos administrativos, Sistema, Inicio de sesión e a configuración nomeada por ocultar os puntos de entrada do cambio rápido de usuario. Póña en Non configurado e actualice con gpupdate /force.
O segundo comando dille se esa política se entrega desde un dominio en lugar de escribirse localmente. Se aparece no informe cun GPO gañador, editar o valor local é unha solución temporal que se revirte na próxima actualización, e a conversación é con quen posúe a política.
O terceiro comando cobre o outro mecanismo. Un provedor de credenciais ou de acceso á rede que instala un módulo de inicio de sesión pode suprimir a entrada mentres se executa, e algúns clientes tamén rexistran un compoñente que arrinca antes do inicio de sesión e mantén unha reclamación na pantalla de inicio. Desactivar ese servizo restaura o cambio, e tamén elimina as funcións previas ao inicio de sesión ou de postura que o módulo existe para ofrecer.
| Cause | How to confirm | Cost of the fix |
|---|---|---|
| HideFastUserSwitching policy | Registry value present and set to 1 | None; remove the policy |
| Logon module service | Service running under a vendor name | Loses pre-logon and posture behaviour |
| GINA-era assumption | Only relevant on very old Windows | Nothing to fix; the mechanism is gone |
Cámbieo sen quedar fóra
Manteña unha sesión administrativa aberta mentres traballa, e nunca faga un cambio na pantalla de inicio de sesión nunha máquina á que só pode chegar a través desa pantalla. Peche primeiro as outras sesións, aplique o cambio, actualice e despois probe cambiando de usuario en lugar de reiniciando.
Anote que funcións de postura desactivou. Unha actualización do cliente pode reinstalar ou reactivar o módulo de inicio de sesión, e o síntoma volve sen causa obvia, normalmente no medio dunha xanela de soporte cando ninguén recorda o cambio anterior.
Nun dispositivo xestionado, supoña que a configuración se entrega desde arriba. Comprobar primeiro o informe de políticas aforra unha hora de edicións locais que se revirten. Tamén lle di a quen preguntar cando a resposta é non. Unha incidencia que nomea a política gañadora resólvese o dobre de rápido que unha que describe unha clave de rexistro que alguén xa cambiou.
Verifique ambas as contas e escolla o modelo
Probe o resultado na orde en que o viven os dous usuarios. Inicie sesión como a segunda conta coa primeira desconectada, confirme o acceso normal, despois conecte o túnel da primeira conta e confirme que a ruta esperada da segunda conta segue sendo a que pretendía.
qwinsta
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Select-Object InterfaceAlias,NextHop,RouteMetric
Test-NetConnection -ComputerName intranet.example.internal -Port 443
Se as dúas contas necesitan de verdade rutas de rede distintas ao mesmo tempo, a resposta honesta son dúas máquinas, dúas máquinas virtuais ou unha política na que só se require unha ruta. Un túnel dividido sobre a conexión compartida pode reducir o que se move, pero non pode dar a cada sesión a súa propia táboa. Chegar a iso pronto é máis barato que descubrilo tras tres intentos de solución alternativa.
Esa é a decisión que hai que tomar explicitamente en lugar de parchear ao redor. Unha táboa de encamiñamento, unha lista de resolutores, un perfil de devasa: todo o demais derívase diso, e a solución que o respecte seguirá funcionando o mes que vén.