Il kill switch blocca solo IPv4: perché IPv6 esce lo stesso

Il tunnel cade, il kill switch segnala di essersi attivato e un download continua. Nelle regole IPv4 non c’è nulla di rotto. L’applicazione si è semplicemente spostata su un percorso per cui quelle regole non sono mai state scritte.

I dispositivi dual-stack hanno due uscite indipendenti. Bloccare una delle due è mezzo blocco.

Due insiemi di regole, due impostazioni predefinite

Su Linux, iptables e ip6tables sono tabelle separate con politiche separate. Impostare le catene INPUT e OUTPUT della tabella IPv4 su DROP non cambia nulla nella tabella IPv6, dove l’impostazione predefinita è di solito ACCEPT. La stessa separazione esiste in nftables, dove si può ispezionare una famiglia e scoprire che solo una delle due porta le proprie regole. Questa asimmetria è normale, ed è tutto il problema.

Ecco perché un kill switch può sembrare completo e comportarsi in parte. Lo script che ha scritto le regole IPv4 è stato eseguito, i contatori aumentano, la riga di log compare e un pacchetto IPv6 esce dall’interfaccia fisica completamente intatto.

Leggi ciò che il tuo client installa davvero, non ciò che promette la pagina di marketing. Alcuni client instradano IPv6 nel tunnel, altri lo bloccano deliberatamente, altri lo lasciano stare mentre un blocco a livello di piattaforma applica una regola diversa. La documentazione del fornitore è l’unica fonte di cui fidarsi qui.

Cosa ti dice la configurazione dell’interfaccia

La pagina del manuale di wg-quick include regole IPv6 nella sua configurazione di esempio, e il motivo è esattamente questa lacuna. L’esempio non è decorazione. Esiste perché le sole regole IPv4 lascerebbero aperta la seconda famiglia.

Copiare metà di un esempio produce metà di una politica. Questa è l’origine più comune di questa fuga. Un post di blog ha accorciato l’esempio per ragioni di lunghezza. La versione ridotta è poi diventata il modello che tutti hanno riutilizzato.

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

Se il secondo comando stampa una politica permissiva mentre il primo stampa DROP, hai trovato la risposta senza toccare il client. Questa asimmetria è il difetto.

Perché una sola ricerca non è tutta la storia

Un solo nome può restituire sia un record A sia un record AAAA, e le applicazioni non scelgono tutte allo stesso modo. Un browser può preferire IPv6 quando la rete lo offre e ripiegare in caso di errore, mentre una sincronizzazione in background o un programma di aggiornamento usa il proprio resolver e la propria preferenza. Un test riuscito su IPv4 dimostra quindi un percorso, non la politica.

Anche le transizioni di rete cambiano la risposta. Unirsi a un’altra rete Wi-Fi, riprendere dopo la sospensione o passare alla rete mobile può dare al dispositivo un nuovo prefisso IPv6, e la politica che sembrava adeguata sulla LAN dell’ufficio potrebbe non coprirlo.

Prova lo stato in cui il tunnel è spento

Testare mentre si è connessi dice che il tunnel funziona. Il test interessante è lo stato non disponibile, perché è lì che il kill switch dovrebbe reggere. Ferma il tunnel di proposito, poi prova le destinazioni che contano dall’app che stai proteggendo.

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

Entrambe le famiglie dovrebbero fallire chiuse. Se la richiesta IPv4 va in timeout e la richiesta IPv6 restituisce un codice di stato, la politica è incompleta, e nessuna quantità di nuovi test del tunnel lo cambierà.

Mantieni anche le eccezioni documentate in quel test. Il rilevamento della rete locale, un rinnovo DHCP o il percorso di avvio verso l’endpoint VPN possono aver bisogno di restare raggiungibili, e quelle eccezioni dovrebbero essere nominate nella politica invece di essere scoperte durante un’interruzione. Un test di fuga che fallisce perché il tunnel non riesce a tornare su non è un risultato di sicurezza, è un risultato di connettività.