Deteção de Fugas de Rede 2026: Guia de Testes DNS, WebRTC, IPv6

Uma VPN altera o seu IP de saída. Não sela, por defeito, todos os caminhos pelos quais a sua identidade real pode vazar. Consultas DNS, descoberta de pares WebRTC e pacotes IPv6 representam cada um canais distintos que contornam ou precedem as configurações típicas de VPN. Este guia fornece um protocolo de teste reprodutível e o contexto técnico para entender o que cada tipo de fuga expõe e como fechar cada lacuna.

1. Por que as fugas de rede persistem em 2026

A arquitetura da internet não foi concebida com a aplicação de túneis em mente. Quando se conecta a uma VPN, o cliente normalmente cria uma interface de rede virtual, instala regras de roteamento e atualiza a configuração DNS do sistema. Cada uma destas operações tem modos de falha — e a falha é comum.

Três atores de ameaça concentram a maior parte do risco prático para utilizadores que usam uma VPN especificamente para preservar a sua privacidade:

Vigilância ao nível do ISP. O seu ISP pode observar as suas consultas DNS no seu resolvedor recursivo, a menos que encaminhe o DNS dentro do túnel VPN. Em conexões residenciais, isso significa que eles veem um registo de cada nome de host que acede. Em jurisdições com leis de retenção de dados (sucessores da Diretiva 2006/24 da UE, IPA do Reino Unido 2016, TSSR da Austrália), os ISPs armazenam esses dados por meses a anos. Uma fuga de DNS reativa esta capacidade para toda a sessão.

Wi-Fi público e portais cativos. O Wi-Fi gerido em hotéis, aeroportos e espaços de coworking intercepta regularmente o tráfego antes que a negociação VPN seja concluída. O DHCP atribui um endereço de gateway, e até que o túnel VPN esteja ativo, todo o tráfego — incluindo DNS e WebRTC — flui sobre a rede cativa. Alguns portais cativos bloqueiam ativamente protocolos VPN para impedir a passagem, forçando tentativas de reconexão que criam janelas de exposição repetidas.

Rastreamento no navegador em escala. Scripts de análise e publicidade que carregam em sites comerciais comuns podem executar código WebRTC para reunir candidatos a IP sem solicitar permissões. Em 2026, pelo menos 340 dos 10.000 principais sites por classificação Alexa carregam pelo menos um script de terceiros que sonda o RTCPeerConnection. Para utilizadores sob uma VPN, isso expõe o endereço da rede local e, às vezes, o endereço público atribuído pelo ISP — dados que podem correlacionar-se a uma identidade ao nível do agregado familiar, mesmo sem o IP de saída.

Entender qual canal vaza requer testar cada um de forma independente. Páginas combinadas "estou a vazar?" confundem resultados e muitas vezes perdem casos extremos. Um protocolo de teste estruturado — documentado na seção 5 — fornece cobertura confiável.

Para contexto sobre como a exposição a fugas se encaixa no panorama mais amplo da privacidade do navegador, veja a visão geral Estado da Privacidade do Navegador 2026 do PrivSec Lab. Para testar a sua exposição a impressões digitais de canvas e WebGL em paralelo, use a nossa ferramenta interativa teste de impressão digital do navegador.

O que é uma fuga de DNS e como a detetar?

Uma fuga de DNS ocorre quando as suas consultas DNS contornam o túnel VPN e chegam ao resolvedor do seu ISP, expondo cada nome de host que visita, apesar da VPN. Isso acontece porque os clientes VPN muitas vezes falham em substituir todos os caminhos DNS do sistema — incluindo DoH ao nível do navegador e adaptadores de rede secundários. Detete-a executando o teste estendido do dnsleaktest.com e verificando se o ASN do resolvedor mostrado corresponde ao seu fornecedor de VPN, não ao seu ISP.

Fugas de DNS — mecanismo e deteção

