Una VPN, due account Windows: perché l'altra sessione si rompe

Due persone hanno effettuato l'accesso, una di loro collega il tunnel aziendale, e il browser dell'altro account smette di caricare pagine che un minuto prima andavano bene. Sulla stessa macchina anche la voce Cambia utente è sparita dalla schermata di accesso, così la seconda persona non può tornare alla propria sessione. Seguire questo dalla seconda sessione verso l'esterno è il modo più rapido per capirlo, perché nulla della connessione del primo utente è nascosto e nulla del problema del secondo utente è misterioso una volta che si vedono quali oggetti sono condivisi.

Iniziate dalla sessione che si è rotta

Andate sul desktop del secondo account, non del primo. Aprite lì un terminale e guardate la tabella di routing e l'elenco dei resolver mentre l'altra sessione è connessa. Tutto ciò che vedete appartiene alla macchina, non all'altro utente, e questo è il primo indizio.

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 la route predefinita ora punta all'interfaccia del tunnel, anche il traffico del secondo utente la segue. Se l'elenco dei resolver ha guadagnato un server privato, le loro ricerche ora vanno in un posto che non possono raggiungere quando il tunnel cade. Nessuna delle due è un difetto del client; sono le conseguenze di un unico stack di rete condiviso.

Il terzo comando spiega una seconda classe di lamentele. Quando un adattatore cambia la macchina da una categoria di rete pubblica a una privata, le regole del firewall limitate a un profilo cambiano per tutti gli account insieme, quindi applicazioni permesse al mattino possono essere bloccate al pomeriggio senza che nessuno tocchi una regola.

La connessione è per utente, la rete non lo è

Windows conserva l'oggetto di connessione nel profilo dell'utente che l'ha creato. L'adattatore virtuale che produce, le route che installa e i server DNS che registra sono a livello di macchina. Questa separazione è l'origine dei due sintomi del titolo.

Spiega anche perché chiudere la sessione del primo utente di solito sistema il secondo. Rimuovere la connessione rimuove l'adattatore e le route con essa, e lo stato dell'intera macchina torna a com'era prima che qualcuno si collegasse. È una diagnosi utile: se la chiusura della sessione ripara l'altro account, state guardando uno stato condiviso e non un profilo rotto.

Quello che non potete fare è dare alla seconda sessione una tabella di routing diversa. C'è una sola tabella, e due sessioni qualsiasi la condividono. È una proprietà del sistema operativo, non un limite di un client particolare. Significa anche che qualsiasi progettazione che presupponga il contrario continuerà a fallire, e i guasti sembreranno difetti applicativi non correlati.

Trovate cosa ha rimosso Cambia utente, in questo ordine

Il cambio rapido di utente è sparito per un motivo completamente diverso, e la correzione non ha nulla a che fare con il routing. Passate in rassegna i quattro candidati in ordine, perché i primi due si annullano in pochi secondi e i successivi hanno un costo.

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

Il valore del registro è la spiegazione più semplice. Se esiste e legge 1, la voce è nascosta da un criterio, e il percorso dei criteri di gruppo è Configurazione computer, Modelli amministrativi, Sistema, Accesso, e l'impostazione chiamata come l'occultamento dei punti di ingresso del cambio rapido di utente. Impostatela su Non configurato e aggiornate con gpupdate /force.

Il secondo comando vi dice se quel criterio viene fornito da un dominio invece di essere scritto localmente. Se compare nel report con un GPO vincente, modificare il valore locale è una correzione temporanea che torna al prossimo aggiornamento, e la conversazione è con chi possiede il criterio.

Il terzo comando copre l'altro meccanismo. Un provider di credenziali o di accesso alla rete che installa un modulo di accesso può sopprimere la voce mentre è in esecuzione, e alcuni client registrano anche un componente che si avvia prima dell'accesso e mantiene un'attestazione sulla schermata di accesso. Disattivare quel servizio ripristina il cambio, e rimuove anche le funzioni di pre-accesso o di postura per cui il modulo esiste.

Modificatelo senza chiudervi fuori

Tenete aperta una sessione amministrativa mentre lavorate, e non fate mai una modifica alla schermata di accesso su una macchina a cui potete arrivare solo attraverso quella schermata. Chiudete prima le altre sessioni, applicate la modifica, aggiornate, poi provate cambiando utente invece di riavviare.

Annotate quali funzioni di postura avete disattivato. Un aggiornamento del client può reinstallare o riattivare il modulo di accesso, e il sintomo torna senza causa evidente, di solito nel mezzo di una finestra di supporto quando nessuno ricorda la modifica precedente.

Su un dispositivo gestito, presupponete che l'impostazione venga fornita dall'alto. Controllare prima il report dei criteri risparmia un'ora di modifiche locali che tornano. Vi dice anche a chi chiedere quando la risposta è no. Un ticket che nomina il criterio vincente si risolve il doppio più in fretta di uno che descrive una chiave di registro che qualcuno ha già cambiato.

Verificate entrambi gli account e scegliete il modello

Provate il risultato nell'ordine in cui lo vivono i due utenti. Accedete come secondo account con il primo disconnesso, confermate l'accesso normale, poi collegate il tunnel del primo account e confermate che il percorso atteso del secondo account è ancora quello che intendevate.

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

Se i due account hanno davvero bisogno di percorsi di rete diversi nello stesso momento, la risposta onesta sono due macchine, due macchine virtuali o un criterio in cui è richiesto un solo percorso. Un tunnel diviso sulla connessione condivisa può restringere ciò che si muove, ma non può dare a ogni sessione la propria tabella. Arrivarci presto costa meno che scoprirlo dopo tre tentativi di aggiramento.

Questa è la decisione da prendere esplicitamente invece di rattoppare intorno. Una tabella di routing, un elenco di resolver, un profilo firewall: tutto il resto ne deriva, e la correzione che lo rispetta funzionerà ancora il mese prossimo.