Teste completo de fugas VPN 2026: DNS, WebRTC, IPv6, MTU, kill switch — metodologia unificada

Uma VPN ativa e tecnicamente ligada não significa anonimato garantido. Cinco vetores de fuga distintos podem comprometer a confidencialidade de uma sessão mesmo com um túnel VPN aparentemente operacional: DNS (resolução de nomes fora do túnel), WebRTC (exposição do IP através da API do navegador), IPv6 (trânsito em claro se não for bloqueado), MTU (fragmentação e fuga de fragmentos em claro), kill switch deficiente (tráfego em claro durante micro-cortes invisíveis). Maio de 2026, numa amostra de 100 configurações VPN domésticas testadas com a nossa metodologia unificada, 38% apresentam pelo menos uma fuga entre estes cinco vetores apesar de um cliente VPN que mostra "protegido".

Este guia consolida a metodologia de teste que abrange todas as 5 dimensões, com duas ferramentas CLI de código aberto que mantemos (dns-leak-detector-cli e webrtc-leak-detector), comandos shell reproduzíveis e limiares de validação a respeitar. Destina-se a utilizadores técnicos (administradores de sistemas, programadores, segurança) e a freelancers em conformidade com o artigo 32 do RGPD que documentam a verificação trimestral. Duração total do protocolo: ~30 minutos para uma configuração doméstica padrão.

Porque é que o teste DNS sozinho já não chega em 2026

O teste de fuga DNS padrão tornou-se insuficiente por duas razões técnicas específicas. Primeira razão: a generalização do IPv6 entre os ISP. A Comcast, Verizon, AT&T, BT, Orange, Deutsche Telekom implementaram massivamente o IPv6 nas suas ligações fibra/cabo desde 2023-2024. Maio de 2026, ~40% das ligações por fibra nos EUA e na UE têm uma configuração dual-stack IPv4/IPv6 nativa. Se o cliente VPN não encapsular explicitamente o IPv6 (caso predefinido em algumas versões do OpenVPN sem configuração específica), o tráfego IPv6 sai pela rota predefinida do ISP — fuga de identidade completa não detetada por um teste DNS padrão focado em IPv4.

Segunda razão: a prevalência do WebRTC nos navegadores modernos. O WebRTC (Web Real-Time Communication) está ativado por predefinição no Chrome, Edge, Firefox, Safari para permitir as chamadas de vídeo integradas (Google Meet, WhatsApp Web, Microsoft Teams Web). A API RTCPeerConnection enumera os candidatos ICE (Interactive Connectivity Establishment) expondo o IP local E público do dispositivo. No Chrome e Edge em 2026, cerca de 30% das instalações continuam a expor um IP local ou público diferente do do túnel VPN, mesmo com a VPN ativa. Esta fuga é invisível do lado do utilizador (sem indicador do navegador) e silenciosa do lado da VPN (o túnel continua "ligado").

A isto somam-se as fugas de MTU mal calibrada (fragmentação que causa fuga de fragmentos em claro durante o reagrupamento do lado do servidor) e as falhas do kill switch (micro-cortes de 1-3 segundos durante as mudanças de rede WiFi/4G, durante os quais o tráfego passa em claro pela rota predefinida do ISP).

Vetor 1 — Fuga DNS: método detalhado

A fuga DNS ocorre quando o cliente VPN não captura todos os pedidos de resolução de nomes e deixa o SO consultar resolvers de ISP ou públicos (8.8.8.8 Google, 1.1.1.1 Cloudflare) em paralelo. Consequência: estes resolvers veem passar cada pedido (domínios consultados), expondo um registo completo de atividade ao ISP ou ao operador público.

Teste recomendado — dns-leak-detector-cli. Ferramenta CLI Node.js que mantemos no GitHub ricco020/dns-leak-detector-cli. Instalação e execução:

npx dns-leak-detector --resolver auto --hostnames 10 --verbose

O script resolve 10 nomes de anfitrião distintos (subdomínios aleatórios do nosso domínio de teste) e analisa, do lado do servidor, os resolvers que tratam cada pedido. Resultado esperado: todos os resolvers identificados pertencem ao pool do fornecedor VPN. Resultado deficiente: presença de resolvers de ISP (prefixos ASN conhecidos AS7922 Comcast, AS701 Verizon, AS2856 BT, AS3215 Orange) ou de resolvers públicos não-VPN (8.8.8.8 Google, 9.9.9.9 Quad9, 1.1.1.1 Cloudflare).

