Una VPN, dos comptes de Windows: per què es trenca l'altra sessió
Les rutes i els resolutors són de tota la màquina, així que el túnel d'un compte redirigeix els altres. Després esbrineu quina política o mòdul d'inici de sessió va treure l'entrada de canvi d'usuari.
Dues persones han iniciat sessió, una d'elles connecta el túnel corporatiu i el navegador de l'altre compte deixa de carregar pàgines que fa un minut anaven bé. A la mateixa màquina, l'entrada de canvi d'usuari també ha desaparegut de la pantalla d'inici de sessió, de manera que la segona persona no pot tornar a la seva pròpia sessió. Seguir-ho des de la segona sessió cap enfora és la manera més ràpida d'entendre-ho, perquè no hi ha res d'amagat a la connexió del primer usuari ni res de misteriós en el problema del segon un cop veieu quins objectes són compartits.
Comenceu per la sessió que s'ha trencat
Aneu a l'escriptori del segon compte, no al primer. Obriu-hi un terminal i mireu la taula d'encaminament i la llista de resolutors mentre l'altra sessió està connectada. Tot el que veieu pertany a la màquina, no a l'altre usuari, i aquesta és 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,IPv4ConnectivitySi la ruta per defecte ara apunta a la interfície del túnel, el trànsit del segon usuari també la segueix. Si la llista de resolutors ha guanyat un servidor privat, les seves consultes ara van a un lloc on no podran arribar quan caigui el túnel. Cap de les dues coses és un error del client; són les conseqüències d'una única pila de xarxa compartida.
La tercera ordre explica una segona classe de queixes. Quan un adaptador canvia la màquina d'una categoria de xarxa pública a privada, les regles del tallafoc vinculades a un perfil canvien per a tots els comptes alhora, de manera que aplicacions permeses al matí poden quedar bloquejades a la tarda sense que ningú toqui cap regla.
La connexió és per usuari, la xarxa no
Windows guarda l'objecte de connexió al perfil de l'usuari que l'ha creat. L'adaptador virtual que produeix, les rutes que instal·la i els servidors DNS que registra són d'abast de màquina. Aquesta divisió és l'origen dels dos símptomes del títol.
També explica per què tancar la sessió del primer usuari normalment arregla el segon. Treure la connexió treu l'adaptador i les rutes amb ella, i l'estat de tota la màquina torna al que era abans que ningú es connectés. És un diagnòstic útil: si tancar la sessió repara l'altre compte, esteu mirant estat compartit i no un perfil trencat.
El que no podeu fer és donar a la segona sessió una taula d'encaminament diferent. Hi ha una sola taula i dues sessions qualssevol la comparteixen. És una propietat del sistema operatiu i no una limitació d'un client concret. També vol dir que qualsevol disseny que assumeixi el contrari continuarà fallant, i les fallades semblaran errors d'aplicació sense relació.
Trobeu què ha tret el canvi d'usuari, en aquest ordre
El canvi ràpid d'usuari ha desaparegut per un motiu completament diferent, i la solució no té res a veure amb l'encaminament. Repasseu els quatre candidats per ordre, perquè els dos primers es poden revertir en segons i els últims tenen un cost.
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,DisplayNameEl valor del registre és l'explicació més senzilla. Si existeix i llegeix 1, l'entrada està oculta per política, i el camí de la directiva de grup és Configuració de l'equip, Plantilles administratives, Sistema, Inici de sessió i la configuració anomenada per amagar els punts d'entrada del canvi ràpid d'usuari. Poseu-la a No configurat i actualitzeu amb gpupdate /force.
La segona ordre us diu si aquesta política s'entrega des d'un domini en lloc d'escriure's localment. Si apareix a l'informe amb un GPO guanyador, editar el valor local és una solució temporal que es reverteix a la propera actualització, i la conversa és amb qui posseeix la política.
La tercera ordre cobreix l'altre mecanisme. Un proveïdor de credencials o d'accés a la xarxa que instal·la un mòdul d'inici de sessió pot suprimir l'entrada mentre s'executa, i alguns clients també registren un component que s'inicia abans de l'inici de sessió i manté una reclamació a la pantalla d'inici. Desactivar aquest servei restaura el canvi, i també elimina les funcions prèvies a l'inici de sessió o de postura que el mòdul existeix per oferir.
| 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 |
Canvieu-ho sense quedar-vos fora
Mantingueu una sessió administrativa oberta mentre treballeu, i no feu mai un canvi a la pantalla d'inici de sessió en una màquina a la qual només podeu arribar a través d'aquesta pantalla. Tanqueu primer les altres sessions, apliqueu el canvi, actualitzeu i després proveu canviant d'usuari en lloc de reiniciant.
Anoteu quines funcions de postura heu desactivat. Una actualització del client pot reinstal·lar o reactivar el mòdul d'inici de sessió, i el símptoma torna sense causa òbvia, normalment al mig d'una finestra de suport quan ningú recorda el canvi anterior.
En un dispositiu gestionat, suposeu que la configuració s'entrega des de dalt. Comprovar primer l'informe de polítiques estalvia una hora d'edicions locals que es reverteixen. També us diu a qui preguntar quan la resposta és no. Una incidència que anomena la política guanyadora es resol el doble de ràpid que una que descriu una clau de registre que algú ja ha canviat.
Verifiqueu tots dos comptes i trieu el model
Proveu el resultat en l'ordre en què el viuen els dos usuaris. Inicieu sessió com al segon compte amb el primer desconnectat, confirmeu l'accés normal, després connecteu el túnel del primer compte i confirmeu que el camí esperat del segon compte segueix sent el que volíeu.
qwinsta
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Select-Object InterfaceAlias,NextHop,RouteMetric
Test-NetConnection -ComputerName intranet.example.internal -Port 443Si els dos comptes necessiten de veritat camins de xarxa diferents alhora, la resposta honesta és dues màquines, dues màquines virtuals o una política en què només calgui un camí. Un túnel dividit sobre la connexió compartida pot reduir què es mou, però no pot donar a cada sessió la seva pròpia taula. Arribar-hi aviat és més barat que descobrir-ho després de tres intents de solució alternativa.
Aquesta és la decisió que cal prendre explícitament en lloc d'apedaçar al voltant. Una taula d'encaminament, una llista de resolutors, un perfil de tallafoc: tota la resta en deriva, i la solució que ho respecti encara funcionarà el mes que ve.