Pular para o conteúdo
iseeu.cc

Teste de vazamento WebRTC

Descubra se o seu navegador revela, pelo WebRTC, um endereço IP que a sua VPN ou proxy deveria esconder. O teste roda no seu navegador e costuma terminar em poucos segundos (espera no máximo oito).

Resultado

Testando… perguntando a um servidor STUN qual endereço ele vê

    Endereços comparados

    Sua conexão (HTTP)
    IP público via WebRTC
    Servidor STUN usado

    Candidatos ICE gerados pelo seu navegador

    TipoEndereçoCategoriaProtocolo

    Resposta curta

    Vazamento de WebRTC é quando qualquer página consegue ler pelo WebRTC um endereço IP público diferente do que a sua conexão usa — por exemplo, o seu endereço real com a VPN ligada — sem nenhum pedido de permissão. Este teste faz uma requisição STUN a stun.cloudflare.com:3478, espera até 8 segundos e compara cada endereço público que volta com o endereço que o servidor vê; a RFC 8828 descreve o que os navegadores devem e não devem revelar desse jeito.

    Como é obtido

    A página cria uma RTCPeerConnection com um servidor STUN e um canal de dados, o que faz o navegador reunir candidatos ICE (RFC 8445). Os candidatos host trazem endereços locais, que os navegadores atuais em geral substituem por um nome .local aleatório; os candidatos server-reflexive (srflx) trazem o endereço público que o servidor STUN viu (RFC 8489). Cada endereço público é comparado com o endereço da sua requisição HTTP; dois endereços IPv6 contam como a mesma rede quando os primeiros 64 bits são iguais.

    Exemplo prático

    Um usuário de VPN se conecta por 198.51.100.7, e a resposta STUN traz 203.0.113.25. Os dois são IPv4 e são diferentes, então o resultado é Vazamento: o WebRTC revela outro IP público: 203.0.113.25 provavelmente é o endereço que a VPN deveria esconder. Se a resposta tivesse sido 198.51.100.7, o resultado seria sem vazamento; se tivesse sido um endereço IPv6 em uma conexão que chegou por IPv4, a página informa que o WebRTC também revela o seu endereço IPv6, o que é esperado em uma conexão dual stack sem VPN. (Os dois endereços são de documentação, da RFC 5737.)

    Limites

    • O teste vale só para este navegador e este perfil; outros navegadores no mesmo aparelho podem se comportar de outro jeito.
    • Se o UDP para a porta do STUN estiver bloqueado ou a rede estiver lenta, o resultado aparece como inconclusivo, e não como seguro.
    • Ele não testa vazamento de DNS nem o tráfego de outros aplicativos.

    Fontes

    Fontes conferidas em . Página atualizada em .

    O que é um vazamento de WebRTC

    WebRTC é a tecnologia do navegador por trás de chamadas de vídeo, compartilhamento de tela e transferência de arquivos ponto a ponto em sites como Google Meet e Discord. Para ligar duas pessoas diretamente, o navegador precisa descobrir todos os endereços pelos quais pode ser alcançado. Ele faz isso mandando uma requisição minúscula a um servidor STUN, que responde com o endereço público de onde viu a requisição sair. Depois, o navegador entrega esses endereços — chamados candidatos ICE — ao JavaScript da página.

    Isso é útil para chamadas e um problema para a privacidade. Qualquer página pode iniciar esse processo em silêncio, sem pedido de permissão e sem câmera nem microfone. Se a requisição STUN sair do seu computador por fora do túnel da VPN, a página descobre o endereço que o seu provedor de internet deu a você, e não o que a VPN mostra. Isso é um vazamento de WebRTC: o site vê dois endereços, e um deles é justamente o que você queria esconder.

    Como usar

    1. Conecte a VPN ou o proxy do jeito que você costuma navegar e abra esta página.
    2. Espere o quadro de resultado no topo. O teste começa sozinho, e a linha Testando dá lugar a um veredito de uma linha com uma explicação curta.
    3. Em Endereços comparados, compare Sua conexão (HTTP) com IP público via WebRTC. A linha Servidor STUN usado mostra qual servidor respondeu ao seu navegador.
    4. Confira a tabela de candidatos ICE. Tipo diz de onde veio cada candidato (host é o seu aparelho, srflx é o que o servidor STUN viu, relay é um servidor TURN), e Categoria diz se o endereço é público, da sua rede local, atrás do NAT da operadora ou escondido atrás de um nome .local.
    5. Depois de mudar uma configuração ou uma extensão do navegador, clique em Rodar o teste de novo. Se você ligou ou desligou a própria VPN, recarregue a página: o endereço HTTP é lido uma vez só, quando a página carrega.

    Rode o teste uma vez com a VPN desligada e anote o endereço que o seu provedor dá. Esse é o endereço que nunca deve aparecer com o túnel ligado.

    Para que serve

    • Avaliar uma VPN antes de confiar nela. Com o túnel ligado, o endereço público do WebRTC deve ser igual ao do HTTP ou nem aparecer. Um endereço diferente da mesma família é o resultado que pede ação.
    • Verificar uma extensão de proxy. As extensões de proxy do navegador encaminham as requisições normais das páginas, mas a requisição STUN usa UDP e pode sair direto pelo seu provedor, a não ser que o navegador seja instruído a bloqueá-la.
    • Achar uma brecha no IPv6. Algumas configurações de VPN passam o IPv4 pelo túnel e deixam o IPv6 de fora. O veredito então diz que o WebRTC também revela o seu endereço IPv6.
    • Conferir a política de um navegador gerenciado. A equipe de TI que restringe o WebRTC nos notebooks da empresa pode abrir a página em uma máquina de teste e confirmar que a tabela de candidatos só mostra o que a política deveria permitir.
    • Depurar um app WebRTC em uma rede restrita. Se a tabela lista candidatos host, mas nenhum srflx, o UDP para o servidor STUN na porta 3478 provavelmente está bloqueado, e as chamadas nessa rede vão precisar de um relay TURN.

    Como este teste funciona

    1. O seu navegador carrega esta página pela sua conexão normal, então o nosso servidor vê um endereço público — mostrado acima como Sua conexão (HTTP).
    2. A página cria uma conexão WebRTC que nunca liga para ninguém e pergunta ao servidor STUN público da Cloudflare (stun.cloudflare.com) qual endereço ele vê.
    3. Listamos todos os candidatos que o seu navegador gerou e comparamos os públicos com o endereço HTTP. Tudo isso acontece no seu navegador; nada é enviado de volta para nós.

    Como ler o resultado

    • Sem vazamento: o WebRTC informa o mesmo endereço público da sua conexão, ou nenhum. Se você usa VPN, ela está cobrindo o WebRTC.
    • Vazamento: o WebRTC informa um endereço público diferente, do mesmo tipo (IPv4 com IPv4). Com a VPN ligada, esse segundo endereço quase sempre é o seu endereço real.
    • Outro protocolo exposto: você se conectou por IPv6 e o WebRTC também mostra um endereço IPv4, ou o contrário. Em uma conexão residencial comum, os dois são seus. Com uma VPN que só passa um protocolo pelo túnel, o outro vaza.
    • Endereço local visível: um endereço 192.168.x.x ou 10.x.x.x significa que o navegador está compartilhando o endereço do seu aparelho na rede de casa. As versões atuais do Chrome, Edge, Firefox e Safari o escondem por padrão atrás de um nome .local aleatório.

    Como resolver um vazamento de WebRTC

    • Use o aplicativo da VPN, não só a extensão do navegador. Uma VPN no sistema todo passa o tráfego STUN pelo túnel; uma extensão de proxy muitas vezes não.
    • Ative a proteção contra vazamento de WebRTC no aplicativo ou na extensão da VPN, se houver.
    • Firefox: abra about:config e defina media.peerconnection.enabled como false para desligar o WebRTC por completo, ou deixe-o ligado e confie na VPN.
    • Chrome e Edge: não há uma opção nativa; use uma extensão confiável que defina a política de IP do WebRTC como “disable non-proxied UDP” (desativar UDP sem proxy).
    • Brave: Configurações → Privacidade e segurança → Política de manuseio de IP do WebRTC → “Desativar UDP não proxy”.
    • Safari: vazamentos são raros, porque o Safari restringe os candidatos ICE por padrão.

    Depois de qualquer mudança, rode o teste de novo. Lembre que desligar o WebRTC quebra as chamadas pelo navegador, então prefira corrigir a VPN a desativar o recurso.

    O que este teste não consegue dizer

    Um resultado limpo vale só para o WebRTC. As suas requisições DNS, o fuso horário e o idioma do navegador e a sua impressão digital são canais separados; a página inicial verifica a diferença de fuso horário e de idioma, e o teste de impressão digital cobre o resto. Não fazemos teste de vazamento de DNS, porque isso exige um servidor DNS dedicado, e preferimos não fingir.

    Perguntas frequentes

    O que é vazamento de WebRTC?

    É quando um site usa o recurso de comunicação em tempo real do navegador para descobrir um endereço IP que a sua VPN ou proxy deveria esconder. A página pergunta a um servidor STUN qual endereço ele vê, e o navegador entrega a resposta ao JavaScript da página.

    Vazamento de WebRTC quer dizer que minha VPN não funciona?

    Não necessariamente. A maioria dos bons aplicativos de VPN passa o tráfego do WebRTC pelo túnel. Um vazamento costuma significar que a VPN cobre só parte do seu tráfego, como um proxy em extensão do navegador, ou que ela passa o IPv4 pelo túnel, mas não o IPv6.

    Devo desativar o WebRTC?

    Só se você não faz chamadas pelo navegador. Chamadas de vídeo no Google Meet, no Discord, no Teams e em sites parecidos precisam do WebRTC. Um primeiro passo melhor é a proteção contra WebRTC da própria VPN ou uma configuração do navegador que limite quais endereços o WebRTC pode compartilhar.

    Por que o teste mostra um endereço .local?

    Os navegadores modernos trocam o endereço do seu aparelho na rede local por um nome aleatório terminado em .local, gerado com mDNS. Isso é uma proteção de privacidade, não um vazamento.

    Este teste guarda o meu IP?

    Não. A comparação roda no seu navegador. A única requisição ao nosso servidor busca o IP que ele vê, e ela não é registrada.

    Por que o teste não encontrou nenhum IP público?

    Um firewall, uma configuração do navegador, uma extensão ou a sua VPN bloqueou a requisição STUN. Para a privacidade no WebRTC, esse é o melhor resultado possível.

    Este teste verifica um único canal de vazamento no momento em que você o roda. Os resultados dependem do navegador, das extensões e da rede, e podem mudar quando qualquer um deles mudar. Não é uma auditoria de segurança da sua VPN.