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). Investigação independente constata regularmente que uma parte considerável das configurações VPN domésticas apresenta 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) 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
• Ficheiro 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 pode revelar fugas silenciosas que um teste DNS padrão não vê. 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.