L’icona di internet è sbagliata ma la VPN funziona? Tre verifiche

L’area di notifica mostra che non c’è internet, l’applicazione privata continua a funzionare e qualcuno vuole cambiare il profilo VPN finché l’icona non si comporta correttamente. Tre osservazioni diverse vengono fuse in una sola, e solo una di esse riguarda il tunnel. Separarle evita che un problema di icona diventi un cambio di profilo inutile.

Prima nominate l’osservazione, poi decidete se qualcosa va davvero riparato.

Tre osservazioni, tre domande

L’indicatore di connettività di Windows risponde a ciò che il processo di rilevamento del sistema ha stabilito per il profilo di rete attuale. Lo stato del client VPN risponde se quel client segnala una sessione peer stabilita. Una nuova operazione dell’applicazione risponde se una specifica richiesta ha funzionato lungo il percorso seguito. Ciascuna è un risultato legittimo e nessuna sostituisce le altre. Fonderle produce una riparazione rivolta allo strato sbagliato.

La confusione classica è trattare la prima come un riassunto delle altre due. Una macchina può avere un tunnel sano con risorse private funzionanti ed essere comunque classificata come senza internet, perché la classificazione viene da una sonda che non ha mai raggiunto il suo servizio.

Get-NetConnectionProfile
Get-DnsClientServerAddress -AddressFamily IPv4
Test-NetConnection -ComputerName internal.example -Port 443

Annotate i tre risultati con una marca temporale prima di toccare qualsiasi cosa. La maggior parte di queste segnalazioni si risolve in quel passaggio, perché il disaccordo diventa evidente appena viene scritto.

Che cosa fa realmente il processo di classificazione

La panoramica NCSI di Microsoft descrive il sondaggio attivo con richieste HTTP verso un servizio di sonda configurato, combinato con l’osservazione passiva del traffico di rete. La mancata risposta attesa può venire dall’instradamento, da un proxy o da un’altra condizione ambientale su quel percorso. È più specifico di un test di raggiungibilità generale e più stretto di quanto si supponga. Proprio questa strettezza è l’intera ragione per cui compare il disaccordo.

Ciò che non verifica mai è la cifratura, la riservatezza del resolver o se un’applicazione è autorizzata. Una classificazione positiva non dimostra che ogni applicazione usi il tunnel, e una negativa non dimostra che il tunnel sia giù.

La confusione inversa è altrettanto frequente. Un tunnel può essere stabilito mentre l’applicazione per cui è stato costruito non ha alcuna rotta utilizzabile, alcun resolver funzionante e alcun permesso. L’indicatore del client segnala un risultato più vecchio e più stretto di quello che serve.

Il disaccordo stesso dice cosa correggere

L’accesso privato funziona e il sistema dice che non c’è internet: il componente che fallisce è il percorso della sonda, non il tunnel. Annotate l’interfaccia e l’ora, poi chiedete al responsabile della rete di guardare come la sonda raggiunge il suo servizio e se una politica la blocca. Sostituire un profilo di accesso privato funzionante con una rotta internet ampia cambia un’icona e allarga un accesso che non avevate chiesto di allargare.

Il tunnel segnala connessione e le nuove richieste ai servizi necessari falliscono: è un guasto reale, e definire l’icona un falso allarme lo salta. Confrontate l’errore dell’applicazione, l’ambito previsto del profilo, il resolver in uso e le rotte selezionate. Un tunnel solo privato non è progettato per fornire un’uscita internet pubblica, e aspettarsene una è un errore di ambito e non un difetto.

Conservate la traccia, cambiate un solo percorso

Usate una nuova operazione nell’applicazione pertinente invece di una pagina aperta da stamattina. Mantenete attivo il blocco necessario e fate ogni confronto diretto consentito tramite i controlli documentati del client, non modificando le rotte a mano.

Se un proxy o un firewall gestito blocca la sonda prevista, correggete quel percorso specifico con il suo responsabile. Le indicazioni di Microsoft sconsigliano di disattivare il sondaggio attivo come soluzione, e un’eccezione di indirizzo codificata o una modifica al registro non spiegano quale componente risponde male.

Dopo la modifica, conservate tutti e tre i risultati nel ticket: classificazione, stato della sessione ed esito applicativo. Se si è mossa solo l’icona, avete imparato che un indicatore è cambiato, non che il database o il sito funzionano adesso.