In breve: una connessione VPN non è uno stato permanente — è una sessione di rete che può cadere. Roaming Wi-Fi, handoff tra celle mobili, riavvii del server, picchi di perdita di pacchetti, sospensioni delle app e cicli di sospensione del sistema operativo interrompono regolarmente il tunnel. Quando il tunnel cade, la regola di routing predefinita del sistema operativo dice "se non c'è una route specifica, usa l'interfaccia fisica" — il che significa che il traffico ricade sulla connessione reale, rivelando il tuo vero IP a qualunque destinatario. Un kill switch è il meccanismo che dice "no, smetti semplicemente di inviare traffico finché il tunnel non è di nuovo attivo." Concettualmente semplice. Nell'implementazione, il termine è stato usato per indicare almeno tre cose piuttosto diverse, con modalità di guasto molto diverse tra loro.
Perché esistono i kill switch — il problema del fallback silenzioso
Considera cosa succede senza un kill switch. Sei in un bar con la VPN connessa. Stai leggendo le email tramite un client webmail. Il Wi-Fi ha una breve interruzione — forse due secondi. Il client VPN tenta di riconnettersi, ma la rete sottostante è assente e la riconnessione fallisce. Dopo 30 secondi la rete torna. Cosa succede ora dipende dal comportamento del client VPN:
- Senza kill switch — nel momento in cui il Wi-Fi torna, la route predefinita del sistema operativo si ripristina sull'interfaccia Wi-Fi. Il client VPN sta ancora cercando di riconnettersi, ma le app non aspettano. La sincronizzazione in background della webmail invia la richiesta successiva sul Wi-Fi normale, usando il tuo IP reale, con qualsiasi resolver DNS fornito dalla rete. Quando la VPN finisce di riconnettersi (5-20 secondi dopo), la perdita di dati è già avvenuta.
- Con il kill switch — quando la VPN si disconnette, il kill switch installa una regola firewall che blocca tutto il traffico che non transita attraverso il tunnel. Anche quando il Wi-Fi torna, le app non possono inviare nulla finché la sessione VPN non è completamente ripristinata. La richiesta di sincronizzazione della webmail fallisce con un errore di rete (l'app riprova), ma nessun traffico lascia il dispositivo sull'interfaccia non protetta.
Il problema del fallback silenzioso è il problema centrale che i kill switch sono progettati per risolvere. Non è il caso di "la VPN è crashata e ora sto navigando in chiaro" — è il caso molto più sottile in cui la VPN è brevemente non disponibile, le app non lo sanno, e fuoriescono dati nel frattempo.
I tre tipi di kill switch
Quando i fornitori dicono "kill switch", possono intendere una qualsiasi di queste tre architetture. Le differenze contano perché le modalità di guasto differiscono.
1. Kill switch di sistema (basato su firewall)
Il modello più robusto. Il client VPN installa una regola firewall sul sistema operativo — usando pf su macOS, la Windows Filtering Platform su Windows, iptables o nftables su Linux, oppure un'estensione di rete di sistema su iOS/Android — che scarta ogni pacchetto in uscita non destinato all'IP del server VPN. Quando la VPN è attiva, il tunnel stesso instrада il traffico verso il server VPN, quindi i pacchetti passano. Quando la VPN è inattiva, nulla corrisponde alla regola "consenti", quindi tutto viene bloccato. La regola del firewall rimane in vigore anche se il client VPN crasha, perché il firewall del sistema operativo è indipendente dall'applicazione che ha installato la regola.
2. Kill switch a livello applicazione (per singola app)
Invece di bloccare tutto il traffico, il kill switch blocca solo le app specifiche che hai aggiunto a un elenco. Quando la VPN cade, quelle app perdono la connettività di rete finché la VPN non torna; le altre app continuano a funzionare normalmente. Questo è utile per scenari molto specifici — proteggere un browser specifico, un client IRC o un client BitTorrent — ma è più debole come difesa generale perché lascia una grande superficie di attacco (le app nella barra delle applicazioni, i servizi in background, i componenti del sistema operativo e le app che hai dimenticato di aggiungere all'elenco).
3. Firewall a livello di rete (VPN sempre attiva)
Su Android in particolare, esiste un primitivo più robusto dei kill switch che le app VPN implementano da sole: l'impostazione di sistema "VPN sempre attiva" con "Blocca connessioni senza VPN" abilitata. Qui è il sistema operativo stesso a far rispettare la regola — Android si rifiuta di instradare qualsiasi traffico non-VPN, indipendentemente dall'app che lo richiede. Anche se l'app VPN crasha, il sistema operativo mantiene la regola. Questo è il comportamento di kill switch più robusto disponibile su mobile ed è decisamente superiore ai kill switch implementati a livello applicazione.
Come funziona ciascun tipo a livello di sistema operativo
I dettagli di implementazione contano perché permettono di prevedere le modalità di guasto. Un kill switch basato su firewall fallisce quando l'API del firewall è difettosa. Un kill switch basato su app fallisce quando l'app crasha. Una VPN sempre attiva imposta dal sistema operativo non fallisce praticamente mai, a meno di non riavviare in modalità provvisoria.
Implementazione su iOS — NetworkExtension e regole on-demand
iOS non espone un'API letterale per il "kill switch" alle app VPN di terze parti. Ciò che espone è il meccanismo delle "regole on-demand" del framework NetworkExtension: regole che dicono "ogni volta che un'app tenta di stabilire una connessione di rete che non corrisponde a un'eccezione, forza prima la connessione alla VPN." Se la VPN non riesce a connettersi, la richiesta di connessione rimane in sospeso. Dal punto di vista dell'utente, questo si comporta come un kill switch — ma in realtà è una regola "forza VPN attiva" piuttosto che una regola "blocca tutto se la VPN è inattiva". Il risultato funzionale è simile; l'implementazione è diversa.
L'API NetworkExtension supporta anche il flag includeAllNetworks (aggiunto in iOS 14) che rende la VPN un filtro di rete a livello di sistema — anche il traffico del kernel e dei servizi di sistema viene forzato attraverso la VPN. Con questo flag impostato, la VPN funziona davvero come un kill switch completo, con il sistema operativo che garantisce che nessun traffico esca fuori dal tunnel. Non tutti i fornitori di VPN lo abilitano; il flag ha implicazioni di compatibilità.
Implementazione su Android — VPN sempre attiva + Blocca connessioni senza VPN
Il comportamento di kill switch più robusto di Android si trova in Impostazioni, poi Rete e internet, poi VPN, poi l'icona a ingranaggio accanto alla tua VPN, poi i due interruttori: "VPN sempre attiva" e "Blocca connessioni senza VPN." Quando entrambi sono attivi, è il sistema Android stesso — non l'app VPN — a rifiutarsi di instradare il traffico finché la VPN non è connessa. L'app VPN può crashare, essere forzatamente chiusa o disinstallata, e la regola persiste. La documentazione ufficiale per sviluppatori Android descrive il meccanismo in dettaglio. Questo è il gold standard per il comportamento del kill switch sui dispositivi mobile consumer.
Implementazione su macOS — estensioni di rete di sistema
macOS 11 (Big Sur) e versioni successive eseguono le VPN tramite il framework System Extension — la stessa architettura che supporta i filtri di contenuto e i filtri di rete a livello di sistema. Il kill switch è tipicamente implementato come una regola packet-filter (pf) installata dal client VPN, combinata con un'estensione di rete che mantiene la modifica della tabella di routing. Quando la VPN cade, la regola pf rimane in vigore e continua a bloccare il traffico finché la VPN non si ristabilisce. Se il client VPN stesso crasha, il comportamento dipende dal fatto che l'estensione di sistema sia configurata per rimanere caricata — i client ben progettati mantengono le regole in vigore; quelli mal progettati le eliminano al crash e perdono dati.
Implementazione su Windows — Windows Filtering Platform
Le VPN su Windows tipicamente implementano il kill switch installando regole di filtro della Windows Filtering Platform (WFP) che bloccano il traffico sull'adattatore fisico consentendo il traffico sull'adattatore VPN virtuale. I filtri persistono attraverso i riavvii del processo del client VPN (sono di proprietà del livello di filtro del kernel, non dell'app nello spazio utente), quindi anche se l'app VPN crasha, il filtro rimane. Il rischio è che alcuni client VPN usino strategie di regole firewall di qualità inferiore — ad es., manipolando Windows Defender Firewall tramite PowerShell o netsh — che possono essere aggirate da altre regole firewall o da errori di configurazione.
Quando i kill switch falliscono — condizioni di perdita da conoscere
Un kill switch non è una garanzia perfetta. Esistono condizioni ben documentate in cui il traffico può fuoriuscire anche con un kill switch abilitato. Ogni fornitore di VPN gestisce queste situazioni in modo diverso; alcune vengono risolte con un'implementazione accurata, altre sono inevitabili senza la cooperazione a livello di sistema operativo.
Avvelenamento DNS durante il bootstrap della connessione
Per connettersi al server VPN, il client VPN deve prima risolvere il nome host del server. Se il kill switch impone "nessun traffico senza VPN", ma il client VPN stesso deve eseguire una ricerca DNS per trovare il server VPN, deve esserci un'eccezione — e quell'eccezione è una piccola superficie di perdita. Una rete locale malevola potrebbe avvelenare la risposta DNS e reindirizzare il client VPN verso un server falso. La maggior parte dei client gestisce questo usando un IP fisso per il server VPN, o fissando il certificato TLS in modo che un server reindirizzato non venga validato. I client VPN economici a volte saltano questo passaggio.
Perdite IPv6
Se la tua rete ha connettività IPv6 ma il kill switch del client VPN blocca solo il traffico IPv4, il traffico IPv6 può fluire sull'interfaccia non protetta anche quando il kill switch è "attivo". Questa è una delle modalità di perdita più comuni nel mondo reale. La soluzione consiste nel fatto che il client VPN installi regole firewall IPv6 corrispondenti. Molti client più vecchi non lo fanno. Verifica sempre le perdite IPv6 dopo aver abilitato un kill switch eseguendo un test di perdita.
Portali captive (pagine di accesso Wi-Fi)
Bar, aeroporti e hotel spesso richiedono di accedere tramite un portale captive prima di poter raggiungere internet — incluso il server VPN. Un kill switch rigoroso non ti permetterà di raggiungere il portale captive perché il portale captive non è il server VPN. La maggior parte dei client VPN ha una modalità "metti in pausa il kill switch per il portale captive" che devi abilitare manualmente. Mentre è in pausa, sei senza protezione, quindi non navigare nulla di sensibile finché il kill switch non è di nuovo attivo. La VPN sempre attiva nativa del sistema operativo su Android gestisce questo in modo leggermente più elegante tramite il rilevamento del portale captive di sistema, ma il compromesso è lo stesso.
Gare di sospensione e riavvio delle app
Su mobile, il sistema operativo può sospendere l'app VPN per risparmiare batteria. Quando l'app riprende, c'è una piccola finestra temporale in cui il tunnel viene ristabilito. Se il kill switch è implementato a livello di sistema operativo (tramite includeAllNetworks su iOS o VPN sempre attiva su Android), non c'è perdita di dati. Se il kill switch è implementato puramente nell'app, può esserci una breve finestra in cui il sistema operativo ha ripreso le app ma la VPN non si è riconnessa, e le app che effettuano chiamate di rete durante quella finestra perderanno dati.
Gara al momento dell'avvio
Su desktop, il periodo tra l'avvio del sistema e l'avvio del client VPN non è protetto. Le app con funzionalità di rete che si avviano automaticamente (Mail, Slack, Steam, controlli degli aggiornamenti di sistema) spesso stabiliscono connessioni prima che la VPN sia attiva. Un kill switch robusto installa la propria regola firewall come regola persistente al momento dell'avvio, in modo che anche all'avvio il traffico sia bloccato finché la VPN non si connette. La maggior parte dei client VPN consumer non lo fa; la regola si applica solo dopo l'avvio del client.
Confronto tra i tipi di kill switch
| Tipo | Cosa blocca | Supporto OS | Modalità di guasto comuni |
|---|---|---|---|
| Firewall di sistema | Tutto il traffico non-VPN a livello kernel | macOS, Windows, Linux; iOS tramite includeAllNetworks | Perdite IPv6 se le regole sono solo IPv4; gara al boot; eccezione bootstrap DNS |
| A livello app (elenco di blocco per app) | Solo il traffico delle app in elenco | Windows, alcuni client macOS | Le app non nell'elenco continuano a perdere dati; i componenti OS perdono dati; i servizi di sistema perdono dati |
| VPN sempre attiva imposta dall'OS | Tutto il traffico a livello OS, indipendentemente dal crash dell'app | Android (VPN sempre attiva + Blocca senza VPN), iOS (NetworkExtension on-demand) | L'accesso al portale captive è bloccato finché non metti in pausa; pochissime altre modalità di guasto |
| Monitor applicazioni (la forma debole) | Nulla direttamente; chiude solo le app specificate quando la VPN cade | Alcuni client Windows la includono ancora | La gara tra rilevamento e chiusura causa perdite; non è davvero un kill switch |
Cosa offre davvero la "VPN sempre attiva" che un kill switch a livello app non dà
La distinzione più importante nel 2026 è tra i kill switch implementati dai fornitori e la VPN sempre attiva imposta dal sistema operativo. Ecco perché la versione imposta dall'OS è significativamente più robusta:
- Sopravvive ai crash dell'app VPN. Se l'app VPN crasha per qualsiasi motivo, un kill switch a livello app muore con essa. La regola firewall che aveva installato può o meno persistere a seconda dell'implementazione. Una regola imposta dall'OS è mantenuta dal sistema operativo stesso e continua ad applicarsi.
- Sopravvive ai riavvii. Molti kill switch a livello app installano le regole all'avvio dell'app e le rimuovono all'uscita, lasciando un vuoto di protezione all'avvio. Le impostazioni always-on a livello di sistema operativo sono rispettate dal primo pacchetto di rete che il sistema operativo instrada dopo l'avvio.
- Copre i servizi di sistema. La sincronizzazione cloud, i controlli degli aggiornamenti del sistema operativo, i demoni delle notifiche push e altri servizi a livello di OS non passano attraverso il normale routing del client VPN. La modalità always-on imposta dall'OS li copre; un kill switch a livello app potrebbe non farlo.
- Non può essere aggirata per errore dell'utente. Un kill switch a livello app ha un interruttore nell'interfaccia utente dell'app. Un utente (o un'altra app con i permessi necessari) può disabilitarlo. La modalità always-on a livello di sistema operativo si trova nelle impostazioni di sistema ed è più difficile da disattivare accidentalmente.
Su Android, preferisci la versione imposta dall'OS: attiva "VPN sempre attiva" e "Blocca connessioni senza VPN" nelle impostazioni di sistema, e considera il kill switch del client VPN come un supplemento. Su iOS, cerca client VPN che optino per includeAllNetworks; questo è il flag equivalente e offre garanzie simili.
Cosa fa Casper — la risposta onesta
Casper's Cloak utilizza un kill switch integrato con il sistema operativo su ciascuna piattaforma — includeAllNetworks su iOS in modo che il sistema operativo stesso faccia rispettare la regola anti-perdita, le impostazioni VPN sempre attiva su Android, e regole di packet-filter a livello kernel su macOS. Il comportamento è lo stesso su tutte e tre le piattaforme: quando il tunnel cade, tutto il traffico si ferma, incluso IPv6 e inclusi i servizi a livello di sistema operativo. Quando il tunnel torna, il traffico riprende. Non c'è nessun interruttore da ricordare, nessun elenco per app da mantenere, nessuna esclusione IPv6.
Lo abbiniamo alla protezione dalle minacce e allo scudo dalle minacce per il filtraggio attivo contro i domini notoriamente malevoli, quindi il tunnel non è solo un livello di routing — rifiuta attivamente le connessioni a phishing, malware C2 e infrastrutture note come pericolose. Il kill switch è la garanzia di base che nulla aggiri il filtraggio quando il tunnel cade brevemente. L'effetto combinato: anche sulle reti ostili come quelle descritte nel nostro articolo sugli attacchi alle reti Wi-Fi pubbliche, non si verifica quella "finestra di due secondi in chiaro" che un kill switch solo a livello app lascia aperta.
La nostra posizione sui kill switch in generale: è un'aspettativa di base, non una funzionalità premium. Qualsiasi VPN consumer che non ne offra uno nel 2026 manca di un meccanismo di sicurezza fondamentale. Per il contesto di modellazione delle minacce su perché questo conta a livello di sistema, la guida NSA sulla selezione e il rafforzamento delle VPN ad accesso remoto tratta il ragionamento architetturale in dettaglio, con una raccomandazione a favore delle architetture full-tunnel supportate da enforcement a livello kernel.
Conclusione
"Questa VPN ha un kill switch?" è la domanda sbagliata. Le domande giuste sono: dove nello stack viene applicato il kill switch (app, sistema o OS), copre IPv6, persiste attraverso crash dell'app e riavvii, ed è attivo per impostazione predefinita. Se le risposte sono "livello OS", "sì", "sì" e "sì", il kill switch sta facendo il suo lavoro. Se le risposte sono "solo livello app", "no", "dipende" e "disattivo per impostazione predefinita", hai un kill switch nel nome ma non nella protezione.
La pratica semplice: su Android, attiva la VPN sempre attiva a livello di sistema con "Blocca connessioni senza VPN". Su iOS, usa un client VPN che abilita includeAllNetworks. Su desktop, verifica dopo l'installazione eseguendo un test di perdita, poi disconnetti brevemente il server VPN (o scollega il cavo di rete) e conferma che il traffico si fermi davvero. Se il test di perdita mostra ancora il tuo IP reale, il kill switch non funziona come pubblicizzato — indaga prima di fidarti.