Always-on VPN o kill switch: cosa hai davvero attivato?

Always-on e kill switch stanno a due righe di distanza nella stessa schermata delle impostazioni, perciò la gente li legge come due nomi dello stesso meccanismo. Non lo sono. L'always-on è una politica di riconnessione: avvia il tunnel al boot, riportalo su dopo un crash o un cambio di rete e continua a riprovare finché fallisce. Il kill switch è una politica di traffico: indica quali pacchetti possono ancora uscire dalla macchina mentre il tunnel è giù. Puoi attivare il primo senza il secondo, e sulla maggior parte delle piattaforme il risultato predefinito lascia comunque uscire traffico durante quel vuoto.

Controllo 1: il blocco è un interruttore a sé?

Su Android 10 e successivi, un profilo VPN salvato apre due interruttori indipendenti dietro l'icona dell'ingranaggio: Always-on VPN e Block connections without VPN. Solo il secondo è il kill switch. Con il solo always-on il tunnel torna su dopo una caduta, e qualsiasi applicazione a metà richiesta può raggiungere la rete via Wi-Fi o dati mobili finché non succede.

I dispositivi gestiti mantengono la stessa separazione nell'API delle politiche: setAlwaysOnVpnPackage() prende il nome del pacchetto e un flag lockdownEnabled; un amministratore che imposta il pacchetto e lascia il flag a false ha costruito un tunnel persistente, non un dispositivo chiuso. La formulazione della console raramente rende visibile quella differenza.

Leggi lo stato dal dispositivo, non dalla console: adb shell settings get global always_on_vpn_app e adb shell settings get global always_on_vpn_lockdown. Se il primo restituisce null, nessun pacchetto è imposto a livello di piattaforma; se il secondo restituisce 0, la piattaforma non sta bloccando nulla. La guida VPN di Android li documenta come capacità separate e non come un'unica modalità.

Controllo 2: quale livello possiede il blocco?

Le etichette vivono nel client e i blocchi di solito nel firewall, ed è per questo che la stessa parola significa cose diverse su ogni piattaforma. Le righe qui sotto sono quelle da confermare prima di fidarti di una qualsiasi.

Windows è l'esempio più chiaro di un'etichetta che non blocca. Lì Always On descrive la persistenza del tunnel: un tunnel di dispositivo per l'autenticazione della macchina, un tunnel utente per l'account connesso, configurati tramite XML del profilo o Add-VpnConnection. Nulla in quel profilo ferma un pacchetto in uscita quando il tunnel manca, e il filtro in uscita non è attivo per impostazione predefinita, quindi un portatile su Wi-Fi continua a funzionare mentre la VPN è giù.

WireGuard si divide allo stesso modo, ma per client. WireGuard for Windows offre un'opzione Block untunneled traffic per tunnel che installa regole di filtro; gli strumenti Linux non hanno un interruttore equivalente. wg-quick aggiunge una route per ogni voce AllowedIPs più una regola fwmark, e wg-quick down rimuove entrambe, così la route predefinita fisica riprende il sopravvento senza un pacchetto perso nel mezzo.

Sulle piattaforme Apple l'always-on arriva come funzione del profilo di gestione per dispositivi supervisionati e si esprime come regole on-demand invece che come casella di controllo. La domanda a cui rispondere dal payload è se un tunnel fallito nega il traffico o chiede solo un'altra connessione. Il titolo del menu non te lo dirà.

Controllo 3: misura il vuoto, non l'icona

Contano quattro transizioni, e falliscono in modi diversi: il boot prima che qualcuno acceda, sospensione e ripresa, il passaggio da Wi-Fi a dati mobili e un crash del client che lascia l'interfaccia del tunnel a metà configurazione. Una riconnessione pulita su una di esse non dimostra nulla sulle altre tre.

Il test più economico ferma il tunnel di proposito e poi prova a uscire. Con il tunnel giù, curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com che restituisce 200 significa che la politica è fail-open; un timeout o una connessione rifiutata significa che qualcosa sta ancora bloccando. ip route get 1.1.1.1 nomina l'interfaccia che porterebbe il pacchetto, di solito più informativa dell'icona nella tray, e systemctl status wg-quick@wg0 mostra se l'interfaccia è stata rimossa in modo pulito.

Esegui la stessa prova in una seconda finestra mentre la rete cambia, non solo dopo che si è assestata. L'intervallo tra la caduta e il nuovo tentativo è la parte che conta, e la risoluzione dei nomi è il modo più rapido per accorgersi che il traffico è fuggito: se il resolver locale risponde mentre il tunnel è giù, il blocco non è completo.

Controllo 4: decidi le eccezioni prima di chiudere tutto

Due eccezioni sono strutturali. Il client deve raggiungere il server VPN stesso, quindi un set di regole che scarta tutto impedisce anche la riconnessione che ripristinerebbe la protezione. Nemmeno un captive portal è raggiungibile attraverso un tunnel che non è attivo, quindi un dispositivo bloccato sul Wi-Fi di un hotel ha bisogno di un modo documentato per aprire il portale, non improvvisato.

Una forma minima, endpoint consentito e tutto il resto scartato:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

Tratta quella riga dell'endpoint come una variabile, non una costante. I fornitori ruotano gli indirizzi, e un'eccezione obsoleta è la ragione abituale per cui un kill switch funzionante diventa un dispositivo che non si riconnette. Stampanti locali, condivisioni NAS e servizi di sviluppo appartengono allo stesso elenco scritto, altrimenti vengono scoperti un ticket di assistenza alla volta.

Controllo 5: registra cosa hai davvero dimostrato

Tieni una tabella a quattro colonne e compilala testando: stato, comportamento atteso, comportamento osservato, prova. Le righe sono le transizioni del controllo 3 più un guasto deliberato. Una riga che non riesci a riempire con l'output di un comando è una riga che non hai testato, e un dispositivo che passa la riga della riconnessione ma fallisce quella del boot è abbastanza comune da valere i dieci minuti in più.

Prima di dichiararlo finito:

• Conferma che l'impostazione di blocco sia separata da quella di riconnessione e leggine il valore sul dispositivo.
• Sappi quale livello applica il blocco - opzione del client, politica del dispositivo o firewall - e dove quel livello è configurato.
• Conserva un comando di prova che dimostri il blocco ed eseguilo durante una transizione, non dopo.
• Scrivi l'elenco delle eccezioni, endpoint incluso, e annota chi lo aggiorna.
• Su hardware gestito lascia stare la politica imposta; rimuovere il blocco cambia il requisito invece di riparare il tunnel.