Guide

Kill switch e fughe: DNS, WebRTC, IPv6

Un kill switch blocca tutto il traffico internet nell'istante in cui il tunnel VPN cade, così le app non possono ripiegare in silenzio sulla tua connessione normale. Senza, anche una disconnessione di due secondi espone il tuo vero indirizzo IP. E anche con il tunnel attivo, le richieste DNS, il WebRTC nel browser e il traffico IPv6 possono passargli accanto. Ogni fuga ha un test semplice e un rimedio.

🛡️

Un tunnel caduto fallisce aperto

Quando una connessione VPN si rompe, il sistema operativo instrada tranquillamente il traffico dall'interfaccia normale. Le app continuano a funzionare e nulla ti avvisa. Un kill switch trasforma il fail-open in fail-closed: niente tunnel, niente traffico.

🌍

Le fughe avvengono a tunnel attivo

Le richieste DNS possono andare al resolver del tuo operatore fuori dal tunnel, il WebRTC può consegnare ai siti i tuoi indirizzi, e l'IPv6 può aggirare un tunnel solo-IPv4 — tutto mentre l'icona della VPN dice «connesso».

🔑

Ogni fuga è testabile

Non devi fidarti delle schermate delle impostazioni. Un leak test mostra quali indirizzi e resolver i siti vedono davvero, e rompere il tunnel apposta mostra se il kill switch regge.

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

Domande frequenti

Mi serve un kill switch se la mia connessione è stabile?
Sì — le cadute che contano sono quelle che non prevedi: svegliare un portatile, passare tra Wi-Fi e dati mobili, un riavvio lato server. La stabilità riduce quante volte il tunnel si rompe, non ciò che succede quando si rompe. Lo switch non costa nulla mentre il tunnel è attivo e agisce solo sul guasto.
Perché un leak test mostra l'IP della VPN ma i server DNS del mio operatore?
È una fuga DNS classica: il traffico passa dal tunnel, ma le risoluzioni dei nomi vanno ancora al resolver assegnato dalla rete locale. O il client non è riuscito a sovrascrivere il resolver di sistema, o il sistema interroga più interfacce in parallelo. Attiva la protezione DNS del client, riconnettiti e ripeti il test.
Il WebRTC può far trapelare il mio indirizzo anche a VPN connessa?
Con un tunnel su tutto il dispositivo, in genere no — il traffico di scoperta del WebRTC viaggia dentro il tunnel e trova l'indirizzo della VPN. Le fughe compaiono nelle configurazioni parziali: proxy nel browser, estensioni o split tunneling che lascia il browser fuori. Un test WebRTC chiude la questione in pochi secondi.
Non conviene disattivare l'IPv6 del tutto?
Come rimedio spiccio funziona, e sulle reti dove la tua VPN non sa gestire l'IPv6 è la scelta pragmatica — praticamente ogni servizio è ancora raggiungibile via IPv4. La risposta più pulita è una VPN che incanala o blocca l'IPv6 da sola, mantenendo la protezione senza ritocchi su ogni dispositivo.
Il kill switch mi taglierà internet quando mi disconnetto apposta?
Un client fatto bene rimuove le sue regole di blocco quando premi disconnetti, quindi il traffico normale riprende subito; il blocco è pensato per le cadute inattese. Alcuni client offrono anche una modalità più severa in cui nessun traffico scorre se il tunnel non è attivo, utile su un dispositivo che non deve mai aggirarlo.
Ogni quanto dovrei ripetere i test per le fughe?
Testa dopo qualsiasi cosa tocchi la rete: un aggiornamento del sistema, un aggiornamento dell'app VPN, un browser nuovo, una rete sconosciuta, impostazioni del router cambiate. Ognuna può azzerare il comportamento DNS o riattivare l'IPv6. Un giro completo richiede cinque minuti, quindi testa su ogni rete nuova e dopo gli aggiornamenti, più che a calendario.

Continua a leggere

Prova Aurora

Garanzia di rimborso di 14 giorni. Fino a 7 dispositivi con un solo abbonamento.

Proteggi i miei dispositivi