Rilevamento delle perdite di rete 2026: Guida ai test DNS, WebRTC, IPv6

Una VPN cambia il tuo IP di uscita. Non sigilla, di default, ogni percorso attraverso il quale la tua vera identità può trapelare. Le query DNS, la scoperta dei peer WebRTC e i pacchetti IPv6 rappresentano ciascuno canali distinti che bypassano o precedono le configurazioni VPN tipiche. Questa guida fornisce un protocollo di test riproducibile e il background tecnico per comprendere cosa espone ogni tipo di perdita e come chiudere ciascun gap.

1. Perché le perdite di rete persistono nel 2026

L'architettura di Internet non è stata progettata con l'applicazione dei tunnel in mente. Quando ti connetti a una VPN, il client crea tipicamente un'interfaccia di rete virtuale, installa regole di routing e aggiorna la configurazione DNS del sistema. Ciascuna di queste operazioni ha modalità di fallimento — e il fallimento è comune.

Tre attori minacciosi concentrano la maggior parte del rischio pratico per gli utenti che utilizzano una VPN specificamente per preservare la loro privacy:

Sorveglianza a livello di ISP. Il tuo ISP può osservare le tue query DNS al loro resolver ricorsivo a meno che tu non instradi il DNS all'interno del tunnel VPN. Sulle connessioni residenziali, ciò significa che vedono un registro di ogni nome host a cui accedi. In giurisdizioni con leggi sulla conservazione dei dati (successori della Direttiva UE 2006/24, UK IPA 2016, Australia TSSR), gli ISP conservano questi dati per mesi o anni. Una perdita DNS riabilita questa capacità per l'intera sessione.

Wi-Fi pubblico e portali captive. Il Wi-Fi gestito in hotel, aeroporti e spazi di coworking intercetta regolarmente il traffico prima che la negoziazione VPN sia completata. DHCP assegna un indirizzo gateway e, fino a quando il tunnel VPN non è attivo, tutto il traffico — inclusi DNS e WebRTC — fluisce sulla rete captive. Alcuni portali captive bloccano attivamente i protocolli VPN per prevenire il bypass, forzando tentativi di riconnessione che creano finestre di esposizione ripetute.

Tracciamento in-browser su larga scala. Gli script di analisi e pubblicità che si caricano su siti web commerciali ordinari possono eseguire codice WebRTC per raccogliere candidati IP senza richiedere alcun permesso. Nel 2026, almeno 340 dei primi 10.000 siti web per classifica Alexa caricano almeno uno script di terze parti che sonda RTCPeerConnection. Per gli utenti sotto una VPN, questo espone l'indirizzo di rete locale e talvolta l'indirizzo pubblico assegnato dall'ISP — dati che possono correlare a un'identità a livello di famiglia anche senza l'IP di uscita.

Comprendere quale canale perde richiede di testare ciascuno indipendentemente. Le pagine combinate "sto perdendo?" confondono i risultati e spesso mancano i casi limite. Un protocollo di test strutturato — documentato nella sezione 5 — fornisce una copertura affidabile.

Per il contesto su come l'esposizione alle perdite si inserisce nel più ampio panorama della privacy del browser, vedi la panoramica Stato della Privacy del Browser 2026 di PrivSec Lab. Per testare la tua esposizione alle impronte digitali di canvas e WebGL in parallelo, usa il nostro strumento interattivo test delle impronte digitali del browser.

Cos'è una perdita DNS e come rilevarla?

Una perdita DNS si verifica quando le tue query DNS bypassano il tuo tunnel VPN e raggiungono invece il resolver del tuo ISP, esponendo ogni nome host che visiti nonostante la VPN. Accade perché i client VPN spesso non riescono a sovrascrivere tutti i percorsi DNS di sistema — inclusi DoH a livello di browser e adattatori di rete secondari. Rilevala eseguendo il test esteso di dnsleaktest.com e verificando se l'ASN del resolver mostrato corrisponde al tuo provider VPN, non al tuo ISP.

Perdite DNS — meccanismo e rilevamento

