Perdite IPv6 e VPN nel 2026: come chiudere tutte le falle senza perdere velocità

Perché le perdite IPv6 compromettono l'anonimato proprio ora

Cosa è il traffico IPv6 e perché la VPN a volte non lo gestisce

IPv6 non è più teoria. Nel 2026 la sua adozione globale supera il 44-48% del traffico, e in vari Paesi le reti mobili funzionano già in modalità IPv6-only con NAT64 e DNS64. Sulla carta è bello, ma c'è un problema: molti scenari VPN sono stati storicamente pensati per IPv4 e tendono a ignorare IPv6 se non si attiva esplicitamente il supporto. Così, alcune app comunicano ancora via IPv6 senza passare dal tunnel VPN, come se la VPN non ci fosse. Silenziosamente, senza errori evidenti. Questo è il vero e proprio leak.

Un esempio semplice. Attivi la VPN, vedi un nuovo IP IPv4 dal provider VPN, ti rilassi e apri il browser. Il sito richiede un record AAAA e stabilisce una connessione IPv6 diretta attraverso il tuo provider d’accesso. L'IP del provider è visibile all'esterno, i cookie restano attivi come se nulla fosse, mentre tu sei convinto di essere protetto. In un'altra scheda, WebRTC invia una richiesta STUN e mostra il tuo IPv6 globale. Sui grafici tutto sembra a posto, ma in realtà la privacy è compromessa. Fastidioso, vero?

Dove si formano le falle: dual-stack, Happy Eyeballs, QUIC e WebRTC

Le fonti di perdita sono molteplici. Il stack di rete nel 2026 usa attivamente la strategia Happy Eyeballs: il client prova contemporaneamente IPv4 e IPv6, e vince chi risponde prima. Se la tua VPN protegge solo IPv4, vince la connessione diretta IPv6. Un altro punto è che le app moderne usano HTTP/3 su QUIC, che si basa su UDP, e alcuni client VPN filtrano poco il traffico UDP in uscita con destinazioni tipo ::/0 se i filtri sono configurati approssimativamente. E poi c’è il tocco finale: WebRTC. Anche senza videochiamate, il browser può fare uno scambio STUN e mostrare il vero IPv6.

C’è una particolarità con il DNS. Quando sistema o browser usano DNS criptato, come DoH o DoQ, possono inviare richieste AAAA bypassando la configurazione VPN o il resolver di sistema. La risposta DNS suggerisce un indirizzo IPv6 al browser, che si connette direttamente. Non è magia, ma una caratteristica di come viene priorizzato il trasporto. Inoltre, applicazioni UWP o PWA talvolta gestiscono stack di rete propri che non rispettano completamente le politiche globali del client VPN. Così pensi che tutto sia in tunnel, ma parte del traffico gira fuori.

Perché le perdite sono pericolose: deanonimizzazione, geolocalizzazione, sorveglianza e blocchi

La perdita IPv6 è preoccupante per vari motivi. Prima di tutto collega immediatamente le tue azioni allo spazio IP del provider, con implicazioni di geolocalizzazione, giurisdizione e potenziali log. In secondo luogo, tracker e network pubblicitari non sono stupidi: se vedono un IPv6 costante, associano sessioni e dispositivi anche se cambia l’IPv4 VPN. Terzo, blocchi aziendali o governativi sono applicati spesso proprio via IPv6, e così vieni bloccato mentre dovresti passare inosservato.

Infine, c’è un problema strutturale con il NAT. In IPv4 il NAT ti nasconde dietro un indirizzo condiviso, mentre IPv6 è pensato senza NAT. Molte reti domestiche ricevono prefissi /56 o /64, e ogni dispositivo ha un indirizzo globalmente routabile. Sì, ci sono indirizzi temporanei e privacy a livello RFC, ma se il traffico sfugge al VPN, esponi il tuo identificativo globale reale. Non è la fine del mondo, ma è una breccia da chiudere subito.

Bloccare o tunnelizzare IPv6: scegliere la strategia

Due opzioni: disabilitare IPv6 o incanalarlo nella VPN

Ci sono due strategie di base contro le perdite. La prima, più semplice, è disattivare completamente IPv6 sulle interfacce o a livello kernel e permettere solo IPv4 attraverso la VPN. Funziona bene, è veloce e ripetibile. I contro sono evidenti: alcuni siti e reti mobili nel 2026 si aspettano IPv6 e possono degradare, e qualche app insiste su QUIC su IPv6. La seconda strategia è più elegante: abilitare pienamente IPv6 nel tunnel VPN. In questo modo hai un indirizzo IPv6 dal provider VPN, rotte ::/0 dentro il tunnel e regole firewall severe fuori.

