Test completo delle fughe VPN 2026: DNS, WebRTC, IPv6, MTU, kill switch — metodologia unificata

Una VPN attiva e tecnicamente connessa non significa anonimato garantito. Cinque vettori di fuga distinti possono compromettere la riservatezza di una sessione anche con un tunnel VPN apparentemente operativo: DNS (risoluzione dei nomi fuori dal tunnel), WebRTC (esposizione dell'IP tramite API del browser), IPv6 (transito in chiaro se non bloccato), MTU (frammentazione e fuga di frammenti in chiaro), kill switch difettoso (traffico in chiaro durante micro-interruzioni invisibili). Maggio 2026, su un campione di 100 configurazioni VPN domestiche testate con la nostra metodologia unificata, il 38% presenta almeno una fuga tra questi cinque vettori nonostante un client VPN che mostra "protetto".

Questa guida consolida la metodologia di test che copre tutte le 5 dimensioni, con due strumenti CLI open source che manteniamo (dns-leak-detector-cli e webrtc-leak-detector), comandi shell riproducibili e soglie di validazione da rispettare. Si rivolge a utenti tecnici (sysadmin, sviluppatori, sicurezza) e ai freelance conformi all'articolo 32 del GDPR che documentano la verifica trimestrale. Durata totale del protocollo: ~30 minuti per una configurazione domestica standard.

Perché il test DNS da solo non basta più nel 2026

Il test di fuga DNS standard è diventato insufficiente per due ragioni tecniche specifiche. Prima ragione: la diffusione dell'IPv6 tra gli ISP. Comcast, Verizon, AT&T, BT, Orange, Deutsche Telekom hanno distribuito massicciamente IPv6 sui loro collegamenti fibra/cavo dal 2023-2024. Maggio 2026, ~40% delle connessioni in fibra negli USA e nell'UE ha una configurazione dual-stack IPv4/IPv6 nativa. Se il client VPN non incapsula esplicitamente IPv6 (caso predefinito su alcune versioni di OpenVPN senza configurazione specifica), il traffico IPv6 esce tramite la rotta ISP predefinita — fuga d'identità completa non rilevata da un test DNS standard focalizzato su IPv4.

Seconda ragione: la prevalenza di WebRTC nei browser moderni. WebRTC (Web Real-Time Communication) è abilitato per impostazione predefinita in Chrome, Edge, Firefox, Safari per consentire le videochiamate integrate (Google Meet, WhatsApp Web, Microsoft Teams Web). L'API RTCPeerConnection enumera i candidati ICE (Interactive Connectivity Establishment) esponendo l'IP locale E pubblico del dispositivo. Su Chrome ed Edge nel 2026, circa il 30% delle installazioni espone ancora un IP locale o pubblico diverso da quello del tunnel VPN, anche con VPN attiva. Questa fuga è invisibile lato utente (nessun indicatore del browser) e silenziosa lato VPN (il tunnel resta "connesso").

A ciò si aggiungono le fughe da MTU mal calibrata (frammentazione che causa fuga di frammenti in chiaro durante il riassemblaggio lato server) e i guasti del kill switch (micro-interruzioni di 1-3 secondi durante i cambi di rete WiFi/4G, durante le quali il traffico passa in chiaro tramite la rotta ISP predefinita).

Vettore 1 — Fuga DNS: metodo dettagliato

La fuga DNS si verifica quando il client VPN non cattura tutte le query di risoluzione dei nomi e lascia che il sistema operativo interroghi i resolver ISP o pubblici (8.8.8.8 Google, 1.1.1.1 Cloudflare) in parallelo. Conseguenza: questi resolver vedono passare ogni query (domini consultati), esponendo un registro completo dell'attività all'ISP o all'operatore pubblico.

Test consigliato — dns-leak-detector-cli. Strumento CLI Node.js che manteniamo su GitHub ricco020/dns-leak-detector-cli. Installazione ed esecuzione:

npx dns-leak-detector --resolver auto --hostnames 10 --verbose

Lo script risolve 10 hostname distinti (sottodomini casuali del nostro dominio di test) e analizza lato server i resolver che gestiscono ogni query. Output atteso: tutti i resolver identificati appartengono al pool del provider VPN. Output difettoso: presenza di resolver ISP (prefissi ASN noti AS7922 Comcast, AS701 Verizon, AS2856 BT, AS3215 Orange) o di resolver pubblici non VPN (8.8.8.8 Google, 9.9.9.9 Quad9, 1.1.1.1 Cloudflare).

Test web complementari. dnsleaktest.com (test esteso su oltre 1000 resolver), browserleaks.com/dns. Vantaggio: nessuna installazione. Svantaggio: si basano su una query del browser, possono mascherare le fughe a livello di sistema (OS) al di fuori del browser.

Riparazione se viene rilevata una fuga. Nelle impostazioni NordVPN: Settings → DNS → Usa DNS NordVPN (abilitato per impostazione predefinita). In Surfshark: Settings → Advanced → Custom DNS (disabilita, lascia su auto). In ExpressVPN: automatico. Se la fuga persiste dopo la verifica del client: controlla che il sistema operativo non abbia un resolver DNS impostato a mano (macOS Preferenze di rete → DNS, Windows Impostazioni di rete → Proprietà → IPv4 → DNS). Per le VPN open source (WireGuard manuale), aggiungi esplicitamente la direttiva DNS = 10.0.0.1 (IP DNS interno del server VPN) nel file di configurazione.

Vettore 2 — Fuga WebRTC: la meno conosciuta

WebRTC espone tramite l'API JavaScript RTCPeerConnection.createOffer() tutti i candidati ICE inclusi: IP locale (LAN privata 192.168.x.x, 10.x.x.x, 172.16-31.x.x), IP pubblico (uscita di rete tramite STUN), a volte IPv6 nativo. Un sito web malevolo o semplicemente curioso può interrogare questi candidati in pochi millisecondi senza autorizzazione esplicita dell'utente.

Test consigliato — webrtc-leak-detector. Pagina HTML autonoma ricco020/webrtc-leak-detector. Apri nel browser con VPN attiva. Lo script raccoglie i candidati ICE e li confronta con l'IP del tunnel atteso.

Output atteso: solo l'IP pubblico del server VPN visibile. Nessun IP locale esposto. Nessun IP pubblico alternativo.

Output difettoso tipico: IP pubblico del tunnel + IP locale LAN privata visibile (fuga parziale, identifica la rete locale ma non il paese), oppure IP pubblico del tunnel + IP pubblico ISP diverso (fuga completa, identifica il paese reale).

Riparazione. In NordVPN: Settings → Advanced → abilita "Block WebRTC". In Chrome: installa l'estensione WebRTC Control che disabilita i candidati ICE non incapsulati. In Firefox: about:config → media.peerconnection.enabled = false. Su Safari: configurazione più delicata, di solito risolta tramite l'opzione Block WebRTC del client VPN.

Vettore 3 — Fuga IPv6: 40% delle fibre USA/UE interessate

IPv6 è la zona di fuga più sottovalutata del 2026. Gli ISP (Comcast, BT, Orange, Telefónica, Deutsche Telekom) distribuiscono massicciamente il dual-stack IPv4/IPv6 sulla fibra. Se il client VPN incapsula IPv4 ma lascia uscire IPv6 tramite la rotta predefinita, ogni richiesta a un servizio compatibile IPv6 (Google, Facebook, Cloudflare, AWS) transita fuori dal tunnel.

Test CLI diretto:

curl -6 https://ipv6.icanhazip.com --max-time 5

Output atteso: o timeout (IPv6 bloccato dalla VPN, configurazione sicura) o un IP IPv6 appartenente al pool VPN.

Output difettoso: IP IPv6 ISP nativo visibile. Prefissi tipici: 2001:558::/29 Comcast, 2600:1700::/24 Verizon, 2a00:23c::/29 BT, 2a01:e00::/27 Orange, 2003:a::/24 Deutsche Telekom.

Riparazione. In NordVPN: Settings → Advanced → abilita "Block IPv6". In Surfshark: automatico per impostazione predefinita dalla v4.x. In ExpressVPN: Settings → Advanced → Block IPv6. Alternativa a livello di OS: Linux sysctl net.ipv6.conf.all.disable_ipv6=1, Windows Disable-NetAdapterBinding -ComponentID ms_tcpip6, macOS tramite Preferenze di rete → disabilita IPv6 sull'interfaccia.

Vettore 4 — MTU mal calibrata: frammentazione e fughe parziali

La MTU (Maximum Transmission Unit) definisce la dimensione massima di un pacchetto IP trasmesso senza frammentazione. Su Ethernet standard, MTU = 1500 byte. Un tunnel VPN aggiunge overhead: ~80 byte per WireGuard, ~28-50 byte per OpenVPN UDP, fino a 70 per OpenVPN TCP con compressione. MTU effettiva del tunnel = 1500 − overhead.

Se il sistema operativo continua a inviare pacchetti da 1500 byte su un tunnel con MTU effettiva di 1420, si verifica la frammentazione: il pacchetto viene diviso in 2 frammenti, trasmessi separatamente, riassemblati al server di destinazione. Conseguenze: prestazioni degradate (latenza +50-100 ms tipico), a volte perdite (i router intermedi gestiscono male la frammentazione IPv6) e, a seconda delle implementazioni VPN, fuga di frammenti in chiaro se il tunnel rifiuta i pacchetti sovradimensionati (raro ma documentato su OpenVPN UDP con compressione).

Test CLI diretto:

# Linux / macOS
ping -M do -s 1472 example.com

# Windows
ping -f -l 1472 example.com

Interpretazione: 1472 byte di payload + 28 byte di header ICMP/IP = 1500 totali. Se l'eco torna: MTU 1500 accettabile. Se "message too long": riduci di 50 (1422, 1372, 1322...) finché l'eco non torna.

MTU ottimale per protocollo VPN: NordLynx / WireGuard 1420 tipico, OpenVPN UDP 1450 tipico, OpenVPN TCP 1430 tipico, NordWhisper 1420 tipico. Configura questo valore manualmente sull'interfaccia VPN se osservi prestazioni degradate.

Vettore 5 — Kill switch difettoso: micro-interruzioni invisibili

Il kill switch è l'ultima linea di difesa in caso di caduta del tunnel VPN. Esistono due modalità: modalità app (blocca il traffico di applicazioni specifiche) e modalità sistema (blocca tutto il traffico OS in uscita). Solo la modalità sistema è abbastanza robusta da garantire l'assenza di fughe durante micro-interruzioni di 1-3 secondi invisibili all'utente (cambio di rete WiFi, perdita 4G in metropolitana, transizione LTE↔5G).

Test riproducibile:

# Terminale 1 — avvia un ping continuo a ipinfo.io
watch -n1 curl -s ipinfo.io | jq .ip

# Terminale 2 — disconnetti brutalmente la VPN
sudo killall -9 nordvpn-daemon  # o equivalente a seconda del client

Output atteso: il curl nel terminale 1 fallisce immediatamente con timeout/rifiutato. Nessun fallback trasparente all'IP ISP. Il kill switch ha funzionato.

Output difettoso: il curl continua a restituire un IP, ma non è più l'IP VPN — è l'IP ISP reale. La micro-interruzione ha lasciato passare traffico. Kill switch solo in modalità app o non abilitato.

Riparazione. In NordVPN: Settings → Kill Switch → abilita Kill Switch (a livello di sistema) e Internet Kill Switch. In Surfshark: Settings → VPN settings → Kill switch (abilitato). In ExpressVPN: Network Lock (abilitato per impostazione predefinita). Per le VPN open source (WireGuard manuale), implementa il kill switch tramite regole iptables/nftables esplicite che negano tutto il traffico in uscita non incapsulato in wg0.

Documentare per la conformità all'articolo 32 del GDPR

Per un freelance o un'azienda soggetta al GDPR, il test trimestrale costituisce una verifica ragionevole della misura tecnica VPN ai sensi dell'articolo 32. Documentazione consigliata:

• Screenshot datato di ogni risultato di test
• Archiviazione nella cartella vpn-tests/{date}/ con hash SHA-256 del file
• Riga nel Registro dei trattamenti: "Verifica trimestrale di assenza di fughe VPN — ultimo test GG/MM/AAAA"
• In caso di fuga rilevata e corretta: annota la fuga, la causa, la correzione applicata e la data del nuovo test

Questa documentazione viene richiesta in caso di audit normativo. Consulta la nostra guida completa al GDPR per freelance per il contesto legale.

Cosa tenere a mente

Testare una VPN nel 2026 non è più una singola verifica DNS — è una metodologia unificata a 5 dimensioni (DNS, WebRTC, IPv6, MTU, kill switch) che richiede ~30 minuti e rivela fughe silenziose nel 38% delle configurazioni testate. Strumenti open source disponibili: dns-leak-detector-cli e webrtc-leak-detector, con comandi shell complementari per IPv6, MTU e kill switch. Test trimestrale obbligatorio o a ogni cambio di contesto (nuovo ISP, aggiornamento OS, nuovo client VPN). Per l'articolo 32 del GDPR, documenta ogni verifica con uno screenshot datato — prova di diligenza ragionevole in caso di audit.

Disclosure: Eric Gerard mantiene gli strumenti open source dns-leak-detector-cli e webrtc-leak-detector citati in questo articolo. Nessuna monetizzazione diretta degli strumenti — solo link affiliati NordVPN nel contenuto editoriale. Fonti tecniche: RFC 4787 NAT behavior, RFC 5245 ICE, WireGuard whitepaper, W3C WebRTC specification.