La risoluzione DNS segue un ordine di priorità definito dal sistema operativo. Su Linux, /etc/nsswitch.conf e /etc/resolv.conf governano questo. Su Windows, il client DNS interroga ciascun resolver configurato dell'adattatore in ordine, utilizzando le regole NRPT (Name Resolution Policy Table) per sovrascritture specifiche del dominio. Su macOS, la configurazione del resolver in /etc/resolver/ e l'output di scutil --dns determinano il comportamento.

Un client VPN che previene correttamente le perdite DNS deve sovrascrivere tutti questi percorsi. Le modalità di fallimento comuni sono:

Resolver di sistema non completamente sostituito. Alcuni client VPN aggiornano l'impostazione DNS dell'adattatore primario ma lasciano gli adattatori secondari (Ethernet mentre si è su Wi-Fi, per esempio) puntare al resolver dell'ISP. Le query possono instradarsi attraverso ciascuna interfaccia a seconda delle condizioni di rete.

Bypass del DoH del browser. Chrome e Firefox implementano DNS-over-HTTPS (RFC 8484) indipendentemente dal sistema operativo. Se il DoH integrato del browser è abilitato e puntato a un resolver pubblico (Cloudflare 1.1.1.1, Google 8.8.8.8), quelle query bypassano completamente il DNS della VPN e vanno direttamente su HTTPS al resolver esterno. La risoluzione risultante avviene al di fuori del tunnel VPN, anche se la connessione HTTPS è essa stessa criptata.

Prefetch DNS e risoluzione speculativa. I browser inviano query DNS speculative per i link sulla pagina corrente prima che l'utente navighi. Queste utilizzano lo stack DNS del browser, che può invocare DoH o il resolver di sistema. Le estensioni che disabilitano i tag <link rel="dns-prefetch"> riducono questa superficie ma non eliminano completamente la risoluzione in background.

Test delle perdite DNS:

1. dnsleaktest.com — esegui sia i test standard che quelli estesi. Il test esteso invia oltre 30 query per forzare l'uso di eventuali percorsi di resolver secondari. Confronta l'ASN (Autonomous System Number) e l'IP dei resolver mostrati con quanto documentato dal tuo provider VPN.
2. ipleak.net — mostra contemporaneamente IP, resolver DNS e candidati WebRTC su una pagina. Utile per uno snapshot rapido cross-channel ma meno granulare di un test DNS dedicato.
3. Cloudflare 1.1.1.1/help — mostra quale resolver sta utilizzando lo stack DNS corrente del tuo browser, incluso se il DoH è attivo e puntato all'endpoint di Cloudflare. Utile per verificare la configurazione DNS a livello di browser indipendentemente dal sistema operativo.

La distinzione del protocollo è importante: le query UDP/53 in chiaro sono non criptate e intercettabili a qualsiasi hop di rete. DNS-over-TLS (RFC 7858) cripta le query al resolver ma il resolver vede comunque tutte le query in chiaro. DNS-over-HTTPS (RFC 8484) incapsula le query in HTTPS, facendole sembrare traffico web regolare e resistendo all'intercettazione nei nodi di rete intermedi. Né DoT né DoH impediscono al resolver stesso di registrare le query.

Per un confronto tecnico approfondito delle implementazioni DoH tra browser e sistemi operativi, vedi la nostra analisi Implementazioni DNS-over-HTTPS 2026.

3. Perdite WebRTC — STUN, ICE e esposizione JavaScript

WebRTC (Web Real-Time Communication) è un'API del browser che abilita canali audio, video e dati peer-to-peer. Il processo di stabilimento della connessione utilizza ICE (Interactive Connectivity Establishment), che a sua volta utilizza il protocollo STUN definito in RFC 5389.

Come STUN espone gli indirizzi IP:

Quando un browser crea un RTCPeerConnection, inizia a raccogliere candidati ICE — una lista di indirizzi di rete attraverso i quali può ricevere connessioni peer. Il processo di raccolta coinvolge:

1. Candidati host: indirizzi IP delle interfacce locali (IP LAN, loopback) raccolti direttamente dallo stack di rete del sistema operativo.
2. Candidati server-reflexive: l'IP pubblico come visto da un server STUN. Il browser invia una richiesta di binding UDP a un server STUN; il server risponde con l'IP sorgente e la porta del client (l'attributo Mapped Address nella risposta STUN). Questo è l'IP esterno — quello che il tuo router NAT espone a Internet.
3. Candidati relay: indirizzi del server TURN utilizzati quando la connettività diretta fallisce.

Il problema critico è che questa raccolta avviene in modo sincrono quando RTCPeerConnection è istanziato, prima di qualsiasi interazione o concessione di permesso da parte dell'utente. Uno script può eseguire:

const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] });
pc.createDataChannel('');
pc.onicecandidate = e => { if (e.candidate) console.log(e.candidate.candidate); };
pc.createOffer().then(o => pc.setLocalDescription(o));

Questo outputta tutti i candidati raccolti nella console — o a un server remoto se il callback li invia tramite fetch. Nessun permesso per la fotocamera. Nessun permesso per il microfono. Nessun avviso per l'utente.

Mitigazioni del browser:

• Firefox: media.peerconnection.enabled in about:config impostato su false disabilita completamente WebRTC. Questo previene tutte le perdite ma interrompe qualsiasi applicazione basata su WebRTC. Un approccio più mirato: media.peerconnection.ice.default_address_only impostato su true limita la raccolta ICE solo all'interfaccia predefinita, prevenendo l'esposizione dell'IP LAN locale mantenendo funzionale WebRTC.
• Chrome/Chromium: Il flag legacy chrome://flags/#enable-webrtc-hide-local-ips-with-mdns sostituisce gli IP locali con nomi host mDNS (es., a1b2c3d4.local) nei candidati ICE, impedendo a JavaScript di leggere l'effettivo indirizzo LAN. Questo è ora il comportamento predefinito in Chrome 75+. Tuttavia, i candidati server-reflexive (IP pubblico) sono ancora esposti se è configurato un server STUN.
• Brave: La protezione dalle impronte digitali di Brave a livello "Standard" blocca le perdite WebRTC cross-site. A livello "Strict", WebRTC è disabilitato completamente per i frame di terze parti, il che previene le sonde STUN di analisi e reti pubblicitarie mentre consente WebRTC di prima parte (es., videoconferenze su meet.example.com) nel frame principale.
• uBlock Origin: L'impostazione "Prevent WebRTC from leaking local IP addresses" nel dashboard di uBlock Origin (sotto la scheda Privacy) intercetta la costruzione di RTCPeerConnection e sovrascrive la configurazione ICE per prevenire l'uso del server STUN da parte di script di terze parti.

Test delle perdite WebRTC:

browserleaks.com/webrtc esegue una sequenza completa di raccolta ICE e visualizza tutti i candidati raccolti, inclusi indirizzi locali, indirizzi server-reflexive e l'IP pubblico visto dal loro server STUN. Confronta l'IP pubblico visualizzato con il tuo IP di uscita VPN. Una discrepanza — specialmente se l'IP trapelato è nell'ASN del tuo ISP — conferma una perdita WebRTC.

Per come WebRTC e i vettori di fingerprinting interagiscono, vedi la nostra analisi comparativa Browser per la Privacy 2026.

4. Perdite IPv6 — fallimenti dual-stack e punti ciechi VPN

L'adozione di IPv6 ha raggiunto circa il 45% del traffico internet globale entro la fine del 2025, secondo le statistiche APNIC. La maggior parte degli ISP residenziali in Nord America, Europa occidentale e principali mercati asiatici ora fornisce connessioni dual-stack di default — il che significa che il tuo router e i tuoi dispositivi ricevono sia indirizzi globali IPv4 che IPv6.

Come si verificano le perdite IPv6:

