Internet funziona solo con l'app VPN attiva? Controlla quattro livelli

Provi un client VPN gratuito o un'estensione del browser per una settimana, lo spegni e internet si ferma. L'icona Wi-Fi mostra ancora una connessione, gli altri dispositivi sullo stesso router funzionano, e le uniche cose che riportano la navigazione sono riattivare l'app o disinstallarla. Questo schema non è una crittografia che crea dipendenza. È configurazione che l'app ha scritto in un punto che il tunnel non possiede.

Il client modifica impostazioni che il tunnel non possiede

Un client per la privacy su Windows o macOS di solito tocca tre punti insieme. Imposta il proxy HTTP di sistema, lo stesso campo che espone Internet Options. Installa un adattatore virtuale, spesso un driver TAP, per poter catturare i pacchetti. E riscrive l'elenco dei resolver, mentre alla disconnessione scompare solo il tunnel.

Un'estensione del browser è una cosa più ristretta. Di solito cambia il proprio profilo o il proxy che un browser segue. Per questo un solo browser può fallire mentre gli strumenti da riga di comando continuano a funzionare, o il contrario: l'estensione non ha mai avuto l'autorità di toccare gli altri livelli. Il livello che ha modificato decide quali strumenti si rompono.

In ogni caso, quella decisione rimasta indietro l'ha presa un software che non aveva motivo di annullarla. Il tunnel era la parte visibile, e anche l'unica parte con un percorso di chiusura pulito. Tutto il resto è un'impostazione in un archivio che sopravvive al processo, quindi rimuovere l'app è l'unico passo che inverte tutti e tre insieme. Leggere quegli archivi prima di reinstallare è ciò che trasforma il sintomo in diagnosi.

Tre residui, tre guasti diversi

Il primo residuo è un proxy che non punta a nulla: la casella del proxy LAN ancora spuntata, o l'URL di uno script di configurazione diretto a una porta localhost dove nessun processo è più in ascolto. Il browser inoltra ogni richiesta a quella porta morta e si blocca finché il timeout non sembra una rete morta. Il secondo è un adattatore che possiede ancora una rotta predefinita, perché un dispositivo TAP-Windows o un driver di routing del fornitore resta un'interfaccia reale dopo la disinstallazione. Conserva la rotta che gli è stata data, e il traffico sparisce in un tunnel che non c'è. Nessuno dei due residui si annuncia; entrambi sembrano esattamente un'interruzione.

Il terzo è il DNS, e fallisce prima degli altri due. Se l'elenco dei resolver contiene solo server raggiungibili attraverso il tunnel, ogni risoluzione va in timeout prima che venga richiesta una sola pagina, quindi il browser segnala un sito irraggiungibile anziché un proxy morto. Qualunque sia il vostro caso, nessuno di questi è un guasto in senso di rete. Ognuno è un residuo che nessuno ha revocato, e ognuno si ripara in un punto diverso.

Scendi i quattro livelli

Parti dal più vicino all'applicazione e scendi, perché i livelli falliscono in quest'ordine di visibilità. Cambia un livello per prova, e ripeti il test dopo ciascuno. Reimpostare tutto insieme di solito riporta la navigazione, e ti lascia incapace di dire quale residuo l'ha causata, così l'installazione successiva ricrea lo stesso rompicapo. L'ordine è proxy, adattatori, rotte, resolver.

Su Windows ogni controllo è un singolo comando fornito con il sistema operativo, quindi non serve installare nulla. Eseguili in ordine e tieni l'output insieme, perché le quattro risposte hanno senso solo una accanto all'altra. Riportano il proxy, gli adattatori, le rotte IPv4 e l'elenco dei resolver, in quest'ordine:

netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress

Linux e macOS richiedono i propri comandi, e non sono intercambiabili. Su Linux le rotte vengono da ip route e il resolver da resolvectl status dove lo gestisce systemd-resolved, con ricaduta su cat /etc/resolv.conf. Su macOS le rotte vengono da netstat -rn, i resolver da scutil --dns e il proxy di sistema da scutil --proxy. Un lettore macOS che esegue ip route riceve command not found, e /etc/resolv.conf lì è uno stub generato, non la configurazione autorevole. Controlla la piattaforma prima del livello, altrimenti il primo comando diventa il reperto.

Per ogni livello fai una domanda: questo valore punta ancora a qualcosa che esiste mentre l'app è chiusa? Un proxy su una porta morta, un adattatore senza tunnel, una rotta predefinita attraverso un'interfaccia spenta e un resolver dentro il tunnel rispondono tutti no. Un solo no basta a spiegare il sintomo, ed è per questo che conta una modifica per prova.

Un proxy non è un tunnel

Un proxy accetta una richiesta, la recupera altrove e restituisce la risposta, il che significa che conosce la destinazione e vede tutto ciò che il sito non ha cifrato da sé. Non trasporta altri protocolli. Non protegge il percorso a meno che la destinazione non usi già TLS. E può essere cambiato da qualunque cosa lo abbia installato, senza il tuo intervento.

Questa distinzione cambia la domanda che vale la pena porre. Quando resta un proxy, scopri quale programma guida ancora il tuo browser invece di chiederti se il tunnel è attivo. Il tunnel può essere perfettamente sano e del tutto irrilevante per il guasto.

Se vuoi sapere che cosa ha fatto davvero un client simile, osservalo invece di leggere la sua dashboard. Process Monitor registra quali chiavi di registro e file tocca, mentre una cattura di pacchetti rivela dove è finito il suo traffico. Sono entrambi strumenti comuni, ed entrambi rispondono alla domanda sul residuo meglio di qualsiasi spia di stato. Nessuno dei due richiede che l'app sia ancora in esecuzione.

Rimuovi il componente, non la prova

La correzione duratura è rimuovere la cosa che ha scritto l'impostazione. Disinstalla l'app, cancella l'adattatore virtuale che ha aggiunto, pulisci il proxy e l'elenco dei resolver, poi riavvia e prova con l'app ancora disinstallata. Se a quel punto la navigazione funziona, hai trovato la causa e non un espediente. Annota quale livello era obsoleto, perché lo stesso fornitore tende a spedire lo stesso errore due volte.

Se il sintomo torna dopo che installi il client successivo, ripercorri i quattro livelli prima di decidere che il servizio ha rotto qualcosa. Le prove di solito sono ancora lì, in uno dei quattro punti. Una seconda app non crea un quinto livello; ne modifica uno dei quattro.

Reinstallare azzera il proxy ma non un adattatore obsoleto, e può lasciare due resolver nell'elenco. È per questa asimmetria che disinstalla-e-prova batte un pulsante che reimposta tutto. Ti dà anche una base di confronto la prossima volta che la connessione cade.