Fexyn
Fexyn
All posts

O que um VPN kill switch realmente faz

Fexyn Team··6 min read

VPN kill switch é uma feature que bloqueia todo o tráfego de internet quando a conexão VPN cai. O objetivo: que seu IP real não vaze enquanto o cliente reconecta. Toda VPN diz que tem um. A maioria não funciona.

O problema é onde o kill switch vive. Se ele vive dentro do app da VPN — só consegue reagir depois que o app perceber a queda. Isso é código de userland numa corrida com um SO que já roteou seus pacotes.

A janela de 200ms da qual ninguém fala

O que acontece quando o túnel VPN cai sem kill switch no nível do kernel:

  1. O endpoint remoto para de responder. Talvez o servidor reiniciou, talvez a rede mudou, talvez aconteceu um routing flap.
  2. O cliente leva de 200ms a alguns segundos pra perceber. A maioria dos clientes usa health-check estilo heartbeat. WireGuard manda ping a cada 25 segundos por padrão. O keepalive do OpenVPN é configurável mas geralmente fica entre 10-60 segundos.
  3. Naquela janela, o sistema operacional ainda acha que o túnel tá aberto. Continua roteando o tráfego pra interface do túnel.
  4. A interface do túnel descarta os pacotes — mas em algumas configurações, o fallback routing entra em ação e os pacotes saem pela sua interface real. Seu navegador continua mandando requisições, seu cliente de email continua dando poll, seus clientes de IM mantêm sessões TCP vivas.
  5. Os servidores destino logam seu IP real. O serviço de streaming atualiza o registro de sessão. Seu provedor vê a query DNS em texto puro que deveria ser resolvida dentro do túnel.

Quando o cliente VPN acorda e dispara o kill switch userland — o vazamento já aconteceu.

A maioria dos kill switches de VPN é assim. Ativam depois do evento.

Onde um kill switch de verdade vive

O kill switch no nível do kernel não vive no processo do cliente VPN — ele fica no network stack do sistema operacional. No Windows isso é Windows Filtering Platform — a mesma firewall API que o Windows Defender Firewall usa. No macOS, Network Extension framework. No Linux, regras nftables/iptables com hooks PF_INET.

Três propriedades fazem isso funcionar:

Entra antes do VPN handshake completar. Quando você aperta Connect, os filtros do kill switch são montados primeiro. O handshake passa por um buraco que o kill switch abriu especificamente pro VPN endpoint. Se o handshake falhar, nada sai pra fora.

Sobrevive a crash do cliente. Se o processo do app VPN morrer, o kill switch continua bloqueando. Kill switches userland morrem junto com seus apps — e o Windows restaura o roteamento normal alegremente no momento que o app sai.

Sobrevive a mudanças de rede, sleep e resume. Trocar de Wi-Fi pra ethernet, fechar a tampa, hibernar, trocar de hotspot — todos esses são eventos que um in-app kill switch precisa tratar como mudanças de state separadas. Regras WFP ficam abaixo disso. Permanecem no lugar até serem explicitamente removidas por um processo autorizado.

Como o Fexyn implementa

O cliente Windows do Fexyn divide em duas partes: a UI com permissões de usuário e o helper service com permissões SYSTEM. Só o helper service é dono dos filtros WFP. Quando você aperta Connect:

  1. O helper service monta os filtros WFP — bloqueia todo o tráfego outbound exceto: (a) loopback, (b) o VPN endpoint:port específico, e (c) DHCP/DNS pro gateway local pro handshake.
  2. O VPN handshake passa por aquele buraco aberto.
  3. Quando o túnel sobe, a routing table manda tudo pra interface do túnel. Os filtros WFP ficam no lugar; só não veem a maior parte do tráfego porque o túnel agora é o caminho de menor resistência.
  4. Se o túnel cair, a routing table perde a route do túnel. O tráfego volta pra interface default. Os filtros WFP bloqueiam. Seu navegador mostra erro de "sem internet". Seu IP real fica escondido.
  5. Quando o helper reconecta com sucesso, o novo endpoint do túnel pode ser diferente. O helper atualiza o carve-out, o tráfego flui de novo.

O usuário não desativa nada. A UI nunca pede admin. O kill switch não depende da UI estar viva.

O que isso significa na prática para o Brasil

No Brasil, operadoras como Vivo, Claro e TIM podem entregar logs de conexão mediante ordem judicial sob o Marco Civil da Internet (Lei 12.965/2014). Provedores são obrigados a guardar logs de conexão por 12 meses. Se o túnel cair — o que pode acontecer em eventos de rede problemáticos — e seu IP real vazar, seu provedor tem registro do que você fez naquela janela.

Kill switch no nível do kernel fecha aquela janela de vazamento. Abre o Wireshark e force uma queda do VPN (puxe a rede, troque o Wi-Fi, suspenda). Com kill switch userland você vai ver, depois da queda por um tempo — geralmente 200ms a alguns segundos — pacotes fluindo pela interface de baixo. Com kill switch baseado em WFP, você não vê nada até o túnel reconectar ou até desligar o kill switch explicitamente.

O segundo é o que você quer.

O que kill switch não resolve

Kill switch resolve um problema específico: vazamento de tráfego durante transições de túnel. Não:

  • Não protege endpoint comprometido. Se seu laptop está infectado, o malware vê o tráfego antes do kernel ver.
  • Não para vazamentos de DNS sozinho. Prevenção de DNS leak é uma camada separada (NRPT no Windows, force-DNS-through-tunnel na config do protocolo). Kill switch sozinho não corrige DNS mal configurado.
  • Não previne vazamentos WebRTC. WebRTC do navegador opera acima do nível de rede; o navegador sabe seu IP real independente do que a rede vê. Fix completamente diferente.

Perguntas ao avaliar uma VPN

Se você está avaliando o kill switch de uma VPN, as perguntas são:

  1. Entra antes do handshake completar, ou só depois?
  2. Sobrevive mesmo se o cliente VPN crashar?
  3. Regra de firewall no nível do kernel ou loop de reconexão userland?
  4. Permite loopback — pra seus servidores de dev local continuarem funcionando?

Respostas honestas geralmente não estão no marketing copy, estão na documentação do produto. O marketing copy sempre vai dizer "kill switch" — sem te contar de que tipo.

Para o Fexyn:

  • Baseado em WFP, nível de kernel
  • Entra antes do handshake
  • Sobrevive a crash do helper-service, sleep, resume e mudanças de rede
  • Permite loopback (127.0.0.0/8 e ::1) e link-local

Leitura relacionada

Experimente o Fexyn grátis por 7 dias. Kill switch é ligado por padrão — você não precisa ativar.

O que um VPN kill switch realmente faz | Fexyn VPN