WebRTC leaks: como seu navegador entrega seu IP real

Você conecta na sua VPN. A status bar diz que você está protegido. Carrega um site. O site silenciosamente pede pro seu navegador o endereço IP real: não o da VPN, o que seu provedor de fato atribuiu. O navegador entrega. Você não vê prompt, não vê aviso, e a VPN está fazendo exatamente o que prometeu.

Isso é WebRTC leak. O culpado é o navegador, não a VPN. E funciona em todo navegador moderno até você desabilitar.

O que é WebRTC

WebRTC (Web Real-Time Communication) é um browser API que provê voz e vídeo no navegador. Google Meet, canais de voz do Discord, huddles do Slack, Whereby, a parte in-browser do Zoom: todos usam WebRTC. Também usam transferências de arquivo diretas, screen sharing e botões de "clique pra ligar" em páginas de suporte.

Pra conexões peer-to-peer funcionarem, o navegador precisa saber seu IP público. É assim que o outro lado te alcança. WebRTC resolve isso via STUN server: o navegador pergunta pra um STUN server público "de qual endereço eu vim?". O STUN server responde com o IP que vê. O navegador cacha e entrega pra qualquer página que pergunte via WebRTC API.

A arquitetura fazia sentido em 2011, quando WebRTC foi projetado. Peer-to-peer latency-sensitive era o caso de uso. Privacidade contra sites arbitrários não estava no documento de design.

Por que VPN não conserta isso

VPN tunela seu tráfego de rede. A troca STUN do WebRTC opera em cima disso, mas a resposta que o navegador cacha é seu IP real, não o do túnel, em dois casos:

Caso 1: STUN foi consultado antes da VPN conectar. O navegador aprendeu seu IP real no startup ou numa rede anterior. Cachou. A página pede endereços IP do WebRTC e pega o valor real cachado.

Caso 2: VPN não tunela UDP pro STUN server. Em algumas configurações VPN existem edge-cases de roteamento. O pacote STUN escapa do túnel.

Mesmo com VPN devidamente tunelada, o cache STUN a nível de navegador é superfície de ataque. Páginas não precisam consultar STUN elas mesmas; só pedem ao WebRTC os endereços IP que o navegador já sabe.

Exposed vs leaking

Terminologia importa porque a reação é diferente.

Exposed. Você não está em VPN, visita uma página, a página vê seu IP real. É comportamento esperado. Não é leak, é a internet funcionando como projetada.

Leak (vazamento). Você ESTÁ em VPN, a página deveria ver só o IP da VPN, mas o WebRTC ainda entrega seu IP real. Isso é leak. A privacidade que você achou que tinha está quebrada.

O teste de WebRTC leak do Fexyn mostra em qual caso você está. Com VPN conectada, o IP público que aparecer deve ser o IP do servidor Fexyn. Se for seu IP de casa: você está vazando.

O que o atacante vê do leak

Mesma coisa que sem VPN:

Seu IP público real
Geolocalização aproximada (geralmente cidade, às vezes bairro pra provedores residenciais)
Seu provedor
Um identificador persistente que pode ser correlacionado entre visitas e entre sites

Pior que sem VPN: o leak dá a eles tanto seu IP real quanto o IP da VPN. Podem correlacionar entre sessões, construir perfil que te segue independente da VPN estar de pé ou não, e usar o próprio IP da VPN como fingerprint.

Pra modelos de ameaça onde geolocalização importa, jornalistas, ativistas, qualquer um se escondendo de stalker, qualquer um usando VPN pra evitar tracking específico de jurisdição: um WebRTC leak silenciosamente anula a proteção.

Fixes por navegador

A cura vive no navegador, não na VPN. Cada navegador trata WebRTC diferente.

Firefox: desabilitar completo

Opção mais limpa. Firefox permite desabilitar WebRTC inteiramente:

Abra uma nova aba e vá pra about:config. Aceite o aviso.
Procure media.peerconnection.enabled.
Coloque em false.
Reinicie Firefox.

Custo: chamadas de vídeo em qualquer aplicação baseada em navegador param de funcionar. Slack huddles, Google Meet, Discord voice no navegador: mortos até você ligar de volta. Pra maioria dos usuários focados em privacidade, isso é aceitável; chamadas são feitas no app desktop.

Brave: toggle embutido

Brave vem com setting orientado a privacidade:

Abra brave://settings.
Procure "WebRTC".
Coloque "WebRTC IP Handling Policy" em Disable non-proxied UDP.

Esse é o setting mais forte que não quebra WebRTC inteiramente. Chamadas funcionam; tráfego STUN é restringido pelo caminho de proxy. Pra usuários Brave em VPN: o setting certo.

Chrome e Edge: precisa extension

Nem Chrome nem Edge têm WebRTC toggle embutido na UI de settings. Precisa extension. Instale uma de:

uBlock Origin com filtro "Prevent WebRTC from leaking local IP addresses" habilitado. uBlock Origin é o ad-blocker certo de qualquer jeito; isso é bonus grátis.
WebRTC Network Limiter (publicado pela própria Google). Single-purpose, restringe WebRTC ao caminho de proxy.

Evite extensions aleatórias de "WebRTC fix" com uma estrela na Chrome Web Store. A categoria atrai extensions de baixa qualidade e às vezes maliciosas. Fique com uBlock Origin ou o do Google.

Safari

Safari implementa WebRTC mas não expõe toggle. Se está no Safari e WebRTC leaks te preocupam: migre pra Brave (Webkit-based, tem toggle) ou Firefox (Gecko-based, desabilitar completo).

Como o Fexyn lida com isso

O Fexyn não tenta monkey-patch seu navegador. Comportamento WebRTC do navegador é nível de navegador, e fora do que VPN pode ou deve sobrescrever.

O que o Fexyn faz:

Tunela todo tráfego UDP, incluindo STUN, quando o protocolo permite. WireGuard tunela tudo por padrão. Configurações VLESS Reality e OpenVPN tunelam UDP pelo mesmo caminho.
Recomenda settings específicos de navegador na página de suporte.
Provê uma ferramenta de checagem, pra você verificar combinação específica de navegador/setting.

A combinação (STUN tunelado por VPN mais WebRTC desabilitado ou restringido no lado do navegador) fecha o leak.

Re-teste depois do fix

Depois de mudar settings de navegador, reinicie o navegador e rode o teste de novo em fexyn.com/tools/webrtc-leak-test. O IP público que aparecer deve bater com o servidor Fexyn. O IP local deve estar vazio ou mostrar só o endereço do adaptador do túnel VPN.

Se ainda vê seu IP público real, a mudança não foi aplicada. Cheque que:

O navegador foi de fato reiniciado (fechar abas não basta; saia do app)
Pra Brave o setting é "Disable non-proxied UDP", não "Disable non-proxied UDP and force proxy"
Pra Chrome/Edge a extension está habilitada, não só instalada

O que WebRTC leak não é

WebRTC leaks são especificamente sobre exposição de IP via browser API. Não:

Afetam aplicações não-navegador. Um app desktop nativo em VPN não tem esse problema.
Afetam apps mobile que têm seu próprio networking. Apps iOS/Android que não embedam webview geralmente não expõem o IP da VPN via WebRTC.
Indicam que o próprio túnel VPN está quebrado. O túnel está bem; o navegador está voluntariamente entregando informação acima do nível do túnel.

Leitura relacionada

Experimente o Fexyn grátis por 7 dias. O túnel faz a parte dele; fixes de navegador são setting de uma vez.