O que acontece quando sua VPN cai? Kill switch explicado

O trabalho de um kill switch de VPN é simples de descrever: quando a conexão VPN cai, prevenir tráfego de vazar pra fora do túnel. As implementações entre provedores de VPN variam amplamente, e as diferenças importam. Um kill switch com janela de vazamento de múltiplos segundos durante uma queda de VPN derrota o propósito inteiro de ter um kill switch.

Esta é a versão técnica. O que kill switches realmente fazem, os dois padrões principais de implementação, por que nível-kernel importa, e como testar que o seu funciona.

O que "kill switch" realmente significa

Quando seu cliente VPN estabelece um túnel, seu tráfego vai por ele. Quando o túnel quebra — falha de servidor, mudança de rede, ciclo dormir/acordar, interrupção no nível de protocolo — a questão é o que acontece com tráfego durante a quebra.

Três comportamentos possíveis:

Tráfego continua pela sua conexão real. Seu IP real fica visível pra destinos. A criptografia que deveria estar ativa está desativada. Qualquer um observando a rede vê o que está fazendo. É o que acontece sem kill switch nenhum.
Kill switch no nível de aplicação detecta a queda e para o tráfego. O daemon do cliente VPN nota que o túnel está caído, depois toma ação pra bloquear tráfego. A detecção tem latência (o daemon faz polling; a stack de rede reporta quedas com delay; a ação leva tempo pra aplicar). A janela de vazamento é tipicamente 1-30 segundos.
Kill switch no nível de kernel bloqueia todo tráfego exceto túnel VPN desde o início. Regras de firewall no nível do kernel do SO bloqueiam tudo que não está no túnel VPN. Quando a VPN cai, as regras ainda estão lá bloqueando tudo; novo tráfego não pode sair até a VPN reconectar. Não há gap de detecção e ação porque não há nada pra detectar — as regras bloqueiam por padrão e só permitem tráfego VPN.

Maioria dos provedores de VPN implementa algo. A questão é qual.

Como conexões VPN caem

Vale entender porque molda o que o kill switch tem que lidar. Quedas acontecem por várias razões:

Falhas do lado do servidor. O servidor VPN trava, reinicia, ou tem sua interface de rede flapando. Recuperação: cliente reconecta, possivelmente a um servidor diferente.

Mudanças de rede no cliente. Trocar de Wi-Fi pra Ethernet. Trocar de redes Wi-Fi. Hibernar o notebook e acordar. O túnel VPN quebra porque a rede subjacente muda; o cliente tem que re-estabelecer.

Problemas no nível de protocolo. Timeout de handshake WireGuard (o peer não responde dentro de 90 segundos do último handshake). Falha de keep-alive OpenVPN. Timeout de sessão TLS VLESS Reality.

Interferência ativa. Um operador de rede ou sistema DPI bloqueia a conexão VPN no meio da sessão. A conexão cai e o cliente não pode re-estabelecer até a rede mudar ou o protocolo trocar.

Crashes de cliente. O processo do cliente VPN morre por qualquer razão.

Janelas de boot / shutdown. O sistema tem acesso à rede antes do cliente VPN iniciar (boot) e depois do cliente VPN desligar (shutdown). Durante essas janelas, tráfego pode vazar mesmo se o kill switch for sólido.

Um kill switch completo lida com todas. Uma implementação no nível de aplicação lida com latência de detecção em cada evento. Uma implementação no nível de kernel lida bloqueando tudo que não está no túnel por padrão.

Kill switch no nível de aplicação: como funciona

Maioria dos clientes VPN implementa isso:

O cliente estabelece o túnel.
O cliente faz polling do estado do túnel num timer (tipicamente intervalo de 1-5 segundos).
Quando o polling detecta um túnel caído, o cliente diz ao SO pra parar tráfego — geralmente mudando a tabela de roteamento ou fazendo chamadas de sistema pra bloquear conexões específicas.
Quando o túnel reconecta, o cliente desfaz o bloqueio.

As janelas de vazamento:

Entre queda e detecção. Se o intervalo de polling é 5 segundos, a janela de vazamento pode ser até 5 segundos.
Entre detecção e ação. Chamadas de SO levam tempo. Mudanças na tabela de roteamento se propagam. O sistema tem tempo pra mandar pacotes pela interface errada durante esse gap.
Entre crash do cliente e recuperação no nível do SO. Se o processo do cliente VPN morre, o SO não tem nada dizendo pra bloquear tráfego. Sem outras garantias, tráfego flui livremente até o cliente reiniciar e re-estabelecer o kill switch.
No boot antes do cliente iniciar. Mesma questão: tráfego pode fluir livremente antes do cliente VPN estar ativo.

