Un kill switch VPN sopravvive a un riavvio? Come verificarlo

Riavviare è il modo più comune in cui le persone testano un kill switch, ed è il test che mente più spesso. La casella di controllo nel client è una preferenza; ciò che conta è se qualcosa impone un blocco tra il momento in cui lo stack di rete sale e il momento in cui il tunnel è realmente stabilito. Su Windows quel qualcosa è di solito un filtro in Windows Filtering Platform, su Linux un insieme di regole caricato da un’unità, su macOS un’ancora pf, su Android i flag del sistema stesso per always-on e blocco. Queste sistemazioni si comportano in modo molto diverso durante un riavvio, e solo quelle a livello di piattaforma sono al loro posto prima che chiunque possa accedere.

Un riavvio pone tre domande separate

Dividete la domanda. Primo, la politica esiste sul disco in una forma che qualcosa legge all’avvio? Secondo, quel lettore viene eseguito prima che qualsiasi traffico possa uscire? Terzo, la politica copre il traffico che vi interessa, cioè ogni processo, entrambe le famiglie di indirizzi e il DNS. Un sì alla prima e un no alla seconda producono esattamente il guasto che le persone segnalano come kill switch che non sopravvive a un riavvio: il traffico esce per qualche secondo all’avvio, e nessuno se ne accorge finché qualcuno non va a guardare.

Tenete separati i livelli. Un insieme di regole del firewall salvato, un servizio che parte all’avvio e una preferenza del client sono tre oggetti diversi con tre durate diverse. La preferenza sopravvive ai riavvii perché è un valore in un file di configurazione. Le regole sono l’unica cosa che blocca i pacchetti, e svaniscono con il kernel che le teneva.

Trovate l’oggetto che ripristina il blocco

Su Linux le regole netfilter vivono nel kernel. Nulla le riscrive all’avvio se non l’avete organizzato: iptables-save più netfilter-persistent, nftables.service carica /etc/nftables.conf, o un’unità systemd che esegue il vostro script. Verificate ciò che è abilitato invece di ciò che ricordate di aver configurato.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

Un insieme di regole vuoto pochi secondi dopo l’avvio è la risposta alla domanda nel titolo. Su Windows chiedete al servizio client come parte, poi estraete lo stato del filtro di piattaforma mentre il tunnel è giù.

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

Il secondo comando scrive wfpstate.xml nella directory corrente. Cercate filtri con un’azione di blocco che esistono già prima che il client si connetta. Base Filtering Engine parte presto e ripristina i filtri aggiunti con il flag persistente, per questo alcuni kill switch bloccano il traffico prima che esista qualsiasi finestra del client e altri no. Su macOS, sudo pfctl -s info riporta se pf è abilitato, sudo pfctl -s rules mostra cosa è caricato, e i client VPN di solito agganciano le proprie regole a un’ancora invece che all’insieme principale. Una regola che nomina utun3 può puntare a un’altra interfaccia dopo il riavvio successivo, perché quel numero viene assegnato a runtime.

Osservate lo scarto tra rete attiva e tunnel attivo

L’intervallo pericoloso non è tutto il riavvio, è lo scarto. L’interfaccia riceve un lease e una rotta predefinita in un momento, il servizio VPN parte in un altro, e il tunnel si autentica ancora più tardi, a volte solo dopo che un utente ha effettuato l’accesso e un agente delle credenziali è stato eseguito. Se il blocco viene applicato per ultimo, tutto ciò che è nello scarto esce in chiaro.

Sugli host systemd leggete l’ordine invece di indovinarlo. Eseguite systemctl cat sulle unità VPN e firewall e cercate After= o Before= rispetto a network-pre.target e network-online.target. Un’unità firewall ordinata dopo network-online.target perde contro l’interfaccia; quella richiesta da e ordinata prima di network-pre.target vince. Su Windows le domande equivalenti sono il tipo di avvio del servizio e le sue dipendenze, perché un servizio impostato su Manual non può bloccare un processo all’avvio. Se il vostro requisito include traffico prima dell’accesso, solo una sistemazione a livello di dispositivo lo soddisfa: un tunnel di dispositivo Always On VPN si autentica con un certificato macchina e si connette prima che l’utente acceda, e Microsoft documenta la configurazione del tunnel di dispositivo separatamente dal tunnel utente. Android prende l’altra strada, imponendo la VPN always-on e bloccando le connessioni senza di essa dal sistema e non da un processo applicativo.

Eseguite il test, poi confrontate due cronologie

Riavviate con una destinazione che non costa nulla se perde, e catturate lo stato durante lo scarto invece che dopo. Il metodo più pulito è una sonda di avvio: un’unità oneshot o un’attività pianificata che parte il prima possibile secondo la piattaforma, registra la rotta predefinita e lo stato del firewall, tenta una richiesta con un timeout breve e aggiunge una riga a un file locale. Confrontate quel registro con l’ora di avvio del servizio VPN da journalctl -b -u o dal registro di sistema.

Poi eseguite il test ordinario: tunnel su, interrompete la connessione, guardate se il traffico diretto viene bloccato, ripristinate. Superare il secondo e fallire il primo è il risultato normale, e significa che l’applicazione è lato client, applicata quando il client si connette e non all’avvio. Sull’ultima macchina che ho verificato il blocco veniva da uno script dispatcher di NetworkManager: presente e corretto e inutile per i secondi prima che l’interfaccia salisse. Annotate entrambi i risultati, perché sopravvivere a un riavvio significa qualcosa solo quando dite quale livello è sopravvissuto e da quale momento.

Chiudete lo scarto senza tagliarvi la via di ritorno

Se il blocco manca all’avvio, abbassate l’applicazione di un livello invece di aggiungere una seconda regola client. Salvate l’insieme di regole e caricatelo da un’unità ordinata prima che la rete sia utilizzabile, e assicuratevi che quell’unità non richieda una risoluzione DNS né un mount di rete che dovrebbe proteggere. La portata conta quanto il momento: le regole che corrispondono a un ID utente o a un cgroup lasciano ogni demone di sistema fuori dal blocco, e un insieme di regole che gestisce solo IPv4 lascia IPv6 e DNS raggiungibili.

Lasciatevi una via di ritorno. Una macchina che blocca tutto all’avvio e poi non riesce ad autenticarsi non ha rete affatto, e la correzione non è eliminare il blocco ma riparare la credenziale o l’ordine. Mantenete una procedura documentata per la console locale e un’eccezione stretta e deliberata per ciò che il tunnel richiede davvero, come l’indirizzo del server e il resolver usato prima che il tunnel esista.

Prima di fidarvi della configurazione, confermate quattro cose nell’ordine. La politica è memorizzata dove l’avvio legge. Quel lettore gira prima che l’interfaccia sia utilizzabile. Il blocco copre entrambe le famiglie di indirizzi e il DNS. La VPN può ancora autenticarsi mentre il blocco è attivo. Quando tutte e quattro valgono, un riavvio non cambia nulla.