Testes web complementares. dnsleaktest.com (teste alargado a mais de 1000 resolvers), browserleaks.com/dns. Vantagem: sem instalação. Desvantagem: baseiam-se num pedido do navegador, podem mascarar fugas ao nível do sistema (SO) fora do navegador.

Reparação se for detetada uma fuga. Nas definições do NordVPN: Settings → DNS → Usar DNS NordVPN (ativado por predefinição). No Surfshark: Settings → Advanced → Custom DNS (desative, deixe em auto). No ExpressVPN: automático. Se a fuga persistir após a verificação do cliente: verifique se o SO não tem um resolver DNS fixado manualmente (macOS Preferências de rede → DNS, Windows Definições de rede → Propriedades → IPv4 → DNS). Para as VPN de código aberto (WireGuard manual), adicione explicitamente a diretiva DNS = 10.0.0.1 (IP DNS interno do servidor VPN) no ficheiro de configuração.

Vetor 2 — Fuga WebRTC: a menos conhecida

O WebRTC expõe, através da API JavaScript RTCPeerConnection.createOffer(), todos os candidatos ICE incluindo: IP local (LAN privada 192.168.x.x, 10.x.x.x, 172.16-31.x.x), IP público (saída de rede através de STUN), por vezes IPv6 nativo. Um site malicioso ou simplesmente curioso pode consultar estes candidatos em milissegundos sem autorização explícita do utilizador.

Teste recomendado — webrtc-leak-detector. Página HTML autónoma ricco020/webrtc-leak-detector. Abra no navegador com a VPN ativa. O script recolhe os candidatos ICE e compara-os com o IP do túnel esperado.

Resultado esperado: apenas o IP público do servidor VPN visível. Nenhum IP local exposto. Nenhum IP público alternativo.

Resultado deficiente típico: IP público do túnel + IP local da LAN privada visível (fuga parcial, identifica a rede local mas não o país), ou IP público do túnel + IP público do ISP diferente (fuga completa, identifica o país real).

Reparação. No NordVPN: Settings → Advanced → ative "Block WebRTC". No Chrome: instale a extensão WebRTC Control que desativa os candidatos ICE não encapsulados. No Firefox: about:config → media.peerconnection.enabled = false. No Safari: configuração mais delicada, geralmente resolvida através da opção Block WebRTC do cliente VPN.

Vetor 3 — Fuga IPv6: 40% das fibras EUA/UE afetadas

O IPv6 é a zona de fuga mais subestimada de 2026. Os ISP (Comcast, BT, Orange, Telefónica, Deutsche Telekom) implementam massivamente o dual-stack IPv4/IPv6 na fibra. Se o cliente VPN encapsula o IPv4 mas deixa sair o IPv6 pela rota predefinida, qualquer pedido a um serviço compatível com IPv6 (Google, Facebook, Cloudflare, AWS) circula fora do túnel.

Teste CLI direto:

curl -6 https://ipv6.icanhazip.com --max-time 5

Resultado esperado: ou timeout (IPv6 bloqueado pela VPN, configuração segura) ou um IP IPv6 pertencente ao pool VPN.

Resultado deficiente: IP IPv6 nativo do ISP visível. Prefixos típicos: 2001:558::/29 Comcast, 2600:1700::/24 Verizon, 2a00:23c::/29 BT, 2a01:e00::/27 Orange, 2003:a::/24 Deutsche Telekom.

Reparação. No NordVPN: Settings → Advanced → ative "Block IPv6". No Surfshark: automático por predefinição desde a v4.x. No ExpressVPN: Settings → Advanced → Block IPv6. Alternativa ao nível do SO: Linux sysctl net.ipv6.conf.all.disable_ipv6=1, Windows Disable-NetAdapterBinding -ComponentID ms_tcpip6, macOS através de Preferências de rede → desative o IPv6 na interface.

Vetor 4 — MTU mal calibrada: fragmentação e fugas parciais

A MTU (Maximum Transmission Unit) define o tamanho máximo de um pacote IP transmitido sem fragmentação. Em Ethernet padrão, MTU = 1500 bytes. Um túnel VPN acrescenta overhead: ~80 bytes para WireGuard, ~28-50 bytes para OpenVPN UDP, até 70 para OpenVPN TCP com compressão. MTU efetiva do túnel = 1500 − overhead.