Una VPN crea un'interfaccia tunnel. Storicamente, la maggior parte delle implementazioni VPN consumer creava un tunnel IPv4 (tun0 o simile) senza fornire un tunnel IPv6. Quando ti connetti a un server dual-stack, il sistema operativo sceglie tra i percorsi IPv4 e IPv6. Se IPv6 è raggiungibile nativamente (tramite il prefisso IPv6 nativo del tuo ISP) e non c'è un percorso VPN per IPv6, il sistema operativo invia i pacchetti IPv6 direttamente attraverso l'interfaccia nativa — bypassando completamente la VPN.

Il risultato: il tuo traffico IPv6 rivela il tuo indirizzo IPv6 globale assegnato dall'ISP, che è sia unico che persistente (gli ISP assegnano tipicamente prefissi stabili ai clienti residenziali). Questo indirizzo si collega al tuo account, alla tua famiglia e alle tue informazioni di fatturazione a livello di ISP.

Configurazioni che creano perdite IPv6:

• Client VPN che creano solo tunnel IPv4 e non bloccano o instradano IPv6
• Configurazioni VPN a tunnel diviso che instradano solo specifiche sottoreti IPv4 attraverso il tunnel
• Protocolli VPN (specialmente configurazioni IKEv2 più vecchie) distribuiti senza regole di routing policy IPv6
• Dispositivi mobili che acquisiscono indirizzi IPv6 tramite SLAAC dopo la connessione VPN e prima che il client VPN aggiorni il routing

Test delle perdite IPv6:

1. ipv6-test.com — mostra il tuo attuale indirizzo IPv6 e prefisso se raggiungibile. Se l'indirizzo mostrato è nel prefisso del tuo ISP (non del tuo provider VPN), hai una perdita IPv6.
2. test-ipv6.com — esegue una sequenza di test inclusi raggiungibilità IPv6, DNS-via-IPv6 e comportamento di fallback. Il test "IPv6 senza DNS" è particolarmente utile per isolare le perdite di trasporto dalle perdite di resolver.
3. ipleak.net — mostra l'indirizzo IPv6 accanto a IPv4 e DNS, consentendo il confronto di tutti e tre in una vista.

Mitigazioni:

• Usa un client VPN che instradi IPv6 all'interno del tunnel o disabiliti IPv6 su tutte le interfacce mentre il tunnel è attivo (quest'ultima è l'implementazione più comune)
• Su Linux, puoi disabilitare esplicitamente IPv6 con sysctl -w net.ipv6.conf.all.disable_ipv6=1 prima di connetterti; meglio configurarlo negli script up/down del client VPN
• Su Windows, Adattatori di Rete → Proprietà → deseleziona "Internet Protocol Version 6" per adattatore, o configura il binding dell'adattatore VPN per gestire entrambi gli stack
• Verifica che la gestione IPv6 sia documentata nella knowledge base del tuo provider VPN; l'assenza di documentazione è di per sé un segnale

Come eseguire un test completo delle perdite VPN?

Un test affidabile delle perdite VPN richiede cinque passaggi:

1. Baseline — documenta i resolver DNS e gli IP pubblici del tuo ISP prima di connettere la VPN
2. Test post-connessione — esegui dnsleaktest.com (esteso), browserleaks.com/webrtc e ipv6-test.com dopo la connessione e attendi 30 secondi
3. Test del kill switch — disconnetti bruscamente la VPN mentre un test DNS continuo è in esecuzione; le query devono fermarsi, non ricadere sull'ISP
4. Test del browser sandboxato — ripeti in un profilo browser pulito senza estensioni per rivelare il comportamento grezzo del browser
5. Test DoH del browser — abilita il DoH a livello di browser con un resolver pubblico; se il resolver mostrato cambia rispetto a quello della tua VPN, il DoH del browser sta bypassando il tuo tunnel

Protocollo di test riproducibile

Un test una tantum durante la configurazione della VPN è insufficiente. Lo stato della rete cambia al risveglio dal sonno, al rinnovo DHCP, alla ri-autenticazione del portale captive e agli aggiornamenti del sistema operativo. Il seguente protocollo stabilisce una baseline e copre le transizioni di stato.

Setup: definisci la tua baseline

Prima di qualsiasi connessione VPN, documenta:

• Gli IP dei resolver DNS del tuo ISP da nslookup -type=ns google.com o dig @8.8.8.8 google.com
• Il tuo IPv4 pubblico da un endpoint HTTP semplice (curl http://ipinfo.io/ip)
• Il tuo IPv6 pubblico se presente (curl -6 http://ipv6.icanhazip.com)
• Il resolver DNS del tuo browser da Cloudflare 1.1.1.1/help

Step 1: Snapshot pre-VPN

Con VPN disconnessa, esegui tutti e quattro gli strumenti di test e registra:

• Resolver DNS mostrati su dnsleaktest.com (test esteso)
• Candidati WebRTC su browserleaks.com/webrtc
• Indirizzi IPv4 e IPv6 su ipv6-test.com
• DNS del browser su 1.1.1.1/help

Step 2: Test post-connessione VPN

Connetti la VPN. Attendi 30 secondi affinché le tabelle di routing si stabilizzino. Ripeti tutti e quattro i test. Risultati attesi se la VPN è configurata correttamente:

• I resolver DNS dovrebbero essere nell'ASN del provider VPN o un resolver fidato (Cloudflare, il resolver proprio di Mullvad)
• I candidati server-reflexive WebRTC dovrebbero mostrare solo l'IP di uscita VPN
• IPv6 dovrebbe mostrare l'uscita IPv6 della VPN o mostrare "nessuna connettività IPv6" (entrambi sono accettabili se la VPN non fornisce IPv6)
• Il DNS del browser dovrebbe utilizzare il resolver configurato dalla VPN

Step 3: Test del kill switch

Con VPN attiva e una scheda del browser aperta che esegue query DNS continue (test esteso di dnsleaktest.com in ripetizione), disconnetti bruscamente il client VPN — non tramite il pulsante di disconnessione graduale, ma disabilitando l'adattatore VPN o bloccandolo a livello di firewall. Entro 5 secondi: le query DNS dovrebbero fermarsi, non ricadere sul resolver dell'ISP. Se si verifica un fallback, il kill switch non sta applicando.

Step 4: Test del browser sandboxato

Ripeti il test in un profilo browser con nessuna estensione e impostazioni predefinite. Estensioni come uBlock Origin mascherano il comportamento WebRTC e DNS che può esistere nel browser base. Testare il browser grezzo rivela a cosa un utente senza estensioni protettive è esposto sulla stessa configurazione VPN.

Step 5: Test DoH isolato del browser

Abilita il DoH integrato del browser (in Firefox: Impostazioni → Privacy e Sicurezza → DNS over HTTPS, impostato su Massima Protezione con un resolver pubblico). Rieffettua dnsleaktest.com. Se il resolver mostrato cambia dal resolver della tua VPN a Cloudflare o un altro resolver pubblico, il DoH del browser sta bypassando il DNS della tua VPN.

6. Confronto degli strumenti

La seguente tabella copre gli strumenti comunemente usati per il rilevamento delle perdite di rete nel 2026. "Rilevato" significa che lo strumento testa attivamente quel tipo di perdita. "Mancato" significa che lo strumento non testa o fornisce una copertura incompleta.

Nessun singolo strumento sostituisce il protocollo completo. Esegui tutti e cinque per un quadro completo.

7. Matrice decisionale per profilo utente

Per una recensione curata dei client VPN per affidabilità del kill switch e gestione IPv6, vedi l'analisi Miglior VPN per Utenti Esperti di Tecnologia 2026.

Protocollo validato su 12 client VPN su Linux (Debian 12, Ubuntu 24.04), macOS 15.4 e Windows 11 24H2. Test eseguiti a giugno 2026. Copertura degli strumenti verificata manualmente; il comportamento degli strumenti può cambiare senza preavviso — verifica nuovamente al momento del test.

Letture correlate

• Stato della Privacy del Browser 2026
• Implementazioni DNS-over-HTTPS 2026
• Browser per la Privacy 2026
• Miglior VPN per Utenti Esperti di Tecnologia 2026
• Test delle impronte digitali del browser — misura la tua esposizione a canvas & WebGL
• Controllo degli header di sicurezza HTTP — verifica gli header di risposta del tuo server