Always-on VPN ou kill switch: o que você realmente ativou?

Always-on e kill switch ficam a duas linhas de distância na mesma tela de configurações, então as pessoas leem os dois como dois nomes de um único recurso. Não são. O always-on é uma política de reconexão: inicia o túnel na inicialização, traz ele de volta depois de um travamento ou de uma troca de rede e segue tentando enquanto falha. O kill switch é uma política de tráfego: nomeia os pacotes que ainda podem sair da máquina enquanto o túnel está fora. Você pode ativar o primeiro sem o segundo, e na maioria das plataformas o resultado padrão ainda deixa tráfego sair nessa lacuna.

Verificação 1: o bloqueio é um interruptor próprio?

No Android 10 e posteriores, um perfil de VPN salvo abre dois interruptores independentes atrás do ícone de engrenagem: Always-on VPN e Block connections without VPN. Apenas o segundo é o kill switch. Com apenas o always-on o túnel realmente volta depois de uma queda, e qualquer aplicativo no meio de uma requisição pode alcançar a rede por Wi-Fi ou dados móveis até que isso aconteça.

Dispositivos gerenciados mantêm a mesma divisão na API de políticas. setAlwaysOnVpnPackage() recebe o nome do pacote e um flag lockdownEnabled; um administrador que define o pacote e deixa o flag em false construiu um túnel persistente, não um dispositivo fechado. O texto do console raramente torna essa diferença visível.

Leia o estado no dispositivo, não no console: adb shell settings get global always_on_vpn_app e adb shell settings get global always_on_vpn_lockdown. Se o primeiro devolver null, nenhum pacote é imposto no nível da plataforma; se o segundo devolver 0, a plataforma não está bloqueando nada. O guia de VPN do Android documenta isso como recursos separados, não como um único modo.

Verificação 2: qual camada é dona do bloqueio?

Os rótulos vivem no cliente e os bloqueios normalmente no firewall, e é por isso que a mesma palavra significa coisas diferentes em cada plataforma. As linhas abaixo são as que vale confirmar antes de confiar em qualquer uma delas.

O Windows é o exemplo mais claro de um rótulo que não bloqueia. Ali o Always On descreve a persistência do túnel: um túnel de dispositivo para autenticação da máquina e um túnel de usuário para a conta conectada, configurados por XML de perfil ou Add-VpnConnection. Nada nesse perfil impede um pacote de saída quando o túnel falta, e a filtragem de saída não vem ativada por padrão, então um notebook no Wi-Fi continua funcionando enquanto a VPN está fora.

O WireGuard se divide do mesmo jeito, mas por cliente. O WireGuard for Windows tem uma opção Block untunneled traffic por túnel que instala regras de filtro; as ferramentas de Linux não têm interruptor equivalente. O wg-quick adiciona uma rota para cada entrada AllowedIPs e uma regra fwmark, e o wg-quick down remove as duas, então a rota padrão física assume de novo sem perder um único pacote.

Nas plataformas da Apple, o always-on chega como recurso de perfil de gerenciamento para dispositivos supervisionados e se expressa como regras on-demand, não como caixa de seleção. A pergunta a responder a partir do payload é se um túnel que falha nega tráfego ou apenas pede outra conexão. O título do menu não vai dizer.

Verificação 3: meça a lacuna, não o ícone

Quatro transições importam, e elas falham de formas diferentes: a inicialização antes de alguém entrar, suspensão e retomada, a troca de Wi-Fi para dados móveis e um travamento do cliente que deixa a interface do túnel meio configurada. Uma reconexão limpa em uma delas não prova nada sobre as outras três.

O teste mais barato para o túnel de propósito e depois tenta sair. Com o túnel fora, curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com devolvendo 200 significa que a política é fail-open; um tempo esgotado ou uma conexão recusada significa que algo ainda está bloqueando. ip route get 1.1.1.1 nomeia a interface que carregaria o pacote, o que costuma informar mais que o ícone da bandeja, e systemctl status wg-quick@wg0 mostra se a interface foi removida de forma limpa.

Rode a mesma verificação numa segunda janela enquanto a rede muda, não apenas depois que ela se estabiliza. O intervalo entre a queda e a nova tentativa é a parte que importa, e a resolução de nomes é o jeito mais rápido de perceber que o tráfego escapou: se o resolvedor local responde com o túnel fora, o bloqueio não está completo.

Verificação 4: decida as exceções antes de trancar

Duas exceções são estruturais. O cliente precisa alcançar o próprio servidor VPN, então um conjunto de regras que descarta tudo também impede a reconexão que restauraria a proteção. Um portal cativo também não é alcançável por um túnel que não está no ar, então um dispositivo trancado no Wi-Fi do hotel precisa de um jeito documentado de abrir o portal, não improvisado.

Uma forma mínima, endpoint permitido e todo o resto descartado:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

Trate essa linha do endpoint como variável, não como constante. Provedores trocam endereços, e uma exceção desatualizada é o motivo comum de um kill switch que funcionava virar um dispositivo que não reconecta. Impressoras locais, compartilhamentos NAS e serviços de desenvolvimento pertencem à mesma lista escrita, senão são descobertos um chamado de suporte por vez.

Verificação 5: registre o que você realmente provou

Mantenha uma tabela de quatro colunas e preencha testando: estado, comportamento esperado, comportamento observado, evidência. As linhas são as transições da verificação 3 mais uma falha deliberada. Uma linha que você não consegue preencher com saída de comando é uma linha que não foi testada, e um dispositivo que passa na linha de reconexão mas falha na linha de inicialização é comum o bastante para valer os dez minutos extras.

Antes de chamar de pronto:

• Confirme que a configuração de bloqueio é separada da de reconexão e leia o valor dela no dispositivo.
• Saiba qual camada aplica o bloqueio - opção do cliente, política do dispositivo ou firewall - e onde essa camada é configurada.
• Guarde um comando de verificação que prove o bloqueio e rode durante uma transição, não depois.
• Escreva a lista de exceções, endpoint incluído, e anote quem a atualiza.
• Em hardware gerenciado, deixe a política imposta em paz; remover o bloqueio muda o requisito em vez de consertar o túnel.