Algumas implementações no nível de aplicação são mais robustas que outras — recuperam de crash limpamente, aplicam bloqueios no nível de adaptador de rede em vez de na tabela de roteamento, integram com notificações de estado de rede do SO. Kill switch da NordVPN, Network Lock da ExpressVPN, kill switch da Surfshark todos têm graus variados de sofisticação. Nenhum é baseado em filtro no nível de kernel em todas plataformas.

Kill switch no nível de kernel: como funciona

Uma abordagem diferente: instalar regras de firewall no nível do kernel do SO que bloqueiam todo tráfego exceto tráfego pro endpoint VPN e tráfego no túnel VPN. As regras são persistentes entre crashes de cliente, reboots, dormir/acordar.

No Windows, isso significa filtros do Windows Filtering Platform (WFP). WFP é o subsistema de filtragem de pacote no nível de kernel que Windows usa pro firewall embutido e pra produtos de segurança de terceiros. Filtros na camada WFP se aplicam a todo pacote que entra ou sai da stack de rede, independente de qual aplicação manda.

No macOS, o equivalente é regras pf (packet filter).

No Linux, regras iptables ou nftables no nível de kernel.

O padrão entre as três:

O cliente VPN (ou seu instalador) registra regras no nível de kernel que bloqueiam todo tráfego exceto:
- Tráfego pros endpoints do servidor do provedor de VPN (pra VPN poder conectar)
- Tráfego no túnel VPN (pra tráfego de usuário real fluir)
As regras persistem entre crashes de cliente, reboots, dormir/acordar.
Quando o cliente VPN estabelece um túnel, tráfego flui. Quando o túnel cai, tráfego para porque as regras ainda bloqueiam tudo que não está no túnel.
Não há gap de detecção e ação porque não há nada pra detectar — o estado padrão é "bloqueado exceto pro túnel".

O kill switch do Fexyn no Windows é baseado em WFP. As regras de filtro WFP são instaladas pelo helper service (um serviço com privilégios SYSTEM que tem direitos pra instalar filtros no nível de kernel) e persistem entre boots. Quando o usuário inicia o cliente VPN, o helper service traz o túnel e tráfego flui. Quando o túnel cai, as regras WFP ainda bloqueiam tudo; nenhum tráfego sai até o túnel voltar.

Persistência em boot

O problema mais difícil: o que acontece durante boot, antes do cliente VPN ter iniciado?

Sem persistência em boot, o sistema tem acesso à internet durante boot (pra conectar a redes corporativas, baixar atualizações Windows, sincronizar tempo com servidores NTP) antes do cliente VPN subir. Durante essa janela, qualquer coisa que é auto-iniciada no boot pode comunicar pela conexão não criptografada.

Kill switches persistentes em boot instalam regras WFP que sobrevivem reboots. As regras bloqueiam todo tráfego durante boot até o cliente VPN subir e levantar o túnel. O cliente VPN no startup sinaliza pras regras WFP permitirem tráfego de túnel; até esse sinal, o sistema não tem acesso à internet.

Isso é mais agressivo que o que maioria dos usuários quer — seu notebook genuinamente não consegue alcançar a internet durante boot até a VPN estar ativa. Mas pra usuários com requisitos fortes de privacidade (jornalistas, ativistas, certos usuários corporativos), persistência em boot é a única forma de prevenir vazamentos da janela de boot.

Fexyn suporta persistência em boot como opção configurável. Padrão é desligado (porque confunde novos usuários quando seu notebook parece "quebrado" no boot antes deles perceberem que a VPN ainda não iniciou). Ativar é um toggle nas configurações do app.

Como testar seu kill switch

O teste honesto:

Inicie sua VPN. Verifique que está conectada (cheque IP em ipleak.net ou serviço similar — deve mostrar o IP de saída VPN).
Abra um cliente torrent ou qualquer aplicação que manda tráfego contínuo. Note seu IP real em ipleak.net.
Desabilite seu adaptador de rede (ou desconecte Ethernet, ou desligue Wi-Fi). A conexão VPN cai porque a rede sumiu.
Espere 30 segundos. As tentativas de reconexão da VPN vão falhar porque a rede sumiu.
Re-habilite seu adaptador de rede. Note o que acontece.

O que você quer ver: tráfego não começa a fluir imediatamente quando a rede volta. Tráfego só começa a fluir uma vez que a VPN reconectou. Rode ipleak.net de novo — o IP mostrado deve ser a saída VPN, não seu IP real.

O que você não quer ver: tráfego flui imediatamente quando a rede volta, seu IP real é visível em ipleak.net, a VPN reconecta no fundo mas só depois que algum tráfego já saiu.

Um kill switch no nível de kernel passa nesse teste. Um kill switch no nível de aplicação com loop de detecção rápido geralmente passa. Um kill switch no nível de aplicação com loop de detecção lento falha.