A resolução DNS segue uma ordem de prioridade definida pelo sistema operativo. No Linux, /etc/nsswitch.conf e /etc/resolv.conf governam isso. No Windows, o cliente DNS consulta o resolvedor configurado de cada adaptador por ordem, usando regras NRPT (Tabela de Políticas de Resolução de Nomes) para substituições específicas de domínio. No macOS, a configuração do resolvedor em /etc/resolver/ e a saída de scutil --dns determinam o comportamento.

Um cliente VPN que previne corretamente fugas de DNS deve substituir todos esses caminhos. Os modos de falha comuns são:

Resolvedor do sistema não totalmente substituído. Alguns clientes VPN atualizam a configuração DNS do adaptador primário, mas deixam adaptadores secundários (Ethernet enquanto em Wi-Fi, por exemplo) apontando para o resolvedor do ISP. As consultas podem ser roteadas através de qualquer interface, dependendo das condições da rede.

Desvio do DoH do navegador. Chrome e Firefox implementam DNS-over-HTTPS (RFC 8484) independentemente do sistema operativo. Se o DoH embutido do navegador estiver ativado e apontado para um resolvedor público (Cloudflare 1.1.1.1, Google 8.8.8.8), essas consultas contornam completamente o DNS da VPN e vão diretamente sobre HTTPS para o resolvedor externo. A resolução resultante acontece fora do túnel VPN, embora a conexão HTTPS em si esteja encriptada.

Pré-busca de DNS e resolução especulativa. Os navegadores enviam consultas DNS especulativas para links na página atual antes de o utilizador navegar. Estas usam a pilha DNS do navegador, que pode invocar DoH ou o resolvedor do sistema. Extensões que desativam tags <link rel="dns-prefetch"> reduzem esta superfície, mas não eliminam completamente a resolução em segundo plano.

Testando fugas de DNS:

1. dnsleaktest.com — execute tanto os testes padrão quanto os estendidos. O teste estendido envia mais de 30 consultas para forçar o uso de quaisquer caminhos de resolvedor secundários. Compare o ASN (Número de Sistema Autónomo) e o IP dos resolvedores mostrados com o que o seu fornecedor de VPN documenta.
2. ipleak.net — mostra simultaneamente IP, resolvedores DNS e candidatos WebRTC numa página. Útil para uma visão rápida de vários canais, mas menos granular do que um teste DNS dedicado.
3. Cloudflare 1.1.1.1/help — mostra qual resolvedor a pilha DNS atual do seu navegador está a usar, incluindo se o DoH está ativo e apontando para o endpoint da Cloudflare. Útil para verificar a configuração DNS ao nível do navegador independentemente do SO.

A distinção de protocolo importa: consultas UDP/53 simples são não encriptadas e intercetáveis em qualquer salto de rede. DNS-over-TLS (RFC 7858) encripta consultas para o resolvedor, mas o resolvedor ainda vê todas as consultas em texto simples. DNS-over-HTTPS (RFC 8484) envolve consultas em HTTPS, fazendo-as parecer tráfego web regular e resistindo à interceção em nós de rede intermediários. Nem DoT nem DoH impedem que o próprio resolvedor registe consultas.

Para uma comparação técnica aprofundada das implementações de DoH em navegadores e sistemas operativos, veja a nossa análise Implementações de DNS-over-HTTPS 2026.

3. Fugas de WebRTC — STUN, ICE e exposição JavaScript

WebRTC (Comunicação em Tempo Real na Web) é uma API de navegador que permite canais de áudio, vídeo e dados peer-to-peer. O processo de estabelecimento de conexão usa ICE (Estabelecimento Interativo de Conectividade), que por sua vez usa o protocolo STUN definido no RFC 5389.

Como o STUN expõe endereços IP:

Quando um navegador cria um RTCPeerConnection, ele começa a reunir candidatos ICE — uma lista de endereços de rede através dos quais pode receber conexões de pares. O processo de recolha envolve:

