Kill switch dell’app contro kill switch del firewall: cosa blocca ciascuno

Un kill switch in un elenco di funzioni non dice quasi nulla su cosa succede quando il tunnel cade. Un’implementazione chiude processi selezionati, un’altra installa filtri di pacchetti al confine del sistema operativo, e una terza prova semplicemente a riconnettersi. La differenza si vede nei secondi successivi a un guasto, non nella schermata delle impostazioni. Segui questi controlli in ordine e fermati al primo a cui non sai rispondere onestamente, perché è lì che finisce la tua copertura reale.

Nomina prima il meccanismo di applicazione

La chiusura dei processi è una funzione del ciclo di vita dell’applicazione. Trova programmi selezionati dopo un guasto del tunnel rilevato e li chiude. Tutto ciò che non è il processo principale sopravvive: servizi ausiliari, sincronizzazione in background e qualsiasi applicazione avviata un secondo dopo hanno il proprio ciclo di vita e i propri tempi.

Il filtraggio dei pacchetti è una funzione del sistema operativo. Rifiuta il traffico che non segue il percorso consentito, che è una promessa più forte, ma solo nella misura in cui la regola corrisponde davvero. La famiglia di indirizzi, l’interfaccia, le applicazioni escluse e le eccezioni lo decidono, non l’etichetta nel client.

Il blocco sopravvive al client?

Poni quattro domande in questo ordine: cosa succede in un crash, in un’uscita manuale, al logout e al riavvio. Una regola mantenuta dal client stesso viene di solito rimossa durante un arresto ordinato e spesso lasciata indietro dopo un crash. Una regola installata nell’archivio della piattaforma può comportarsi al contrario: sopravvivere sia al client sia, talvolta, alla disinstallazione.

Chiudi il client a metà di un download lungo e guarda se il trasferimento si blocca o continua.

Cerca i buchi standard

IPv6 è il primo. Una regola scritta per indirizzi IPv4 lascia intatto il traffico IPv6, e molti client scrivono solo la metà v4. Il secondo è l’interfaccia: il tethering USB, un secondo adattatore Wi-Fi e un modem cellulare possono non essere inclusi in una regola limitata alla connessione principale. Applicazioni escluse e le eccezioni della rete locale sono il terzo.

Su Windows puoi leggere le regole installate invece di fidarti dell’interruttore: Get-NetFirewallRule -DisplayName '*VPN*' e netsh wfp show filters mostrano entrambi ciò che esiste. Su Linux, iptables -S, ip6tables -S e nft list ruleset coprono i casi comuni, e confrontare tutti e tre è il punto.

Il DNS è la fuga abituale

Bloccare TCP lasciando aperto UDP 53 ti dà un kill switch molto convincente che risponde ancora a ogni richiesta di nome host. Lo stesso vale quando il DNS viene affidato a un resolver su un’altra interfaccia, o quando il client blocca solo v4 e il resolver è raggiungibile via v6.

Con il tunnel abbassato, risolvi un nome noto e vedi se torna una risposta. Se torna, il traffico non è del tutto bloccato, qualunque cosa dica l’icona di stato.

Prova la transizione, non l’interruttore

Spegnere la VPN dal suo menu è un arresto ordinato, e il caso ordinato ogni implementazione lo gestisce bene. La transizione che conta è quella brusca: uccidi il processo del tunnel, stacca la rete, lascia che il server smetta di rispondere. Poi avvia una richiesta e guarda se fallisce o usa silenziosamente il collegamento fisico.

Il risultato di un portatile non si trasferisce a un telefono o a un router. API di piattaforma diverse, valori predefiniti diversi, e su Android la differenza è netta: la modalità always-on con blocco la impone il sistema e non il client, quindi continua a funzionare quando il client non lo fa. La guida VPN di Android descrive questa separazione.

Mantieni una via di ritorno

Il blocco a livello di sistema ha la modalità di guasto opposta. Filtri che sopravvivono al client possono lasciare una macchina senza alcuna rete dopo una disinstallazione, il che è una chiamata all’assistenza senza causa evidente. Prima di attivare qualsiasi kill switch che scrive regole di piattaforma, annota come viene rimosso, e tieni il percorso di riparazione del fornitore dove puoi trovarlo.

Se non sai rispondere ai controlli su crash, IPv6, DNS e transizione per il tuo client, trattalo come un interruttore a livello di applicazione con buchi noti e pianifica di conseguenza.