Quale scegliere? Se vuoi azzerare il rischio sul desktop senza perdere funzionalità, disabilita temporaneamente IPv6. Se invece ti serve compatibilità massima, meglio che la VPN gestisca sia IPv4 sia IPv6. È un po’ più complesso, richiede supporto dal provider VPN, ma gli ambienti futuri e le reti non ti faranno inseguire rotte in emergenza. Ricorda però: interventi parziali del tipo “ho bloccato qualche prefisso” danno un senso di sicurezza falso.

Meccanismi tecnici: firewall, policy routing e blackhole

Bloccare localmente IPv6 può avvenire con diversi metodi sicuri. Il più semplice è disabilitare lo stack a livello di sistema. Il secondo consiste nell’usare il firewall per droppare tutto il traffico inet6 in uscita sulle interfacce fisiche, tranne quella della VPN. Il terzo è inserire una rotta default ::/0 in blackhole, così ogni pacchetto IPv6 va nel nulla se non c’è un tunnel attivo. Alcuni usano policy-based routing: marcano i pacchetti e li fanno passare solo dall’interfaccia VPN, scartando il resto.

Se incanali IPv6, le regole sono speculari. Aggiungi rotte ::/0 all’interfaccia tunnel, prendi l’indirizzo IPv6 dal provider VPN e blocca ogni inet6 in uscita fuori da quella. In WireGuard si fa con AllowedIPs 0.0.0.0/0, ::/0 e una regola killswitch. In OpenVPN con tun-ipv6 e redirect-gateway ipv6. Non dimenticare il DNS: il resolver deve fornire record AAAA e le query DNS devono passare per il tunnel, altrimenti parte del traffico salta fuori di nuovo.

Prestazioni e overhead

Dal punto di vista della velocità, bloccare IPv6 correttamente costa quasi nulla, soprattutto se fatto a livello kernel e tramite tabelle di routing. Tunnelizzare IPv6 impone un overhead simile a IPv4, in media un aumento del 3-7% della CPU per cifratura e gestione, qualche volta di più su chip ARM più vecchi. Nel 2026 WireGuard su desktop e router con offload funziona molto velocemente, quindi il discorso di “perdita di velocità” è spesso più emotivo che tecnico.

C’è un dettaglio sul tempo di connessione. Se Happy Eyeballs è mal configurato, il client può tentare IPv6 fuori tunnel e attendere timeout perché il firewall droppa i pacchetti. Questo provoca un “appiccicamento” dove il sito si apre con qualche secondo in più. La soluzione è semplice: instrada ::/0 nel tunnel o metti una rotta blackhole, evitando di appoggiarti a regole isolate dentro l’app. Così la connessione va o bene o non va, senza ritardi.

Windows 10, 11 e 12: protezione pratica contro le perdite IPv6

Disabilitazione rapida di IPv6: interfaccia grafica e PowerShell

Su Windows ci sono due modi per spegnere IPv6. Il più intuitivo è andare su Rete e Internet, Modifica opzioni scheda, proprietà dell’interfaccia interessata e togliere la spunta su Internet Protocol versione 6. Funziona, ma non sempre copre interfacce tunnel o virtuali. Il metodo più affidabile è impostare il flag DisabledComponents nel registro, ma nel 2026 Microsoft invita alla cautela. Meglio usare PowerShell e netsh per evitare mezze misure.

Comandi rapidi: apri PowerShell come admin e lancia Disable-NetAdapterBinding -Name "Ethernet" -ComponentID ms_tcpip6. Ripeti per Wi-Fi. Oppure usa netsh: netsh interface ipv6 set teredo disabled, netsh interface ipv6 set privacy state=enabled, e se vuoi disabilitare radicalmente, Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" -Name DisabledComponents -Type DWord -Value 0xff. Dopo il riavvio IPv6 sarà spento completamente. Ma non esagerare: se usi VPN con IPv6 integrato, è meglio configurare rotte e firewall.

Filtraggio con Windows Defender Firewall e WFP

