O que é um vazamento de WebRTC
O WebRTC é a capacidade de comunicação em tempo real embutida no navegador, usada em videoconferências, chamadas de voz, transferência de arquivos P2P e cenários parecidos. Para estabelecer uma conexão peer-to-peer, o navegador descobre o próprio endereço público por meio de um servidor STUN. Essa sondagem normalmente usa UDP, e proxies HTTP / SOCKS comuns nem sempre interceptam o UDP.
Se a requisição STUN contornar o proxy e sair direto da rede local, um script da web pode obter o seu IP público real. Esse processo geralmente não exige permissão de câmera ou microfone e não exibe nenhum aviso de confirmação extra, e é por isso que costuma ser usado para checar se um proxy realmente cobre o tráfego de comunicação em tempo real.
Como esta ferramenta detecta
A página tenta sondagens WebRTC em vários servidores STUN, coleta os endereços públicos retornados e os compara com o IP de saída HTTP. Se o endereço retornado for igual ao da saída atual, o caminho UDP provavelmente passa pelo proxy; se retornar um endereço da operadora local, vale investigar.
- Verificar se o UDP passa pela saída do proxy
- Detectar se IPv4 / IPv6 vazam cada um de forma independente
- Observar se destinos STUN diferentes caem em regras de roteamento diferentes
O papel do STUN e do UDP
O UDP é um protocolo de transporte sem conexão, muito usado em voz, vídeo, jogos e comunicação em tempo real. O trabalho do STUN é simples: você envia um pacote UDP ao servidor e ele informa o IP de origem que viu. O WebRTC depende desse resultado para negociar a conexão, então o endereço visto pelo STUN é a principal evidência para julgar um vazamento.
Como interpretar os resultados
Nenhum vazamento detectadoO IP público retornado pelo WebRTC é igual à saída atual do seu proxy (no IPv6, o mesmo /64). Se nenhum IP público voltar, o teste simplesmente não obteve resposta; isso não prova que você está seguro.
Suspeita de vazamentoO WebRTC retornou um IP público diferente, e a localização, a operadora ou o ASN apontam para a sua rede local real.
Divisão de tráfego normalVários servidores STUN retornaram saídas de proxy diferentes, mas essas saídas correspondem ao roteamento ou às regras que você configurou.
O que fazer ao encontrar um vazamento
- Mude o seu cliente de proxy para o modo TUN, para que o UDP do WebRTC também passe pela saída do proxy.
- Chrome / Edge: defina a política corporativa <code>WebRtcIPHandling</code> = <code>disable_non_proxied_udp</code>; Firefox: ative <code>media.peerconnection.ice.proxy_only_if_behind_proxy</code> em <code>about:config</code>. Não remova o WebRTC por completo, porque um navegador sem WebRTC já é identificável por si só.
- Brave: defina a política de tratamento de IP do WebRTC como “Disable non-proxied UDP”.
- Se você precisa de conferências ou chamadas de voz, primeiro corrija as regras de roteamento de UDP / STUN no seu cliente de proxy.
Vários IPs de saída não significam necessariamente um vazamento
Se você configurou divisão de tráfego, servidores STUN diferentes podem passar por nós diferentes — por exemplo, o STUN do Google por uma saída nos EUA e o STUN da Cloudflare por uma saída em Hong Kong. Isso não é necessariamente perigoso; o que importa é se bate com o desenho das suas regras. O que você realmente precisa vigiar é quando todos os endereços WebRTC apontam para o seu local físico ou para a sua operadora local.
Vazamentos de DNS importam tanto quanto
Um vazamento de WebRTC expõe “o seu IP real”; um vazamento de DNS expõe “quais domínios você consultou”. Se as requisições DNS não passam pelo proxy, a operadora local ou o resolvedor upstream ainda conseguem ver quais sites você visitou.
A detecção de vazamento de DNS desta página usa uma sondagem real: o CleanIP.io mantém um NS autoritativo em Utah, EUA (ns1) e outro em Los Angeles, EUA (ns2), atendendo a zona dp.cleanip.io. Cada teste resolve 8 subdomínios independentes <uuid>.dp.cleanip.io; essas consultas passam pelo stub resolver do seu sistema → resolvedor recursivo do provedor / da VPN / público e chegam, por fim, ao nosso NS autoritativo, que registra o IP do resolvedor que consultou e (se houver) o EDNS Client Subnet, e devolve tudo a você para comparação.
Observe dois sinais: ① sub-rede ECS — se o resolvedor recursivo repassou a sub-rede do seu cliente (comum no Google 8.8.8.8), essa sub-rede é prova definitiva da identidade do seu cliente; ② país do resolvedor — o anycast entre países dos resolvedores recursivos públicos (1.1.1.1 / 8.8.8.8) é normal; o que importa é se, quando você acha que a VPN está ligada, a localização do resolvedor coincide com o país da sua saída HTTP.
Por que o modo proxy e o modo TUN dão resultados diferentes
Proxies HTTP / SOCKS costumam tratar apenas TCP, então o UDP de que o STUN precisa pode não ser enviado, e a página pode mostrar “sem vazamento”. Isso não significa que o UDP foi encaminhado com segurança pelo proxy — apenas que o UDP nunca chegou ao servidor STUN. O modo TUN intercepta TCP e UDP no adaptador de rede virtual, então reflete melhor o caminho real de saída do UDP.
ModoSTUN UDPSignificado
Proxy HTTP / SOCKSPode não ser enviado“Sem vazamento” pode significar apenas que o UDP foi bloqueado
TUN / adaptador virtualPode ser enviado de verdadeMais indicado para verificar a saída do UDP e as regras de roteamento