La tua VPN è connessa. Il tunnel è attivo, il client dice protetto, e il tuo traffico IPv4 ci passa davvero. E un sito che visiti registra comunque il tuo indirizzo reale, perché ti ha raggiunto via IPv6.
Qui non c'è alcun guasto da trovare. Sono due sistemi corretti che non concordano, e questo disaccordo è scritto in uno standard.
Il tuo sistema non si comporta male, applica la RFC 6724
Quando una destinazione è raggiungibile sia via IPv4 sia via IPv6, qualcosa deve scegliere. Quel qualcosa è la RFC 6724, che definisce una tabella di policy predefinita per la selezione degli indirizzi. Tre delle sue righe contano qui:
Prefix Precedence Label
::1/128 50 0
::/0 40 1
::ffff:0:0/96 35 4
::/0 è IPv6 in generale. ::ffff:0:0/96 è il modo in cui gli indirizzi IPv4 sono rappresentati in quella tabella. Quaranta batte trentacinque, e la regola di selezione della destinazione è esplicita: se Precedence(DA) > Precedence(DB), allora si preferisce DA.
La RFC enuncia la conseguenza in chiaro invece di lasciartela dedurre: un altro effetto della tabella di policy predefinita è preferire la comunicazione con indirizzi IPv6 a quella con indirizzi IPv4, se sono disponibili indirizzi sorgente corrispondenti.
Per ogni sito dual stack che visiti, quindi, il tuo sistema operativo punta prima a IPv6. È un comportamento corretto, e precede di gran lunga la tua VPN.
Perché questo diventa una fuga
Metti ora sopra una VPN che trasporta solo IPv4.
La tua macchina conserva un indirizzo IPv6 nativo del tuo operatore. Il tunnel non rivendica il traffico IPv6, quindi nulla lo intercetta. Il tuo sistema, seguendo la regola qui sopra, preferisce IPv6 per ogni destinazione che lo offra. Il risultato è che il tuo percorso preferito è quello che aggira il tunnel, e il percorso protetto riceve solo ciò che IPv6 non ha potuto servire.
Ecco perché la fuga sfugge così facilmente. Non ha l'aria di un malfunzionamento. La tua VPN segnala connesso perché lo è. Le tue verifiche IPv4 passano perché passano davvero. Il traffico che sfugge è precisamente quello che il tuo sistema ha giudicato migliore.
Verificare, e l'errore che rende inutile la verifica
La verifica è semplice: a VPN connessa, guarda che cosa vede davvero un sito, e leggi specificamente la riga IPv6 invece di dare un'occhiata a quella IPv4 e passare oltre.
Se l'indirizzo IPv6 mostrato appartiene alla tua connessione anziché al fornitore VPN, IPv6 è fuori dal tunnel. Se non compare alcun indirizzo IPv6, o la tua rete non ne ha o è bloccato, e in entrambi i casi non c'è problema di fughe.
Due cose rovinano questa verifica nella pratica:
Provare prima di connettersi. La domanda non è che aspetto hai senza protezione. È che cosa sfugge mentre ti credi protetto.
Provare una volta sola. Una configurazione che oggi trasporta IPv6 può smettere dopo una riconnessione, un cambio di rete o il passaggio dal Wi-Fi ai dati mobili, perché gli indirizzi disponibili cambiano con la rete. Un unico risultato pulito dimostra che la configurazione era corretta su una rete, in un momento.
La riga che decide, su WireGuard
WireGuard rende la causa insolitamente leggibile, perché la stessa impostazione decide sia che cosa entra sia dove escono le cose. Il manuale wg definisce AllowedIPs come un elenco di indirizzi IP (v4 o v6) separati da virgole, con maschere CIDR, dai quali è consentito il traffico in ingresso per questo peer e verso i quali è diretto il traffico in uscita per questo peer, e aggiunge che il jolly 0.0.0.0/0 può essere indicato per tutti gli indirizzi IPv4, e ::/0 per tutti gli indirizzi IPv6.
Leggilo come un'istruzione di routing, perché è quello che è. Un peer configurato con il solo 0.0.0.0/0 indirizza IPv4 nel tunnel e non dice nulla di IPv6, che continua quindi a usare la rotta normale. Aggiungere ::/0 vi indirizza anche IPv6.
Vale una condizione: il tunnel deve avere un proprio indirizzo IPv6 perché questo serva a qualcosa. Se il tuo fornitore non ne assegna, instradare ::/0 in un tunnel privo di estremità IPv6 non crea connettività IPv6. È a quel punto che bloccare IPv6 diventa il ripiego onesto e non una scorciatoia.
Bloccare IPv6 funziona, e ha un costo
Disattivare IPv6 sulla macchina rimuove il percorso preferito, quindi tutto ricade su IPv4 e nel tunnel. È efficace, ed è ciò che fanno diversi client VPN sotto l'etichetta protezione dalle fughe IPv6.
Il costo però è reale. Perdi IPv6 per tutto il resto su quella macchina, comprese le reti in cui è l'unico trasporto utilizzabile, e l'impostazione sopravvive al motivo per cui l'avevi cambiata. Sei mesi dopo, un problema di connettività del tutto scollegato diventa difficilissimo da diagnosticare perché nessuno ricorda più che IPv6 era spento.
Instradare IPv6 nel tunnel conserva la capacità e risolve lo stesso problema. Preferiscilo ogni volta che il tuo fornitore lo consente, e tratta il blocco come il ripiego per quando non lo consente.
Il kill switch non copre questo caso
Da dire a parte, perché i due si confondono nella stessa schermata di impostazioni.
Un kill switch sorveglia la caduta del tunnel e taglia il traffico quando avviene. Una fuga IPv6 accade a tunnel attivo. Non c'è alcuna caduta da rilevare, nessun evento di guasto, nulla a cui l'interruttore possa reagire. Un kill switch perfettamente funzionante starà lì a fare il suo lavoro impeccabilmente mentre il traffico IPv6 gli passa davanti.
Se il tuo client offre la protezione dalle fughe IPv6 come interruttore separato, è un meccanismo diverso, e avere l'uno non ti dà l'altro.
In sintesi
Una fuga IPv6 non è la tua VPN che si rompe. Sono la RFC 6724 che dice al tuo sistema di preferire IPv6, un tunnel che trasporta solo IPv4, e la conseguenza perfettamente logica di questi due fatti.
Verifica a VPN connessa, leggi la riga IPv6, e ripeti dopo un cambio di rete. Su WireGuard è AllowedIPs a decidere, e ::/0 è ciò che indirizza IPv6 nel tunnel. Dove il tunnel non ha un IPv6 proprio, bloccare IPv6 è un ripiego legittimo, con un costo che conviene annotare da qualche parte dove lo ritroverai.
La tabella di policy predefinita, i valori di precedenza, la regola di selezione della destinazione e l'affermazione che la tabella preferisce la comunicazione IPv6 a quella IPv4 provengono dalla RFC 6724. La definizione di AllowedIPs e la notazione jolly per 0.0.0.0/0 e ::/0 provengono dalla pagina di manuale wg(8). Entrambe sono state consultate al momento della stesura.
Guide correlate
- Audit di sicurezza VPN completo - le sette verifiche che vale la pena fare una volta, e questa è una di esse.
- Il kill switch VPN spiegato - il meccanismo che gestisce il caso opposto, quando il tunnel cade davvero.
Proteggi la tua connessione con NordVPN
Threat Protection blocca tracker e malware · kill switch · 30 giorni di rimborso
