Um proxy pode cobrir o tráfego HTTP enquanto o WebRTC troca endereços candidatos via STUN/ICE sobre UDP. Este artigo explica quando endereços locais e privados podem ser expostos e como manter consistentes a saída de rede e o ambiente do navegador.
Você configurou um proxy, e uma página de consulta de IP mostra a região e o provedor esperados. A identidade de rede parece estar correta. Mas, ao abrir um teste de vazamento, a seção de WebRTC aparece em vermelho e mostra o endereço da sua conexão real com o provedor de Internet.
Não é preciso trocar de proxy imediatamente. Na maioria dos casos, o problema não está na qualidade do proxy, e sim no tráfego que ele não controla.
O proxy cuida de HTTP, enquanto o WebRTC segue outro caminho
Um proxy atua na camada de rede. Seja como extensão do navegador ou como túnel no nível do sistema, ele processa solicitações HTTP/HTTPS e envia esse tráfego pela saída do proxy.
O WebRTC funciona de outra forma. Ele é um recurso de comunicação em tempo real integrado ao navegador. Para que chamadas de áudio/vídeo e transferências P2P encontrem um caminho adequado, o navegador pode enviar ativamente consultas STUN a servidores externos — em essência, perguntando “que endereço você vê para mim?” — e depois organizar as respostas como candidatos ICE entregues à página. Essas consultas usam UDP, um canal independente do túnel HTTP.
Surge então uma inconsistência: as solicitações da página saem pelo proxy, enquanto o navegador também pode informar um endereço local. Supor que configurar um proxy significa automaticamente deixar toda a identidade de rede limpa é o ponto de partida mais comum desse problema.
Não é apenas o IP público que pode ser exposto
Os candidatos ICE normalmente contêm dois tipos de endereço. Um é o endereço público, ou seja, a saída do seu provedor de Internet real. O outro é um endereço local, como um endereço privado começando com 192.168, e às vezes também um endereço de adaptador de rede virtual.
Um endereço de rede privada, isoladamente, diz pouco; praticamente todo computador tem um. Porém, ele pode ser estável o bastante para que candidatos repetidamente sobrepostos entre várias contas forneçam a uma plataforma mais um sinal para associá-las ao mesmo dispositivo. O endereço público é mais direto: aponta para o provedor real e uma região geográfica aproximada. O nível de precisão depende da plataforma, mas a lógica é clara: quanto mais autêntico o endereço, mais fácil a associação.
Quando um site realmente consegue ler esse endereço?
Nem todo site tenta fazer isso. A troca de endereços exige que a página crie ativamente um objeto RTCPeerConnection, algo que páginas comuns de conteúdo geralmente não precisam fazer.
Os casos mais comuns incluem sites que precisam de comunicação em tempo real, como videoconferências, atendimento online e algumas páginas de transmissão ao vivo; sites que dependem fortemente de publicidade ou prevenção a fraudes; e plataformas com sistemas de controle de risco mais completos. A leitura ocorre fora da parte visível da interface e, depois que os dados são coletados, você normalmente não recebe aviso sobre como serão usados.
Há também uma situação que não depende do site. Durante o curto intervalo em que o proxy reconecta ou troca de nó, uma solicitação STUN do navegador pode acabar saindo pela rede local. A janela é curta, mas suficiente para registrar uma observação.
Três cenários comuns de falha
Proxies em forma de extensão do navegador costumam assumir apenas solicitações HTTP/HTTPS. UDP fica fora do seu alcance, e marcar uma opção “global” na interface não muda isso.
Um proxy global no nível do sistema parece mais completo, pois cobre o tráfego do dispositivo inteiro. Porém, a coleta de endereços candidatos pode se vincular diretamente a uma interface de rede local e contornar a tabela de roteamento do sistema, deixando uma brecha no túnel nesse ponto.
O terceiro problema não é apenas técnico, mas também acompanha a evolução dos controles. Sistemas de risco vêm usando endereços WebRTC como um dos sinais para relacionar contas. Dados que antes não eram medidos ou eram ignorados podem agora entrar na avaliação.
O objetivo é uma saída coerente, não apenas desligar uma opção
Existem algumas abordagens gerais. Se um fluxo de trabalho não precisa de comunicação em tempo real, desativar o WebRTC é a alternativa mais simples, com o custo de perder também recursos como chamadas de vídeo e atendimento online.
Se esses recursos precisam continuar funcionando, uma abordagem comum é fazer com que o endereço retornado no nível do WebRTC corresponda à saída do proxy. Uma opção mais robusta é encaminhar também as solicitações STUN pelo canal do proxy, para que a interface não exponha o endereço local. Se houver necessidade de P2P ou chamadas de vídeo, todo o tráfego UDP deve passar pelo proxy, e não apenas a camada HTTP.
Um erro comum é pensar que desativar apenas o WebRTC já deixa o ambiente limpo. O importante é manter coerentes entre si a saída de rede, a resolução DNS, a propriedade do IP e o ASN, o fuso horário e o idioma, além das características do dispositivo. Qualquer incompatibilidade pode gerar um sinal anômalo; o WebRTC é apenas um dos itens mais fáceis de ignorar.
A verificação é simples. Faça um teste depois de trocar de nó e outro antes de começar o uso normal do ambiente: abra um teste de vazamento e veja se a seção WebRTC mostra a saída do proxy, um endereço local ou o endereço público real. Uma consulta comum de IP não revela esse item.
Soluções de isolamento no nível do mecanismo do navegador podem definir uma política de endereço WebRTC separada para cada ambiente e vinculá-la à saída de rede correspondente. A PurpleMark oferece esse tipo de capacidade. Se vários ambientes compartilharem a mesma saída ou se suas políticas de endereço forem inconsistentes, o valor do isolamento cai bastante.
Esta é apenas uma explicação técnica. Use as ferramentas relacionadas em conformidade com as regras das plataformas e as leis locais.