Por que isso importa pra casos de uso específicos

Pra maioria dos usuários — privacidade casual, trabalho ocasional em Wi-Fi público, geo-bypass pra streaming — kill switches no nível de aplicação são geralmente suficientes. As janelas de vazamento são segundos, não minutos; o tráfego que vaza é improvável de ser sensível o suficiente pra importar.

Pra casos de uso específicos, nível-kernel importa mais:

Torrent. Um cliente torrent rodando por horas pode experimentar quedas de VPN sem o usuário notar. Um IP real aparecendo em logs de swarm por mesmo alguns segundos é suficiente pra agentes de detentores de direitos logarem. Kill switches no nível de kernel previnem o vazamento.

Jornalismo, ativismo, trabalho dissidente. Comunicações que precisam de confidencialidade por razões de segurança não podem tolerar nem vazamentos curtos. Nível-kernel + persistência em boot é a configuração certa.

Uso movido por compliance (LGPD, HIPAA, ABA 477R). Uma VPN caindo no meio da sessão e expondo dados de cliente em conexão não criptografada é a postura de compliance que está tentando prevenir. Kill switch no nível de kernel é o controle técnico que torna a alegação de compliance defensável.

Ambientes corporativos. Kill switches que sobrevivem ciclos dormir/acordar importam pra notebooks que vão e voltam de mochilas durante viagens.

Quais provedores usam o quê

O quadro em 2026:

Fexyn: baseado em WFP nível-kernel no Windows (produção) e Android (enviado); clientes macOS, Linux e iOS estão chegando
Mullvad: nível-kernel no Windows, macOS, Linux. Entre as implementações de kill switch mais robustas disponíveis.
NordVPN: nível-aplicação na maioria das plataformas com várias melhorias; recursos nível-kernel no cliente Windows mais novo. Variável dependendo da versão.
Network Lock da ExpressVPN: nível-aplicação com implementação proprietária; funcionalmente robusto no Windows e macOS mas não estritamente baseado em filtro nível-kernel
Surfshark: kill switch nível-aplicação
ProtonVPN: nível-kernel na maioria das plataformas
IVPN: nível-kernel na maioria das plataformas
AirVPN: nível-kernel

O padrão: provedores focados em privacidade técnica (Mullvad, ProtonVPN, IVPN, AirVPN, Fexyn) tendem ao nível-kernel. Provedores focados em mercado de consumidor amplo (NordVPN, ExpressVPN, Surfshark) historicamente usaram nível-aplicação com melhorias ao longo do tempo.

Perguntas frequentes

Minha VPN tem kill switch?

Quase toda VPN reputável alega ter um. Se realmente funciona do jeito que você precisa é questão pra verificar, não assumir. O teste descrito acima (desabilitar rede no meio da sessão, observar o que acontece quando a rede volta) é a resposta prática.

Por que nem toda VPN usa kill switches no nível de kernel?

Custo de implementação. Nível-kernel requer código específico de plataforma: filtros WFP no Windows, regras pf no macOS, integração de rede de kernel no Linux. Cada plataforma requer engenharia separada. Implementações no nível de aplicação funcionam em toda plataforma com o mesmo código. Pra provedores de VPN servindo mercados de consumidor amplos, o investimento de engenharia em nível-kernel não foi historicamente prioridade.

Persistência em boot vai quebrar meu computador?

Vai prevenir seu computador de alcançar a internet durante boot até a VPN iniciar. Pra maioria dos usuários isso é irritante mas não quebrado — a VPN inicia, o sistema alcança a internet. Pra usuários em redes corporativas onde processos de boot precisam de acesso à internet (juntar domínios corporativos, sincronizar com servidores de tempo corporativos, baixar atualizações de mirrors internos), persistência em boot pode interferir. Teste antes de habilitar.

E quanto a kill switch só pra apps específicos?

Alguns clientes VPN deixam você configurar o kill switch pra se aplicar a apps específicos em vez de todo tráfego. Útil quando quer algum tráfego ir pela VPN com proteção de kill switch (apps de trabalho) e outro tráfego ir ao redor da VPN (streaming). Fexyn não suporta atualmente kill switch por app; enviamos a abordagem tudo-ou-nada. Mullvad e ProtonVPN têm opções por app mais granulares.

Posso confiar num "kill switch" que não posso testar?

Teste. O custo de testar é minutos; o custo de um kill switch que não funciona de fato é o que o tráfego vazado expôs. Qualquer kill switch que não pode ser testado pelo usuário é uma alegação de marketing, não um recurso verificado.

Experimente o Fexyn grátis por 7 dias — kill switch baseado em WFP nível-kernel no Windows, com persistência em boot opcional. VPN pra torrent e VPN pra advogados cobrem os casos de uso onde isso mais importa.

Última revisão 2026-05-09.