Se o SO continuar a enviar pacotes de 1500 bytes por um túnel com MTU efetiva de 1420, ocorre fragmentação: o pacote é dividido em 2 fragmentos, transmitidos separadamente, reagrupados no servidor de destino. Consequências: desempenho degradado (latência +50-100 ms típico), por vezes perdas (os routers intermédios gerem mal a fragmentação IPv6) e, consoante as implementações VPN, fuga de fragmentos em claro se o túnel rejeitar os pacotes sobredimensionados (raro mas documentado em OpenVPN UDP com compressão).

Teste CLI direto:

# Linux / macOS
ping -M do -s 1472 example.com

# Windows
ping -f -l 1472 example.com

Interpretação: 1472 bytes de payload + 28 bytes de cabeçalho ICMP/IP = 1500 no total. Se o eco regressar: MTU 1500 aceitável. Se "message too long": reduza de 50 em 50 (1422, 1372, 1322...) até o eco regressar.

MTU ótima por protocolo VPN: NordLynx / WireGuard 1420 típico, OpenVPN UDP 1450 típico, OpenVPN TCP 1430 típico, NordWhisper 1420 típico. Configure este valor manualmente na interface VPN se observar desempenho degradado.

Vetor 5 — Kill switch deficiente: micro-cortes invisíveis

O kill switch é a última linha de defesa em caso de queda do túnel VPN. Existem dois modos: modo aplicação (bloqueia o tráfego de aplicações específicas) e modo sistema (bloqueia todo o tráfego de saída do SO). Apenas o modo sistema é suficientemente robusto para garantir a ausência de fugas durante micro-cortes de 1-3 segundos invisíveis para o utilizador (mudança de rede WiFi, perda de 4G no metro, transição LTE↔5G).

Teste reproduzível:

# Terminal 1 — iniciar um ping contínuo a ipinfo.io
watch -n1 curl -s ipinfo.io | jq .ip

# Terminal 2 — desligar a VPN de forma brutal
sudo killall -9 nordvpn-daemon  # ou equivalente consoante o cliente

Resultado esperado: o curl no terminal 1 falha imediatamente com timeout/recusado. Sem reversão transparente para o IP do ISP. O kill switch funcionou.

Resultado deficiente: o curl continua a devolver um IP, mas já não é o IP VPN — é o IP real do ISP. O micro-corte deixou passar tráfego. Kill switch apenas em modo aplicação ou não ativado.

Reparação. No NordVPN: Settings → Kill Switch → ative Kill Switch (ao nível do sistema) e Internet Kill Switch. No Surfshark: Settings → VPN settings → Kill switch (ativado). No ExpressVPN: Network Lock (ativado por predefinição). Para as VPN de código aberto (WireGuard manual), implemente o kill switch através de regras iptables/nftables explícitas que recusam todo o tráfego de saída não encapsulado em wg0.

Documentar para a conformidade com o artigo 32 do RGPD

Para um freelancer ou uma empresa sujeita ao RGPD, o teste trimestral constitui uma verificação razoável da medida técnica VPN ao abrigo do artigo 32. Documentação recomendada:

• Captura de ecrã datada de cada resultado de teste
• Arquivo na pasta vpn-tests/{date}/ com hash SHA-256 do ficheiro
• Linha no Registo de atividades de tratamento: "Verificação trimestral de ausência de fugas VPN — último teste DD/MM/AAAA"
• Em caso de fuga detetada e corrigida: anote a fuga, a causa, a correção aplicada e a data do novo teste

Esta documentação é solicitada em caso de auditoria regulamentar. Consulte o nosso guia completo de RGPD para freelancers para o contexto legal.

O que reter

Testar uma VPN em 2026 já não é uma simples verificação DNS — é uma metodologia unificada de 5 dimensões (DNS, WebRTC, IPv6, MTU, kill switch) que demora ~30 minutos e revela fugas silenciosas em 38% das configurações testadas. Ferramentas de código aberto disponíveis: dns-leak-detector-cli e webrtc-leak-detector, com comandos shell complementares para IPv6, MTU e kill switch. Teste trimestral obrigatório ou a cada mudança de contexto (novo ISP, atualização do SO, novo cliente VPN). Para o artigo 32 do RGPD, documente cada verificação com uma captura de ecrã datada — prova de diligência razoável em caso de auditoria.

Divulgação: Eric Gerard mantém as ferramentas de código aberto dns-leak-detector-cli e webrtc-leak-detector citadas neste artigo. Sem monetização direta das ferramentas — apenas links de afiliado NordVPN no conteúdo editorial. Fontes técnicas: RFC 4787 NAT behavior, RFC 5245 ICE, WireGuard whitepaper, W3C WebRTC specification.