O que acontece no momento em que o túnel cai
A conexão falha aberta. A VPN adiciona rotas que empurram o tráfego para uma interface de rede virtual. Quando o processo do túnel morre ou expira, essas rotas somem, enquanto a rota padrão pelo Wi-Fi ou pelo cabo permanece — então o sistema continua entregando pacotes, agora direto pela operadora. Os apps reconectam seus sockets em segundos, mandando tráfego do seu IP real, sem nenhuma janela de erro em lugar algum.
Quedas são rotina. Trocar do Wi-Fi para os dados móveis, um notebook acordando do repouso, uma rede de hotel capenga ou um reinício do servidor da VPN — tudo isso quebra o túnel por um momento. O que esse momento custa depende do que tem permissão para sair do seu dispositivo enquanto o túnel está no chão.
O que o kill switch faz de verdade
Um kill switch é um conjunto de regras de firewall, não mágica. A versão estrita permite só dois tipos de tráfego de saída: pacotes entrando na interface do túnel e os próprios pacotes criptografados do cliente de VPN rumo ao servidor. Se o túnel cai, o tráfego dos aplicativos simplesmente não tem para onde ir até ele voltar.
Isso muda o modo de falha, não evita as falhas. Com kill switch, uma queda vira uma conexão pausada que você percebe; sem ele, vira tráfego no seu endereço real que você não percebe. Redes são imperfeitas e o túnel vai quebrar mesmo assim — falhar fechado torna esses momentos inofensivos.
Kill switch do sistema vs kill switch dentro do app
A diferença é o que acontece quando o próprio app morre. O kill switch de aplicativo é código dentro do cliente de VPN que vigia o túnel e bloqueia o tráfego quando ele cai. Só funciona enquanto o cliente roda: se o cliente trava ou é morto por um otimizador de bateria, a proteção morre junto — exatamente no momento em que o túnel desaparece.
O kill switch de nível de sistema instala regras no firewall do próprio sistema operacional, que inspeciona cada pacote de saída independentemente de quais apps estão rodando. O Android tem isso embutido: VPN sempre ativa mais o bloqueio de conexões sem VPN faz o próprio sistema recusar tráfego fora do túnel, mesmo antes de o app iniciar depois de um reboot. O jeito bruto de distinguir os dois: force o encerramento do app de VPN enquanto navega — se as páginas continuarem carregando, o switch mora no app.
Vazamento de DNS: consultas que pulam o túnel
Vazamento de DNS significa que as suas resoluções de nome vão para o resolvedor que a rede local atribuiu — geralmente o da operadora — mesmo com o tráfego em si viajando pelo túnel. Os sites veem o endereço da VPN, mas o resolvedor recebe o nome de cada site que você abre, o que equivale a um registro de navegação. O Windows é o infrator clássico: com várias interfaces ativas, ele pode consultar todas em paralelo e usar a que responder primeiro.
A correção tem duas partes, e um bom cliente faz as duas: apontar o sistema para o resolvedor dentro do túnel e bloquear DNS em todas as outras interfaces, para que uma consulta perdida não tenha para onde ir. Depois, verifique: rode um teste de vazamento e confira os resolvedores listados — se algum for da sua operadora, as consultas estão vazando.
Vazamento de WebRTC: o navegador entrega endereços
O WebRTC é a tecnologia de navegador por trás das videochamadas, e qualquer site pode invocá-la com poucas linhas de JavaScript. Para montar conexões diretas, ela coleta cada endereço que possa alcançar a sua máquina: os endereços locais e, perguntando a um servidor STUN, o público. Uma página pode ler esses candidatos sem nenhuma ação sua.
Com um túnel de dispositivo inteiro, a requisição STUN viaja dentro do túnel e descobre o endereço da VPN. As montagens perigosas são as parciais: um proxy só de navegador ou split tunneling que deixa o navegador de fora — ali os pacotes UDP do WebRTC saem direto e revelam o seu IP real.
Teste em vez de raciocinar: nosso verificador gratuito em /webrtc-leak-test/ mostra quais endereços o seu navegador revela agora. Se o real aparecer, migre para um túnel de dispositivo inteiro ou desative o WebRTC nas configurações do navegador.
Vazamento de IPv6: o túnel só cobre IPv4
Muitas configurações de VPN carregam apenas IPv4. Se a sua operadora também fornece IPv6 — a maioria das redes móveis fornece — o sistema mantém uma rota IPv6 funcional fora do túnel, e sistemas modernos preferem IPv6 quando o site oferece os dois. O resultado é exposição seletiva: sites sem IPv6 veem o endereço da VPN, sites com IPv6 veem o seu real, e um teste só-IPv4 relata que está tudo bem.
Há duas correções limpas. A melhor é uma VPN que trate IPv6 direito — tunelando-o junto com o IPv4 ou instalando uma rota de bloqueio para que os pacotes IPv6 sejam descartados, não enviados direto. O plano B bruto é desativar o IPv6 no dispositivo ou no roteador. De um jeito ou de outro, verifique: o teste de vazamento não deve mostrar nenhum endereço IPv6 que não seja da VPN.
Como testar sua configuração direito
Rode as checagens nas condições que você realmente usa — Wi-Fi de casa, celular nos dados móveis, a rede de uma cafeteria — porque os vazamentos dependem da configuração de DNS e da disponibilidade de IPv6 de cada rede. A rotina leva uns cinco minutos:
- Anote o seu IP real com a VPN desligada, conecte e confirme que os endereços IPv4 e IPv6 visíveis mudaram — nosso /data-leak-checker/ mostra IP, resolvedores DNS e WebRTC numa passada só
- Confira a lista de resolvedores: todo servidor DNS exibido deve pertencer à VPN, nenhum à operadora
- Derrube o túnel de propósito — alterne o Wi-Fi ou force o encerramento do app — e observe se as páginas carregam antes de ele reconectar
- Repita após atualizações do sistema ou do app de VPN, já que ambas podem redefinir configurações de rede em silêncio