Per non affidarsi solo ai checkbox, aggiungi regole rigide nel firewall. Windows Defender Firewall integra la possibilità di creare regole in uscita che bloccano tutto il protocollo TCP e UDP per i profili Private e Public riguardo IPv6, escludendo però l’interfaccia VPN. In interfaccia non è evidente, ma via netsh si può fare: netsh advfirewall firewall add rule name="Block IPv6 out" dir=out action=block protocol=any profile=any interfacetype=any remoteip=any localip=any edge=yes. Poi crea una regola che consente il traffico per la VPN con indirizzi ::/0. Ordina le regole: deny generico prima, allow specifico dopo.

Se vuoi precisione massima, usa politiche WFP tramite client specializzati o Group Policy. Queste filtrano a livello di driver callout e bloccano IPv6 prima che il pacchetto esca dallo stack. Per WireGuard controlla che AllowedIPs includa ::/0 e che l’opzione killswitch sia attiva per bloccare traffico fuori tunnel. Per OpenVPN configura tun-ipv6 e redirect-gateway ipv6. Se il provider non supporta IPv6, aggiungi block-ipv6.

DNS e modalità Always-on VPN

Un dettaglio spesso trascurato sono i DNS. Windows 11 ha DoH nativo, e alcune build del 2025-2026 testano DoQ. Assicurati che DNS criptato sia instradato attraverso la VPN. Controlla la voce Encrypted DNS nelle impostazioni di rete e seleziona un provider dall’elenco o lascia "Automatico tramite rete corrente" se il client VPN imposta un resolver dedicato. Altrimenti le query AAAA usciranno direttamente, e avrai connessioni IPv6 esterne.

Un'altra buona pratica è la modalità Always-on. Su Windows questo si imposta sia dal client VPN che tramite policy MDM in ambienti aziendali. Attiva sempre il kill switch. Senza di esso, al cambio di rete o risveglio il sistema torna subito a IPv6 diretto, esponendo qualche richiesta. È come dimenticare una finestra aperta col freddo: casa calda ma si sente il vento.

macOS e iOS: attenzione a PF e profili

Disabilitare IPv6 e scegliere l’interfaccia

macOS è tradizionalmente attento alle reti, ma ama IPv6 per default. Il passo base è usare networksetup -setv6off Wi-Fi e ripetere per Ethernet. Questo disabilita IPv6 sul servizio specifico senza compromettere tutto lo stack. Per riattivare, usa -setv6automatic. Su iOS non esiste un toggle diretto: il sistema gestisce. Se vuoi garanzia forte, meglio tunnelizzare IPv6 dentro l’adattatore VPN invece di disabilitarlo a livello mobile.

Se il provider VPN supporta IPv6, assicurati che l’interfaccia utun abbia un indirizzo del pool e la rotta ::/0. Molti client WireGuard per macOS e iOS dal 2025 aggiungono AllowedIPs ::/0 e rispettano l’opzione killswitch. Controlla l’ordine dei servizi con networksetup -listnetworkserviceorder: posiziona la VPN prima di Wi-Fi ed Ethernet, così macOS non fa il furbo.

PF: regole semplici per drop inet6

Per un controllo severo attiva PF. Nel file /etc/pf.conf inserisci righe come block out on en0 inet6 all e block out on en1 inet6 all lasciando pass out on utun0 inet6 from any to any. Ricarica con sudo pfctl -f /etc/pf.conf e abilita PF con sudo pfctl -e. Garantisce che IPv6 non esca fuori dal tunnel. Su desktop è un compromesso pratico: non spegni lo stack ma crei una barriera solida dove serve.

Ricorda che macOS usa parecchi servizi Apple: iCloud Private Relay, Handoff, AirDrop. Private Relay può usare meccanismi propri di cifratura. Se vuoi controllo totale, disattivalo: altrimenti il debug perdite si complica. Prima stabilizza la VPN, poi riattiva funzioni aggiuntive testando di nuovo.

DNS e cifratura: DoH, DoQ e resolver

Nel 2026 Safari e macOS supportano DNS criptato. Significa che il resolver può usare DoH o DoQ direttamente se il profilo configurazione lo indica. Se usi profili aziendali o custom, verifica quali resolver si applicano a ogni servizio di rete. Se DoH è attivo su Wi-Fi e il client VPN non lo intercetta, avrai ancora query AAAA fuori tunnel.

