Dos personas han iniciado sesión, una de ellas conecta el túnel corporativo y el navegador de la otra cuenta deja de cargar páginas que hace un minuto iban bien. En la misma máquina, la entrada de cambio de usuario también ha desaparecido de la pantalla de inicio de sesión, así que la segunda persona no puede volver a su propia sesión. Seguirlo desde la segunda sesión hacia fuera es la forma más rápida de entenderlo, porque nada de la conexión del primer usuario está oculto y nada del problema del segundo usuario es misterioso una vez que ve qué objetos se comparten.

Empiece por la sesión que se rompió

Vaya al escritorio de la segunda cuenta, no al de la primera. Abra allí un terminal y mire la tabla de enrutamiento y la lista de resolutores mientras la otra sesión está conectada. Todo lo que ve pertenece a la máquina, no al otro usuario, y esa es la primera 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

Si la ruta predeterminada ahora apunta a la interfaz del túnel, el tráfico del segundo usuario también la sigue. Si la lista de resolutores ha ganado un servidor privado, sus consultas ahora van a un lugar al que no podrán llegar cuando caiga el túnel. Ninguna de las dos cosas es un error del cliente; son las consecuencias de una única pila de red compartida.

El tercer comando explica una segunda clase de quejas. Cuando un adaptador cambia la máquina de una categoría de red pública a privada, las reglas de firewall vinculadas a un perfil cambian para todas las cuentas a la vez, así que aplicaciones que estaban permitidas por la mañana pueden quedar bloqueadas por la tarde sin que nadie toque una regla.

La conexión es por usuario, la red no

Windows guarda el objeto de conexión en el perfil del usuario que lo creó. El adaptador virtual que produce, las rutas que instala y los servidores DNS que registra son de ámbito de máquina. Esa división es el origen de los dos síntomas del título.

También explica por qué cerrar la sesión del primer usuario suele arreglar la del segundo. Quitar la conexión quita el adaptador y las rutas con ella, y el estado de toda la máquina vuelve al que había antes de que nadie se conectara. Es un diagnóstico útil: si cerrar la sesión repara la otra cuenta, está mirando estado compartido y no un perfil roto.

Lo que no puede hacer es dar a la segunda sesión una tabla de enrutamiento distinta. Hay una sola tabla y dos sesiones cualesquiera la comparten. Es una propiedad del sistema operativo y no una limitación de un cliente concreto. También significa que cualquier diseño que asuma lo contrario seguirá fallando, y los fallos parecerán errores de aplicación sin relación.

Encuentre qué quitó el cambio de usuario, en este orden

El cambio rápido de usuario ha desaparecido por un motivo completamente distinto, y la solución no tiene nada que ver con el enrutamiento. Recorra los cuatro candidatos en orden, porque los dos primeros se revierten en segundos y los últimos tienen un coste.

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

El valor del registro es la explicación más sencilla. Si existe y lee 1, la entrada está oculta por directiva, y la ruta de la directiva de grupo es Configuración del equipo, Plantillas administrativas, Sistema, Inicio de sesión y la opción nombrada por ocultar los puntos de entrada del cambio rápido de usuario. Póngala en No configurado y actualice con gpupdate /force.

El segundo comando le dice si esa directiva se entrega desde un dominio en lugar de escribirse localmente. Si aparece en el informe con un GPO ganador, editar el valor local es una solución temporal que se revierte en la próxima actualización, y la conversación es con quien posee la directiva.

El tercer comando cubre el otro mecanismo. Un proveedor de credenciales o de acceso a la red que instala un módulo de inicio de sesión puede suprimir la entrada mientras se ejecuta, y algunos clientes también registran un componente que arranca antes del inicio de sesión y mantiene una reclamación en la pantalla de inicio. Desactivar ese servicio restaura el cambio, y también elimina las funciones previas al inicio de sesión o de postura que el módulo existe para ofrecer.

CauseHow to confirmCost of the fix
HideFastUserSwitching policyRegistry value present and set to 1None; remove the policy
Logon module serviceService running under a vendor nameLoses pre-logon and posture behaviour
GINA-era assumptionOnly relevant on very old WindowsNothing to fix; the mechanism is gone

Cámbielo sin quedarse fuera

Mantenga una sesión administrativa abierta mientras trabaja, y nunca haga un cambio en la pantalla de inicio de sesión en una máquina a la que solo puede llegar a través de esa pantalla. Cierre primero las otras sesiones, aplique el cambio, actualice y luego pruebe cambiando de usuario en lugar de reiniciando.

Anote qué funciones de postura desactivó. Una actualización del cliente puede reinstalar o reactivar el módulo de inicio de sesión, y el síntoma vuelve sin causa obvia, normalmente en medio de una ventana de soporte cuando nadie recuerda el cambio anterior.

En un dispositivo gestionado, suponga que la configuración se entrega desde arriba. Comprobar primero el informe de directivas ahorra una hora de ediciones locales que se revierten. También le dice a quién preguntar cuando la respuesta es no. Un ticket que nombra la directiva ganadora se resuelve el doble de rápido que uno que describe una clave de registro que alguien ya cambió.

Verifique ambas cuentas y elija el modelo

Pruebe el resultado en el orden en que lo viven los dos usuarios. Inicie sesión como la segunda cuenta con la primera desconectada, confirme el acceso normal, luego conecte el túnel de la primera cuenta y confirme que la ruta esperada de la segunda cuenta sigue siendo la 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

Si las dos cuentas necesitan de verdad rutas de red distintas al mismo tiempo, la respuesta honesta son dos máquinas, dos máquinas virtuales o una directiva en la que solo se requiere una ruta. Un túnel dividido sobre la conexión compartida puede reducir lo que se mueve, pero no puede dar a cada sesión su propia tabla. Llegar a eso pronto es más barato que descubrirlo tras tres intentos de solución alternativa.

Esa es la decisión que hay que tomar explícitamente en lugar de parchear alrededor. Una tabla de enrutamiento, una lista de resolutores, un perfil de firewall: todo lo demás se deriva de eso, y la solución que lo respete seguirá funcionando el mes que viene.

Artículos relacionados