Cosa succede nell'istante in cui il tunnel cade
La connessione fallisce aperta. Una VPN aggiunge rotte che dirottano il traffico in un'interfaccia di rete virtuale. Quando il processo del tunnel muore o va in timeout, quelle rotte spariscono, mentre la rotta di default via Wi-Fi o Ethernet rimane — quindi il sistema continua a consegnare pacchetti, ora direttamente attraverso il tuo operatore. Le app riconnettono i loro socket in pochi secondi, mandando traffico dal tuo IP reale, senza alcuna finestra di errore da nessuna parte.
Le cadute sono routine. Passare dal Wi-Fi ai dati mobili, un portatile che si sveglia dallo standby, una rete d'albergo ballerina o un riavvio del server VPN rompono tutti il tunnel per un momento. Quanto costa quel momento dipende da cosa è autorizzato a lasciare il tuo dispositivo mentre il tunnel è giù.
Cosa fa davvero un kill switch
Un kill switch è un insieme di regole del firewall, non magia. La versione rigorosa ammette solo due tipi di traffico in uscita: i pacchetti che entrano nell'interfaccia del tunnel e i pacchetti cifrati del client VPN stesso verso il server. Se il tunnel va giù, il traffico delle applicazioni semplicemente non ha dove andare finché non torna.
Questo cambia la modalità di guasto, non previene i guasti. Con un kill switch, una caduta diventa una connessione in pausa che noti; senza, diventa traffico dal tuo indirizzo reale che non noti. Le reti sono imperfette e il tunnel continuerà a rompersi — il fail-closed rende quei momenti innocui.
Kill switch di sistema o dentro l'app
La differenza è cosa succede quando muore l'app stessa. Un kill switch in-app è codice dentro il client VPN che sorveglia il tunnel e blocca il traffico quando cade. Funziona solo mentre il client gira: se il client va in crash o viene ucciso da un ottimizzatore di batteria, la sua protezione muore con lui — esattamente nel momento in cui il tunnel sparisce.
Un kill switch a livello di sistema installa regole nel firewall del sistema operativo, che ispeziona ogni pacchetto in uscita a prescindere da quali app girino. Android ce l'ha integrato: VPN sempre attiva più il blocco delle connessioni senza VPN fanno sì che sia il sistema stesso a rifiutare il traffico fuori dal tunnel, perfino prima che l'app parta dopo un riavvio. Il modo spiccio per distinguere i due: forza la chiusura dell'app VPN mentre navighi — se le pagine si caricano ancora, lo switch vive nell'app.
Fughe DNS: richieste che saltano il tunnel
Una fuga DNS significa che le tue risoluzioni dei nomi vanno al resolver assegnato dalla rete locale — di solito quello del tuo operatore — anche se il traffico in sé viaggia nel tunnel. I siti vedono l'indirizzo della VPN, ma il resolver riceve il nome di ogni sito che apri, il che equivale a un registro della navigazione. Windows è il colpevole classico: con più interfacce attive può interrogarle tutte in parallelo e usare quella che risponde per prima.
Il rimedio ha due parti, e un buon client le fa entrambe: puntare il sistema al resolver dentro il tunnel e bloccare il DNS su ogni altra interfaccia, così una richiesta vagante non ha dove andare. Poi verifica: esegui un leak test e controlla i resolver elencati — se qualcuno appartiene al tuo operatore, le risoluzioni stanno fuggendo.
Fughe WebRTC: il browser regala gli indirizzi
WebRTC è la tecnologia del browser dietro le videochiamate, e qualsiasi sito può invocarla con poche righe di JavaScript. Per stabilire connessioni dirette raccoglie ogni indirizzo che potrebbe raggiungere la tua macchina: gli indirizzi locali e, chiedendo a un server STUN, quello pubblico. Una pagina può leggere quei candidati senza alcun tuo intervento.
Con un tunnel su tutto il dispositivo la richiesta STUN viaggia dentro il tunnel, quindi scopre l'indirizzo della VPN. Le configurazioni pericolose sono quelle parziali: un proxy solo per il browser o uno split tunneling che lascia il browser fuori — lì i pacchetti UDP del WebRTC escono diretti e rivelano il tuo IP reale.
Testalo invece di ragionarci sopra: il nostro verificatore gratuito su /webrtc-leak-test/ mostra quali indirizzi il tuo browser rivela in questo momento. Se compare quello reale, passa a un tunnel su tutto il dispositivo o disattiva il WebRTC nelle impostazioni del browser.
Fughe IPv6: il tunnel copre solo l'IPv4
Molte configurazioni VPN trasportano solo IPv4. Se il tuo operatore fornisce anche IPv6 — quasi tutte le reti mobili lo fanno — il sistema mantiene una rotta IPv6 funzionante fuori dal tunnel, e i sistemi moderni preferiscono l'IPv6 quando un sito offre entrambi. Il risultato è un'esposizione selettiva: i siti senza IPv6 vedono l'indirizzo della VPN, quelli con IPv6 vedono il tuo reale, e un test solo-IPv4 riferisce che va tutto bene.
Ci sono due rimedi puliti. Il migliore è una VPN che gestisce l'IPv6 come si deve — incanalandolo accanto all'IPv4 o installando una rotta di blocco così che i pacchetti IPv6 vengano scartati, non spediti direttamente. Il ripiego spiccio è disattivare l'IPv6 sul dispositivo o sul router. In ogni caso, verifica: il leak test non deve mostrare alcun indirizzo IPv6 che non sia della VPN.
Come testare la propria configurazione come si deve
Esegui i controlli nelle condizioni in cui ti trovi davvero — Wi-Fi di casa, telefono su dati mobili, la rete di un bar — perché le fughe dipendono dalla configurazione DNS e dalla disponibilità IPv6 di ciascuna rete. La routine richiede circa cinque minuti:
- Annota il tuo IP reale a VPN spenta, connettiti e verifica che gli indirizzi visibili IPv4 e IPv6 siano cambiati entrambi — il nostro /data-leak-checker/ mostra IP, resolver DNS e WebRTC in un solo passaggio
- Controlla l'elenco dei resolver: ogni server DNS mostrato deve appartenere alla VPN, nessuno al tuo operatore
- Rompi il tunnel apposta — spegni e riaccendi il Wi-Fi o forza la chiusura dell'app — e guarda se le pagine si caricano prima che si riconnetta
- Ripeti dopo gli aggiornamenti del sistema o dell'app VPN, perché entrambi possono azzerare in silenzio le impostazioni di rete