La regola è semplice: il resolver deve vivere dentro il tunnel. Se no, o droppi connessioni DNS fuori VPN o configuri il client per pubblicare il resolver di sistema usato da Safari. Sembra pignoleria, ma se una volta prendi una perdita nascosta in sleep mode, capisci perché insisti tanto su DNS.

Linux: sysctl, nftables e WireGuard intelligente

Disabilitazione globale o selettiva di IPv6

Su Linux il metodo più diretto è sysctl. Scrivi in /etc/sysctl.d/99-noipv6.conf i parametri net.ipv6.conf.all.disable_ipv6=1 e net.ipv6.conf.default.disable_ipv6=1, poi sysctl -p. Così disabiliti IPv6 ovunque. Per granularità, disattiva solo sulle interfacce fisiche: net.ipv6.conf.eth0.disable_ipv6=1, lasciando attivo su tun0 o wg0. Otterrai stack funzionante nel tunnel e vuoto all’uscita. Talvolta si usa il parametro kernel ipv6.disable=1 in GRUB, ma è una soluzione drastica, comoda per server ma non ideale su laptop.

Per un controllo raffinato prova la rotta blackhole: ip -6 route add blackhole ::/0 metric 1000. Blocca ogni IPv6 in uscita a meno che una rotta più prioritaria non esista nel tunnel. È più elegante del solo firewall e si sposa bene con policy routing. Se usi NetworkManager, ricordati di fissare metriche rotte e disabilitare auto IPv6 sulle interfacce fisiche.

nftables: regole robuste

nftables consente regole concise e rigide contro le perdite. Esempio: table inet filter { chain output { type filter hook output priority 0; policy accept; oifname "wg0" accept; ip6 daddr ::/0 drop; } }. La logica è chiara: consenti tutto su wg0, droppa ogni IPv6 fuori. Fai lo stesso per input se non serve traffico entrante. Se tunnelizzi IPv6, cambia policy: di default droppa tutto, ma su wg0 consenti IPv4 e IPv6 e aggiungi conntrack per non tagliare reverse packets.

WireGuard è ancora il re della velocità nel 2026. Nel config client metti AllowedIPs = 0.0.0.0/0, ::/0 per tunnel completo. Aggiungi Table = off e PolicyRouting se vuoi gestire rotte a mano. Attiva PersistentKeepalive, specialmente su mobile IPv6-only con NAT64, per non far dormire il tunnel. Ricordati regole nftables oifname come kill switch. Se usi OpenVPN, verifica tun-ipv6, redirect-gateway ipv6 e opzioni route-nopull o selective push se il provider dà rotte custom.

DNS: systemd-resolved, resolvconf e proxy DoH

Nei moderni distro domina systemd-resolved. Controlla che l’interfaccia wg0 registri DNS con resolvectl dns wg0 10.8.0.1 e domini corretti. Disattiva automagic sulle interfacce fisiche: in NetworkManager metti ignore-auto-dns yes e configura resolver manualmente. Altrimenti query AAAA volano ai DNS provider e rivelano IPv6 diretto.

Per cifrare DNS, lancia un proxy DoH o DoQ locale dentro il tunnel: cloudflared, dnsproxy, dnscrypt-proxy. Fondamentale che il traffico verso upstream passi da wg0, altrimenti perdi il controllo. Controllo rapido: curl -6 https://indirizzo-DNS-provider deve passare da wg0, e tcpdump -i eth0 non deve vedere pacchetti sulle porte 853 o 443 verso host DNS.

Android: reti IPv6-only e Always-on VPN

VPN sempre attiva e tunnel completo

Android ormai convive bene con IPv6-only negli operatori. Significa che senza VPN corretta il traffico esce via IPv6 con NAT64 e proprio non vuoi perdite. Attiva Always-on VPN e blocca connessioni senza VPN. È un kill switch integrato che interrompe traffico se il tunnel cade. Il client WireGuard su Android supporta AllowedIPs ::/0 e 0.0.0.0/0 per tunnel completo, non split.

Alcune app usano DNS propri o QUIC, quindi verifica che il client VPN blocchi la LAN locale e filtri IPv6. Su Android 13-15 il DNS privato è sempre attivo. Configuralo su un indirizzo raggiungibile solo via tunnel, o lascialo AUTOMATICO se il VPN pubblica un resolver dedicato. Altrimenti le query AAAA vanno ai resolver pubblici esponendo la tua privacy con un click.

ADB, OEM e trucchi extra