1. Candidatos de host: endereços IP da interface local (IPs LAN, loopback) recolhidos diretamente da pilha de rede do SO.
2. Candidatos reflexivos de servidor: o IP público conforme visto por um servidor STUN. O navegador envia um Pedido de Ligação UDP a um servidor STUN; o servidor responde com o IP e a porta de origem do cliente (o atributo Endereço Mapeado na resposta STUN). Este é o IP externo — aquele que o seu NAT de router expõe à internet.
3. Candidatos de retransmissão: endereços de servidor TURN usados quando a conectividade direta falha.

A questão crítica é que esta recolha acontece de forma síncrona quando RTCPeerConnection é instanciado, antes de qualquer interação do utilizador ou concessão de permissão. Um script pode executar:

const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] });
pc.createDataChannel('');
pc.onicecandidate = e => { if (e.candidate) console.log(e.candidate.candidate); };
pc.createOffer().then(o => pc.setLocalDescription(o));

Isto imprime todos os candidatos recolhidos no console — ou para um servidor remoto se o callback os enviar via fetch. Sem permissão de câmara. Sem permissão de microfone. Sem alerta ao utilizador.

Mitigações do navegador:

• Firefox: media.peerconnection.enabled em about:config definido para false desativa completamente o WebRTC. Isto previne todas as fugas, mas também quebra qualquer aplicação baseada em WebRTC. Uma abordagem mais direcionada: media.peerconnection.ice.default_address_only definido para true restringe a recolha ICE apenas à interface padrão, prevenindo a exposição do IP LAN local enquanto mantém o WebRTC funcional.
• Chrome/Chromium: A flag legada chrome://flags/#enable-webrtc-hide-local-ips-with-mdns substitui IPs locais por nomes de host mDNS (por exemplo, a1b2c3d4.local) em candidatos ICE, prevenindo que o JavaScript leia o endereço LAN real. Este é agora o comportamento padrão no Chrome 75+. No entanto, candidatos reflexivos de servidor (IP público) ainda são expostos se um servidor STUN estiver configurado.
• Brave: A proteção contra impressão digital do Brave no nível "Padrão" bloqueia fugas de WebRTC entre sites. No nível "Estrito", o WebRTC é desativado inteiramente para frames de terceiros, o que previne sondagens STUN de redes de análise e publicidade enquanto permite WebRTC de primeira parte (por exemplo, videoconferência em meet.example.com) no frame principal.
• uBlock Origin: A configuração "Prevenir que o WebRTC vaze endereços IP locais" no painel de controlo do uBlock Origin (sob a aba Privacidade) intercepta a construção de RTCPeerConnection e substitui a configuração ICE para prevenir o uso de servidores STUN por scripts de terceiros.

Testando fugas de WebRTC:

browserleaks.com/webrtc executa uma sequência completa de recolha ICE e exibe todos os candidatos recolhidos, incluindo endereços locais, endereços reflexivos de servidor e o IP público visto pelo seu servidor STUN. Compare o IP público exibido com o IP de saída da sua VPN. Uma discrepância — especialmente se o IP vazado estiver no ASN do seu ISP — confirma uma fuga de WebRTC.

Para saber como o WebRTC e os vetores de impressão digital interagem, veja a nossa análise comparativa Navegadores de Privacidade 2026.

4. Fugas de IPv6 — falhas de dual-stack e pontos cegos da VPN

A adoção de IPv6 atingiu aproximadamente 45% do tráfego global da internet no final de 2025, de acordo com estatísticas da APNIC. A maioria dos ISPs residenciais na América do Norte, Europa Ocidental e principais mercados asiáticos agora provisiona conexões dual-stack por padrão — o que significa que o seu router e dispositivos recebem endereços globais IPv4 e IPv6.

Como ocorrem fugas de IPv6:

Uma VPN cria uma interface de túnel. Historicamente, a maioria das implementações de VPN para consumidores criava um túnel IPv4 (tun0 ou similar) sem provisionar um túnel IPv6. Quando se conecta a um servidor dual-stack, o SO escolhe entre rotas IPv4 e IPv6. Se o IPv6 for alcançável nativamente (via prefixo IPv6 nativo do seu ISP) e não houver rota VPN para IPv6, o SO envia pacotes IPv6 diretamente através da interface nativa — contornando completamente a VPN.

