Perché un kill switch taglia il traffico quando cambi server
Perché un kill switch blocca il traffico durante un cambio di server, cosa fa il client in quella finestra e come distinguere una pausa normale da un blocco bloccato.
Scegli un server che sembra più vicino, premi connetti e il browser smette di caricare prima che il nuovo tunnel sia attivo. L'icona passa a uno stato di connessione e resta lì mentre ogni scheda va in timeout. Quella pausa di solito è il kill switch che lavora come previsto: il traffico è bloccato finché il client non ha un tunnel da cui inviarlo. Se la pausa sia accettabile dipende da cosa fa il client in quei secondi e dal fatto che il blocco venga rimosso quando dice di rimuoverlo.
Cosa fa il client tra due server
Cambiare endpoint sono diversi passaggi, non un solo interruttore. Il client smonta il tunnel attuale, aggiorna le sue regole di blocco, risolve e raggiunge il nuovo endpoint fuori dal tunnel, poi installa le nuove rotte e toglie il blocco. Il vuoto che percepisci sta tra il primo passaggio e l'ultimo.
Qui l'ordine conta più della velocità. Se le regole di blocco entrano prima dell'eccezione per il nuovo endpoint, il client non riesce a completare l'handshake e resta su connessione fino a un timeout. Se l'eccezione è una copia dell'indirizzo del vecchio server, il nuovo handshake sembra qualsiasi altro pacchetto in uscita e viene scartato. Entrambi i casi appaiono identici dal browser, ed è per questo che un cambio che si riprende dopo sei secondi e uno che non si riprende mai possono avere la stessa causa.
Il nuovo endpoint ha bisogno di un buco nel blocco
Per costruire il tunnel, il client deve inviare pacchetti all'indirizzo e alla porta del nuovo server sull'interfaccia fisica, per esempio UDP 51820 in un tipico profilo WireGuard o 1194 e 443 per OpenVPN, qualunque cosa specifichi il tuo profilo. Quel traffico non è dentro il tunnel che sta per essere creato, quindi un blocco per l'intero dispositivo lo inghiotte a meno che esista una regola di permesso corrispondente.
I profili basati sul nome host aggiungono un secondo requisito: la risoluzione stessa. Se il client risolve l'endpoint prima che il blocco salga, può usare un indirizzo in cache, ma quando il profilo ruota gli indirizzi o la voce in cache diventa vecchia, l'handshake punta a un indirizzo che la regola di permesso non copre. IPv6 lo rende visibile, perché un endpoint a doppio stack può pubblicare sia un record A sia uno AAAA, e una regola di permesso che copre solo l'indirizzo v4 lascia il client a ritentare contro un indirizzo v6 bloccato.
I nomi delle opzioni e i valori predefiniti cambiano da client a versione, quindi leggi l'elenco documentato per il tuo invece di indovinare dalle schermate. Il riferimento delle impostazioni di OpenVPN Connect su openvpn.net/connect-docs/app-settings-windows è un esempio di come un client descrive le sue opzioni di blocco e di tunnel diviso.
Fail-closed è una macchina a stati, non un interruttore
La maggior parte dei client esprime il blocco come politica del firewall in tre stati: tunnel attivo, con il traffico che passa dal tunnel e nessun blocco; tunnel abbassato, con il blocco attivo; e transizione, con il blocco attivo più eccezioni temporanee per l'endpoint. È nel terzo stato che vivono i bug, perché deve cambiare due volte nel giro di un paio di secondi, e non uscirne appare esattamente come un blocco permanente.
Il meccanismo cambia da piattaforma a piattaforma, e anche il guasto. I filtri di Windows Filtering Platform hanno pesi, quindi un filtro di blocco che supera il tuo permesso continua a scartare pacchetti anche se il permesso esiste, e i filtri lasciati da un processo client ucciso possono tenere la macchina offline dopo che l'applicazione è sparita. I client macOS di solito scrivono regole pf in un anchor, dove l'ordine delle regole e le decisioni rapide stabiliscono quale regola si applica. I client Linux di solito gestiscono una catena nftables o iptables con politica drop e permessi espliciti per l'endpoint, l'interfaccia del tunnel e il loopback. La VPN sempre attiva di Android con l'opzione di bloccare le connessioni senza VPN è la più severa del gruppo, perché il sistema applica il blocco all'intero dispositivo e non per applicazione.
WireGuard merita una nota a parte, perché AllowedIPs è un selettore di instradamento, non un bloccante. Decide quali destinazioni entrano nel tunnel; non fa nulla per impedire a un pacchetto ancora senza tunnel di uscire in Wi-Fi. In una configurazione solo WireGuard e senza regola del firewall, il kill switch è in realtà l'assenza di una rotta, e dopo un handshake scartato può uscire un pacchetto reale dall'interfaccia fisica.
Misura il vuoto invece di guardare l'icona
Osserva i pacchetti, non la spia di stato. Su Linux avvia un ping lento verso un indirizzo pubblico in un terminale e cattura la porta di trasporto del tunnel sull'interfaccia fisica in un altro:
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
Cambia server nel client mentre entrambi girano. Tre cose contano: quanto si fermano i ping, se la cattura mostra l'handshake che raggiunge il nuovo endpoint e se il traffico riprende prima o dopo che lo stato del client passa a connesso. Se il vuoto dei ping finisce prima, o il blocco è stato tolto troppo presto o il tunnel è attivo prima che l'indicatore lo ammetta. Se il vuoto finisce più tardi, l'indicatore è ottimista.
Su Windows, netsh wfp show state scrive un'istantanea in cui puoi cercare filtri di blocco ancora presenti mentre il client dichiara di essere disconnesso. Su macOS, sudo pfctl -sr elenca le regole caricate e il loro ordine. Abbina una delle istantanee al registro del client stesso; la cronologia del tuo ping ti dice se il blocco è finito tardi o non è mai finito.
Blackout normale contro blocco bloccato
Un po' di interruzione è lo scopo della funzione, quindi fai un triage prima di cambiare qualsiasi impostazione:
| What you see | Usually means | Next check |
|---|---|---|
| Two or three seconds of timeouts, then normal browsing | Expected fail-closed gap | Nothing to fix |
| State says connected, traffic stays dead | Block filter or route left behind | Firewall snapshot, client log |
| One app dead while others work | TCP session bound to the old exit address | Restart the app |
| LAN devices unreachable after the switch | LAN exception not reapplied | Allow-LAN or split-tunnel setting |
| New server hangs, the old one reconnects | Permit covers only the old address | Resolved address of the new host, including AAAA |
Se finisci nella seconda o nella quinta riga, non disattivare il kill switch per provare, perché questo trasforma un bug di instradamento in una fuga. Riavvia il servizio del client, o riavvia la macchina dove i filtri sopravvivono all'uccisione del processo, poi guarda se il blocco si schiarisce. Se si schiarisce, il guasto è nella pulizia durante il cambio e non nel blocco.
Prima del prossimo cambio, conferma quattro cose: il permesso dell'endpoint copre ogni famiglia di indirizzi che il tuo profilo risolve, il registro del client mostra la transizione completata, il tuo test di ping misura il vuoto e non l'icona, e chiudere il client ripristina la connettività normale. Un kill switch che tiene durante il cambio e rilascia dopo fa il suo lavoro. Uno che rilascia presto, o mai, merita di essere depurato.