Non esiste un modo diretto per disabilitare IPv6 da interfaccia standard Android. In teoria puoi usare ADB e sysctl su dispositivi rootati, per esempio settare net.ipv6.conf.all.disable_ipv6=1. Ma nel 2026 è raro: più semplice creare un tunnel corretto con IPv6 e regole rigorose nel client. Alcune ROM OEM hanno ottimizzazioni reticolari che ritardano traffico fino all’attivazione VPN. Ecco perché Always-on e blocco senza VPN sono fondamentali.

Controlla WebRTC su browser mobili. Disattiva mDNS e candidati diretti se presenti o usa estensioni dove possibile. Piccoli dettagli, ma eliminano un’altra fonte di esposizione IPv6. Testa sia Wi-Fi sia LTE o 5G. Spesso a casa va bene, ma per strada si scopre la perdita da rete mobile.

DNS privati e QUIC

Android punta sulla velocità e usa QUIC ovunque, specialmente in Google services e messenger. Se firewall o client VPN non controllano UDP, le perdite sono invisibili ma reali. Configura nel client divieto di UDP in uscita fuori tunnel, tranne il DNS locale sul tunnel. Specifica un dominio per Private DNS visitabile solo via tunnel per prevenire uscite indesiderate. Sì, serve un po’ di pazienza, ma ne vale la pena.

Router: OpenWrt, MikroTik e Ubiquiti

OpenWrt: RA, DHCPv6 e policy routing

Su OpenWrt le perdite spesso nascono da RA e DHCPv6. Se vuoi bloccare IPv6 esternamente, disabilita l’invio di RA su LAN, vieta prefissi dai provider e droppa ip6 via firewall. È semplice. Ma meglio configurare una VPN che supporti IPv4 e IPv6 e che assegni indirizzi ai client via DHCPv6-PD del pool VPN. Così i browser sanno dove andare e Happy Eyeballs funziona per te, non contro.

Nel routing: installa policy-based routing, marca il traffico LAN e manda solo VPN. Aggiungi blackhole ::/0 in tabella principale per bloccare uscite senza VPN. Su WireGuard in OpenWrt usa AllowedIPs ::/0 e option route_allowed_ips 1. Nei commenti firewall lascia note comprensibili: è il tuo diario per capirci tutto dopo mesi. Documentare è la tua salvezza.

MikroTik RouterOS v7: configurazione IPv6 avanzata

MikroTik ha uno stack IPv6 dedicato. Prima molti eliminavano il pacchetto ipv6, ora è eccessivo. Configura firewall con chain=forward family=ipv6 action=drop tranne l’interfaccia WireGuard o IPsec usata. Imposta rotte ::/0 verso VPN e metriche alte per le altre. Usa mangle per marcare i pacchetti LAN e indirizzarli nella tabella di policy routing con unica rotta via VPN.

Non dimenticare ND e RA. Disabilita annunci su LAN se non distribuisci indirizzi VPN. Se li distribuisci, verifica arrivo prefisso dal provider VPN e corretto annuncio. Di solito basta per dimenticare «perdite». Usa fasttrack con calma, può bypassare parte delle regole se WireGuard non è escluso.

Ubiquiti: EdgeRouter e UniFi

Su EdgeRouter la logica è simile: configura firewall IPv6 per bloccare traffico uscente su WAN e permetti solo tunnel. Imposta rotta ::/0 sull’interfaccia VPN. Su UniFi UX inserisci regole a livello reti e client. Controlla come il controller distribuisce DNS: a volte dà resolver esterni. Cambiali in indirizzi interni della VPN o configura un resolver locale che comunica con upstream via tunnel.

Testa bene reti guest Wi-Fi. Spesso hanno isolamento client e DNS propri che bypassano le policy globali. Una spunta dimenticata e i dispositivi guest espongono IPv6 fuori VPN. Non lasciare al caso la sicurezza.

Test: come verificare l’assenza di perdite

Verifiche browser: indirizzi, WebRTC e moduli

Inizia semplice. Cerca online "test IP" e verifica che il sito veda solo l’IPv4 della VPN e nessun IPv6 diretto. Apri gli strumenti sviluppatore e guarda i log di rete. Se vedi query AAAA verso resolver fuori tunnel, c’è un problema. Controlla WebRTC con pagine dedicate: ti mostrano i candidati locali e globali. Se tra questi c’è IPv6 globale del provider, la configurazione è incompleta.

