Cos'è una perdita WebRTC
WebRTC è una funzionalità di comunicazione in tempo reale integrata nel browser, usata per videoconferenze, chiamate vocali, trasferimento di file P2P e scenari simili. Per stabilire una connessione peer-to-peer, il browser scopre il proprio indirizzo pubblico tramite un server STUN. Questa sonda usa di solito UDP, e i normali proxy HTTP / SOCKS non intercettano necessariamente UDP.
Se la richiesta STUN aggira il proxy e parte direttamente dalla rete locale, uno script della pagina può ottenere il tuo IP pubblico reale. Di solito questo processo non richiede l'autorizzazione per fotocamera o microfono e non mostra alcuna richiesta di conferma aggiuntiva: per questo viene usato spesso per verificare se un proxy copre davvero il traffico di comunicazione in tempo reale.
Come lo rileva questo strumento
La pagina tenta sonde WebRTC verso più server STUN, raccoglie gli indirizzi pubblici restituiti e li confronta con l'IP di uscita HTTP. Se l'indirizzo restituito coincide con l'uscita attuale, il percorso UDP è probabilmente gestito dal proxy; se restituisce un indirizzo dell'operatore locale, vale la pena approfondire.
- Verificare se UDP passa dall'uscita del proxy
- Rilevare se IPv4 / IPv6 hanno perdite indipendenti
- Osservare se destinazioni STUN diverse corrispondono a regole di routing diverse
Il ruolo di STUN e UDP
UDP è un protocollo di trasporto senza connessione, usato comunemente per voce, video, giochi e comunicazione in tempo reale. Il compito di STUN è semplice: invii un pacchetto UDP al server e il server ti dice l'IP di origine che ha visto. WebRTC si basa su questo risultato per negoziare una connessione, quindi l'indirizzo visto da STUN è la prova chiave per valutare una perdita.
Come interpretare i risultati
Nessuna perdita rilevataL'IP pubblico restituito da WebRTC coincide con l'uscita attuale del proxy (per IPv6, lo stesso /64). Se non torna alcun IP pubblico, il test semplicemente non ha ricevuto risposta: non è una prova di sicurezza.
Perdita sospettaWebRTC ha restituito un IP pubblico diverso, e la sua posizione, l'operatore o l'ASN indicano la tua vera rete locale.
Instradamento normalePiù server STUN hanno restituito uscite proxy diverse, ma queste uscite corrispondono al routing o alle regole che hai configurato.
Cosa fare dopo aver trovato una perdita
- Passa il client proxy alla modalità TUN, così anche l'UDP di WebRTC esce dal proxy.
- Chrome / Edge: imposta il criterio aziendale <code>WebRtcIPHandling</code> = <code>disable_non_proxied_udp</code>; Firefox: attiva <code>media.peerconnection.ice.proxy_only_if_behind_proxy</code> in <code>about:config</code>. Non rimuovere del tutto WebRTC, perché un browser senza WebRTC è di per sé identificabile.
- Brave: imposta il criterio di gestione IP di WebRTC su «Disable non-proxied UDP».
- Quando ti servono videoconferenze o chiamate vocali, correggi prima le regole di routing UDP / STUN nel client proxy.
Più IP di uscita non sono necessariamente una perdita
Se hai configurato l'instradamento basato su regole, server STUN diversi possono passare da nodi diversi: ad esempio, lo STUN di Google tramite un'uscita negli Stati Uniti e lo STUN di Cloudflare tramite un'uscita a Hong Kong. Non è necessariamente pericoloso; conta se corrisponde alle regole che hai progettato. Ciò a cui devi davvero fare attenzione è quando tutti gli indirizzi WebRTC indicano la tua posizione fisica o il tuo ISP locale.
Le perdite DNS contano altrettanto
Una perdita WebRTC espone «il tuo IP reale»; una perdita DNS espone «quali domini hai interrogato». Se le richieste DNS non passano dal proxy, l'operatore locale o il resolver upstream possono comunque vedere quali siti hai visitato.
Il rilevamento delle perdite DNS di questa pagina usa una sonda reale: CleanIP.io gestisce un NS autoritativo nello Utah, Stati Uniti (ns1) e uno a Los Angeles, Stati Uniti (ns2), che servono la zona dp.cleanip.io. Ogni rilevamento risolve 8 sottodomini indipendenti <uuid>.dp.cleanip.io; queste query passano dallo stub resolver del tuo sistema -> resolver ricorsivo dell'ISP / della VPN / pubblico, e arrivano infine al nostro NS autoritativo, che registra l'IP del resolver che ha fatto la query e (se presente) l'EDNS Client Subnet, poi te li restituisce per il confronto.
Concentrati su due segnali: ① sottorete ECS: se il resolver ricorsivo ha inoltrato la sottorete del tuo client (comune con Google 8.8.8.8), quella sottorete è la prova definitiva dell'identità del client; ② paese del resolver: l'anycast transfrontaliero dei resolver ricorsivi pubblici (1.1.1.1 / 8.8.8.8) è normale; ciò che conta è se, quando pensi che la VPN sia attiva, la posizione del resolver corrisponde al paese dell'uscita HTTP.
Perché la modalità proxy e la modalità TUN danno risultati diversi
I proxy HTTP / SOCKS di solito gestiscono solo TCP, quindi l'UDP necessario a STUN potrebbe non partire e la pagina potrebbe mostrare «nessuna perdita». Questo non significa che UDP sia passato in modo sicuro dal proxy: significa solo che UDP non ha mai raggiunto il server STUN. La modalità TUN intercetta sia TCP sia UDP sulla scheda di rete virtuale, quindi riflette meglio il percorso di uscita UDP reale.
ModalitàSTUN UDPSignificato del risultato
Proxy HTTP / SOCKSPotrebbe non partire«Nessuna perdita» può significare solo che UDP è stato bloccato
TUN / scheda virtualeParte davveroPiù adatta a verificare l'uscita UDP e le regole di routing