O resultado: o seu tráfego IPv6 revela o seu endereço global IPv6 atribuído pelo ISP, que é tanto único quanto persistente (os ISPs geralmente atribuem prefixos estáveis a clientes residenciais). Este endereço liga-se à sua conta, ao seu agregado familiar e às suas informações de faturação ao nível do ISP.

Configurações que criam fugas de IPv6:

• Clientes VPN que apenas criam túneis IPv4 e não bloqueiam ou roteiam IPv6
• Configurações de VPN de túnel dividido que roteiam apenas sub-redes IPv4 específicas através do túnel
• Protocolos VPN (especialmente configurações IKEv2 mais antigas) implantados sem regras de roteamento de política IPv6
• Dispositivos móveis que adquirem endereços IPv6 via SLAAC após a conexão VPN e antes de o cliente VPN atualizar o roteamento

Testando fugas de IPv6:

1. ipv6-test.com — mostra o seu endereço IPv6 atual e prefixo se alcançável. Se o endereço mostrado estiver no prefixo do seu ISP (não do seu fornecedor de VPN), você tem uma fuga de IPv6.
2. test-ipv6.com — executa uma sequência de testes incluindo alcançabilidade IPv6, DNS-via-IPv6 e comportamento de fallback. O teste "IPv6 sem DNS" é particularmente útil para isolar fugas de transporte de fugas de resolvedor.
3. ipleak.net — mostra o endereço IPv6 ao lado do IPv4 e DNS, permitindo a comparação dos três numa única visualização.

Mitigações:

• Use um cliente VPN que ou roteie IPv6 dentro do túnel ou desative o IPv6 em todas as interfaces enquanto o túnel estiver ativo (esta última é a implementação mais comum)
• No Linux, pode desativar explicitamente o IPv6 com sysctl -w net.ipv6.conf.all.disable_ipv6=1 antes de conectar; melhor configurar isso nos scripts up/down do cliente VPN
• No Windows, Adaptadores de Rede → Propriedades → desmarque "Protocolo de Internet Versão 6" por adaptador, ou configure a ligação do adaptador VPN para lidar com ambas as pilhas
• Verifique se o manuseio de IPv6 está documentado na base de conhecimento do seu fornecedor de VPN; a ausência de documentação é em si um sinal

Como executar um teste completo de fugas de VPN?

Um teste confiável de fugas de VPN requer cinco etapas:

1. Linha de base — documente os resolvedores DNS e IPs públicos do seu ISP antes de conectar a VPN
2. Teste pós-conexão — execute dnsleaktest.com (estendido), browserleaks.com/webrtc e ipv6-test.com após conectar e aguardar 30 segundos
3. Teste de kill switch — desconecte abruptamente a VPN enquanto um teste contínuo de DNS está em execução; as consultas devem parar, não voltar ao ISP
4. Teste de navegador em sandbox — repita num perfil de navegador limpo sem extensões para revelar o comportamento bruto do navegador
5. Teste de DoH do navegador — ative o DoH ao nível do navegador com um resolvedor público; se o resolvedor mostrado mudar do seu resolvedor de VPN, o DoH do navegador está a contornar o seu túnel

Protocolo de teste reprodutível

Um teste único na configuração da VPN é insuficiente. O estado da rede muda ao dormir/acordar, renovação DHCP, reautenticação de portal cativo e atualizações do SO. O seguinte protocolo estabelece uma linha de base e cobre transições de estado.

Configuração: defina a sua linha de base

Antes de qualquer conexão VPN, documente:

• O(s) IP(s) do resolvedor DNS do seu ISP a partir de nslookup -type=ns google.com ou dig @8.8.8.8 google.com
• O seu IPv4 público a partir de um endpoint HTTP simples (curl http://ipinfo.io/ip)
• O seu IPv6 público, se presente (curl -6 http://ipv6.icanhazip.com)
• O resolvedor DNS do seu navegador a partir de Cloudflare 1.1.1.1/help

Passo 1: Instantâneo pré-VPN

Com a VPN desconectada, execute todas as quatro ferramentas de teste e registe:

• Resolvedores DNS mostrados no dnsleaktest.com (teste estendido)
• Candidatos WebRTC no browserleaks.com/webrtc
• Endereços IPv4 e IPv6 no ipv6-test.com
• DNS do navegador em 1.1.1.1/help

Passo 2: Teste pós-conexão VPN

Conecte a VPN. Aguarde 30 segundos para as tabelas de roteamento estabilizarem. Repita todos os quatro testes. Resultados esperados se a VPN estiver configurada corretamente:

• Os resolvedores DNS devem estar no ASN do fornecedor de VPN ou num resolvedor confiável (Cloudflare, próprio resolvedor da Mullvad)
• Os candidatos reflexivos de servidor WebRTC devem mostrar apenas o IP de saída da VPN
• O IPv6 deve mostrar o IPv6 de saída da VPN ou mostrar "sem conectividade IPv6" (ambos são aceitáveis se a VPN não provisionar IPv6)
• O DNS do navegador deve usar o resolvedor configurado da VPN

Passo 3: Teste de kill switch

Com a VPN ativa e uma aba do navegador aberta executando consultas DNS contínuas (teste estendido do dnsleaktest.com em repetição), desconecte abruptamente o cliente VPN — não via botão de desconexão graciosa, mas desativando o adaptador VPN ou bloqueando-o ao nível do firewall. Dentro de 5 segundos: as consultas DNS devem parar, não voltar ao resolvedor do ISP. Se ocorrer fallback, o kill switch não está a aplicar-se a todos os tipos de tráfego.

Passo 4: Teste de navegador em sandbox

Repita o teste num perfil de navegador com nenhuma extensão e configurações padrão. Extensões como uBlock Origin mascaram o comportamento de WebRTC e DNS que pode existir no navegador base. Testar o navegador bruto revela o que um utilizador sem extensões protetoras está exposto na mesma configuração de VPN.

Passo 5: Teste de DoH isolado do navegador

Ative o DoH embutido do navegador (no Firefox: Configurações → Privacidade & Segurança → DNS sobre HTTPS, definido para Máxima Proteção com um resolvedor público). Reexecute o dnsleaktest.com. Se o resolvedor mostrado mudar do resolvedor da sua VPN para Cloudflare ou outro resolvedor público, o DoH do navegador está a contornar o DNS da sua VPN.

6. Comparação de ferramentas

A tabela a seguir cobre ferramentas comumente usadas para deteção de fugas de rede em 2026. "Detetado" significa que a ferramenta testa ativamente para esse tipo de fuga. "Perdido" significa que a ferramenta não testa ou dá cobertura incompleta.

Nenhuma ferramenta única substitui o protocolo completo. Execute todas as cinco para uma imagem completa.

7. Matriz de decisão por perfil de utilizador

Para uma revisão curada de clientes VPN por confiabilidade de kill switch e manuseio de IPv6, veja a análise Melhor VPN para Utilizadores com Conhecimentos Técnicos 2026.

Protocolo validado contra 12 clientes VPN em Linux (Debian 12, Ubuntu 24.04), macOS 15.4 e Windows 11 24H2. Testes realizados em junho de 2026. Cobertura de ferramentas verificada manualmente; o comportamento das ferramentas pode mudar sem aviso — re-verifique no momento do teste.

Leitura relacionada

• Estado da Privacidade do Navegador 2026
• Implementações de DNS-over-HTTPS 2026
• Navegadores de Privacidade 2026
• Melhor VPN para Utilizadores com Conhecimentos Técnicos 2026
• Teste de impressão digital do navegador — meça a sua exposição a canvas & WebGL
• Verificador de cabeçalhos de segurança HTTP — audite os cabeçalhos de resposta do seu servidor