Disabilita il cambio automatico a DoH nel browser se non lo instradi via VPN. In Chrome, la configurazione Secure DNS deve puntare a un resolver raggiungibile nel tunnel. In Firefox usa impostazioni che seguano il resolver di sistema o impostane uno personalizzato. Sì, è noioso, ma una checklist fatta bene ti farà risparmiare tempo dopo.

CLI: curl, dig, ping6 e tcpdump

Da terminale è tutto trasparente. Esegui curl -4 https://example.test e curl -6 https://example.test. Il primo deve passare per VPN, il secondo o deve passare o fallire se blocchi IPv6. Usa dig AAAA per il dominio e verifica il resolver che risponde. traceroute -6 mostra se la rotta esce fuori. tcpdump -i ip6 vede tutto il traffico IPv6. Se vedi pacchetti su eth0 fuori tunnel, c’è perdita. Correggi il firewall e ripeti.

Su Windows usa Test-NetConnection -ComputerName dominio -TraceRoute -InformationLevel Detailed e netsh trace start capture=yes report=no. Su macOS monitora nettop -m tcp e log PF. Su Android senza root è più complicato, ma confronta indirizzi in app test e statistiche rete nel client VPN. Non cercare soluzioni magiche, cerca il metodo sistematico per risultati affidabili.

Automazione e alert

Se per te la sicurezza è critica, automatizza. Su Linux uno script ogni cinque minuti fa curl -6 al tuo host di controllo via tunnel e verifica risposta e interfaccia. Un secondo script ascolta tcpdump sull’interfaccia fisica e manda allarme se vede IPv6. Su Windows PowerShell controlla rotta ::/0 e regole firewall. Non è fantascienza, è semplice monitoraggio degli "indicatori" e ti salva se un driver viene aggiornato accidentalmente e resetta impostazioni.

In azienda organizza audit regolari. Ogni tre mesi fai test su laptop, telefoni e router. Aggiornamenti di sistema e VPN sono insidiosi: una nuova funzione DoQ può far tornare query AAAA fuori tunnel. Una checklist periodica costa meno di un incidente. È economia pratica.

Casi 2024-2026: esempi reali senza fronzoli

Notebook aziendale e split tunnel

L’azienda autorizzava VPN solo per app business, tutto il resto diretto. Sulla carta logico, ma Teams e Zoom usarono QUIC su IPv6 e parte del traffico multimediale uscì fuori tunnel. Gli IP esterni comparirono nei log dei partner. Soluzione: passare a tunnel completo VPN, abilitare supporto IPv6, aggiungere regola firewall Windows che blocca IPv6 fuori interfaccia VPN e disattivare QUIC forzato nelle app video. Risultato: velocità stabile, perdite azzerate, utenti ignari.

Lezione semplice: lo split tunnel nel 2026 richiede gestione precisa di domini, protocolli e trasporti. Se il team non tiene aggiornato il puzzle, meglio full tunnel e routing corretto. È noioso, ma funziona e preserva la serenità.

Router domestico provider e telefoni Wi-Fi

Scenario noto: il provider fornisce router con RA e DHCPv6 attivi, l’utente ha VPN sul laptop ma i telefoni Wi-Fi continuano a navigare IPv6 diretto. Ne nasce discrepanza di comportamento e pubblicità mirate geolocalizzate. Soluzione: disattivare RA su LAN nel router, settare OpenWrt con WireGuard e distribuzione IPv6 dal tunnel, schermare IPv6 sulla rete guest e permettere solo VPN sulla rete principale. Così tutti i dispositivi condividono la stessa policy e le perdite spariscono.

Importante: i telefoni spesso ignorano il resolver di sistema se è attivo Private DNS. Configura il Private DNS su un hostname raggiungibile solo con VPN e verifica i record AAAA da lì. Così non si ha più dubbio su chi esce fuori all’insaputa la notte.

Rete mobile IPv6-only e NAT64

L’operatore passa utenti a IPv6-only con NAT64. L’utente attiva VPN senza IPv6 e si lamenta: metà app non funziona, parte del traffico esce fuori. Soluzione: abilitare IPv6 nella VPN, permettere ::/0 su WireGuard, assicurarti che il resolver risponda per A e AAAA, eventualmente usare DNS64 nel tunnel. Bonus: attivare PersistentKeepalive per mantenere attivo il tunnel. Tutto funziona, perdite assenti, latenze stabili.

Conclusione: l’era del «spengo IPv6 e sono a posto» con operatori mobili finisce. Bisogna convivere con IPv6, ma alle nostre condizioni: attraverso VPN con regole chiare.

Checklist e best practice 2026

Dal blocco alla gestione controllata di IPv6

Step 1. Se sei nel panico, disabilita temporaneamente IPv6 sulle interfacce fisiche. Step 2. Scegli un provider VPN che supporti IPv6 e tunnel completo. Step 3. Cambia strategia: abilita IPv6 nel tunnel, bloccalo fuori. Step 4. Sistema i DNS: resolver solo via VPN, cifratura consigliata. Step 5. Fai test: browser, CLI, tcpdump. E documenta tutto per non rifare lo stesso lavoro domani.

Questa scala è semplice e affidabile. Parti da un interruttore grossolano e arrivi a una rete gestita che guarda al futuro. Sì, impiega un giorno o due, ma poi dormi tranquillo senza inseguire perdite fantasma o rallentamenti casuali.

Scelta del provider e del client VPN

Nel 2026 i requisiti minimi sono: supporto IPv6 nel tunnel, WireGuard con killswitch, corretta pubblicazione DNS, possibilità di forzare DoH e DoQ tramite VPN, regole avanzate di blocco a livello interfaccia. Audit e policy trasparenti: un grande vantaggio. Se il provider dice "IPv6 presto" da tre anni, valuta un’alternativa. Il mondo avanza e IPv6 è ora una necessità, non un lusso.

Il client deve saper bloccare traffico fuori tunnel, impostare rotte ::/0, gestire priorità, mostrare interfacce e log con dettagli su cosa e dove viaggia. Test semplice: disconnetti internet e guarda il comportamento. Se la macchina manda qualche pacchetto nel mondo, il client non va bene.

Monitoraggio e audit regolari

La best practice è trasformare il controllo perdite in procedura ordinaria. Script, report, allarmi. Ogni trimestre test completo. Dopo grandi aggiornamenti test accelerato. Su router snapshot periodiche di rotte e regole. Nei browser controlla profili attivi. Sì, sembra una scocciatura, ma è come la cintura di sicurezza: fastidiosa all’inizio, ma ti salva la vita. Non è esagerazione.

Forma gli utenti. Due slide su come riconoscere un IP corretto nei test, come controllare WebRTC e dove segnalare problemi. Spiega che DNS privato senza VPN non è privacy. Le persone sono intelligenti, hanno solo bisogno di strumenti giusti.

Errori comuni e come evitarli

Disabilitare IPv6 “globalmente” e rompere servizi

Spegnere IPv6 a livello kernel a volte rompe portali aziendali, nuovi CDN e app mobili. Non stupirti. Se puoi, adotta un modello "IPv6 solo dentro VPN". Così compatibilità e sicurezza vanno di pari passo. Se disabiliti globalmente, mantieni backup config e piano rollback. Meglio prevenire che fare l’eroe di notte.

Un altro errore: dimenticare il router. Spegni IPv6 sul laptop ma TV e telefono illuminano il loro IPv6 globale via Wi-Fi. Il tracciamento funziona lo stesso. Applica una policy unica a casa o ufficio. È disciplina che ripaga.

Perdite DNS per DoH e DoQ

Il browser abilita DoH verso resolver pubblici e butta all’aria tutta la strategia. Controlla configurazioni: DNS sicuro deve essere controllato. Su Windows e Android imposta provider nel sistema o disabilita forzature automatiche se non passano via VPN. Su macOS verifica che il profilo usi resolver intra VPN. Altrimenti installa proxy DoH locale in tunnel.

Altro problema: resolver paralleli. Il sistema può tenere più indirizzi e app diverse interrogano resolver diversi. Soluzione: punto unico, un resolver locale di sistema che va fuori solo via VPN. Evita caos da configurazioni miste.

Problemi con rotte ::/0 in WireGuard

A volte hai messo AllowedIPs ::/0 ma il traffico perde lo stesso. Controlla che il client non abbia Table = off senza policy routing adeguato. In tal caso le rotte non si applicano. Secondo punto: priorità metriche. Se l’interfaccia fisica ha metrica più bassa, il sistema ci va comunque. Aumenta metrica su fisico o abbassa su wg0. E naturalmente attiva regole nftables che droppano ip6 fuori wg0. È la tua linea di difesa finale.

Abbiamo visto anche casi di blackhole ::/0 impostato sulla tabella sbagliata: comando accetta ma niente effetto. Impara a leggere ip -6 rule e ip -6 route show table all. Un colpo d’occhio e tutto diventa chiaro. È come guardare la plancia: velocità, giri, benzina, si parte.

FAQ: risposte sintetiche e pratiche

Serve spegnere del tutto IPv6 per evitare perdite?

Non necessariamente. L’approccio più affidabile e moderno è tunnelizzare IPv6 dentro la VPN e bloccarlo fuori. Disabilitarlo completamente è una misura temporanea se devi chiudere un buco in fretta o se il provider VPN non lo supporta. Nel 2026 sempre più servizi vogliono IPv6, quindi meglio convivere amichevolmente che combatterlo.

Se temi complessità, parti semplice: disattiva IPv6 sulle interfacce fisiche, testa, poi abilitalo nel tunnel. Quando sei sicuro, passa a un modello gestito. È un’evoluzione, non un salto nel buio.

Come capire se sto perdendo IPv6 ora?

Fai due passi. Nel browser verifica se il sito vede il tuo IPv6 e se coincide con l’indirizzo VPN. Poi da terminale curl -6 verso un sito noto e controlla la rotta con ip -6 route get indirizzo. Se il pacchetto esce su interfaccia fisica, c’è perdita. Inoltre fai tcpdump su interfaccia fisica e attendi pacchetti ip6: è prova certa.

Non dimenticare WebRTC. Controlla candidati su pagine di test o nelle impostazioni browser. Se appare un IPv6 globale del provider, la configurazione è incompleta. Correggi firewall e DNS.

Il mio provider VPN non supporta IPv6. Che fare?

Hai tre opzioni. Temporaneamente disattiva IPv6 su dispositivi. Imposta regole firewall rigorose che droppano ip6 fuori tunnel. E valuta un cambio provider che offra IPv6 in tunnel. Nel 2026 non è più un extra, ma igiene base. Vivere senza IPv6 è sempre più complicato, soprattutto su reti mobile e servizi media.

Se cambiare provider non è possibile, usa checklist e automazione: script che monitorano ip6 su fisico e inviano allarmi. È un compromesso semplice ma efficace.

Il blocco IPv6 rallenta la connessione?

Se blocchi IPv6 fuori tunnel in modo corretto o lo mandi in blackhole, l’impatto è minimo. Problemi nascono solo con timeout: il client tenta IPv6, il pacchetto vien droppato e aspetta prima di passare a IPv4. Si risolve con routing corretto ::/0 nel tunnel o blackhole con metrica adatta.

Tunnelizzare IPv6 costa quanto IPv4, soprattutto con WireGuard. Su CPU moderne la differenza è spesso statistica. Molto più importante avere rotte stabili e nessun "sfarfallio".

Devo disattivare DoH e DoQ per sicurezza?

Non serve disattivare DNS criptato se lo puoi far passare via VPN. Anzi, cifrare è meglio. Il problema non sono DoH o DoQ in sé, ma che a volte aggirano il tunnel. La soluzione è che il resolver stia dentro il tunnel e qualunque tentativo fuori venga bloccato. Regola non negoziabile.

Se non puoi sistemare tutto ora, disattiva DoH nel browser finché non sei sicuro che passi solo da VPN. Poi lo riattivi e avrai privacy e ordine insieme.

Come comportarsi con WebRTC se serve per videochiamate quotidiane?

Non puoi spegnere WebRTC se la usi ogni giorno. La soluzione è farlo usare solo candidati dentro tunnel. Se c’è IPv6 nel VPN, userà indirizzo del tunnel, non globale. Inoltre blocca i candidati locali diretti se non rompono funzioni.

In azienda configura server TURN accessibili solo via VPN e assicurati che i client non si colleghino UDP fuori. È una policy più severa ma elimina perdite e sorprese.

Perché lo split tunnel è problematico nel 2026?

Non è intrinsecamente sbagliato, ma richiede disciplina e monitoraggio costanti. Se metà traffico va diretto e metà via VPN, hai un puzzle complesso di domini, protocolli e porte. Aggiungi IPv6, QUIC e DoH e ottieni un sistema dove la perdita è una statistica inevitabile.

Se non hai un team pronto a mantenere regole aggiornate e controllare, meglio full tunnel con eccezioni mirate. È noioso, ma funziona. Conta il risultato, non la poesia delle regole.