Um kill switch de VPN sobrevive a um reinício? Como verificar

Reiniciar é a forma mais comum de as pessoas testarem um kill switch, e é o teste que mente com mais frequência. A caixa de seleção no cliente é uma preferência; o que importa é se algo impõe um bloqueio entre o momento em que a pilha de rede sobe e o momento em que o túnel está realmente estabelecido. No Windows essa coisa costuma ser um filtro no Windows Filtering Platform, no Linux um conjunto de regras carregado por uma unidade, no macOS uma âncora de pf, no Android os próprios sinalizadores do sistema para always-on e bloqueio. Esses arranjos comportam-se de forma muito diferente ao longo de um reinício, e apenas os de nível de plataforma estão no lugar antes de alguém poder iniciar sessão.

Um reinício coloca três perguntas separadas

Divida a pergunta. Primeiro, a política existe no disco numa forma que algo lê no arranque? Segundo, esse leitor corre antes de qualquer tráfego poder sair? Terceiro, a política cobre o tráfego que lhe importa, ou seja, cada processo, as duas famílias de endereços e o DNS. Um sim à primeira e um não à segunda produzem exatamente a falha que as pessoas relatam como um kill switch que não sobrevive a um reinício: o tráfego escapa durante alguns segundos no arranque, e ninguém nota até alguém ir verificar.

Mantenha as camadas separadas. Um conjunto de regras de firewall guardado, um serviço que arranca com o sistema e uma preferência do cliente são três objetos diferentes com três vidas diferentes. A preferência sobrevive aos reinícios porque é um valor num ficheiro de configuração. As regras são a única coisa que bloqueia pacotes, e desaparecem com o kernel que as segurava.

Encontre o objeto que restaura o bloqueio

No Linux as regras de netfilter vivem no kernel. Nada as reescreve no arranque a menos que você o tenha preparado: iptables-save mais netfilter-persistent, nftables.service carrega /etc/nftables.conf, ou uma unidade systemd que executa o seu próprio script. Verifique o que está ativado em vez do que se lembra de ter configurado.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

Um conjunto de regras vazio uns segundos depois do arranque é a resposta à pergunta do título. No Windows pergunte ao serviço do cliente como arranca e depois extraia o estado do filtro da plataforma enquanto o túnel está em baixo.

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

O segundo comando escreve wfpstate.xml no diretório atual. Procure filtros com uma ação de bloqueio que já existam antes de o cliente se ligar. O Base Filtering Engine arranca cedo e restaura os filtros adicionados com o sinalizador persistente, por isso alguns kill switches bloqueiam o tráfego antes de existir qualquer janela de cliente e outros não. No macOS, sudo pfctl -s info informa se o pf está ativado, sudo pfctl -s rules mostra o que está carregado, e os clientes de VPN costumam ligar as suas regras a uma âncora em vez de ao conjunto principal. Uma regra que nomeia utun3 pode apontar para outra interface após o arranque seguinte, porque esse número é atribuído em tempo de execução.

Observe o intervalo entre a rede a subir e o túnel a subir

O intervalo perigoso não é todo o reinício, é o intervalo. A interface recebe um aluguer e uma rota predefinida num momento, o serviço de VPN arranca noutro, e o túnel autentica-se ainda mais tarde, às vezes só depois de um utilizador iniciar sessão e de um agente de credenciais correr. Se o bloqueio for aplicado por último, tudo o que está no intervalo sai em claro.

Em máquinas com systemd, leia a ordem em vez de a adivinhar. Execute systemctl cat nas unidades de VPN e de firewall e procure After= ou Before= face a network-pre.target e network-online.target. Uma unidade de firewall ordenada depois de network-online.target perde contra a interface; a que é exigida por e ordenada antes de network-pre.target ganha. No Windows as perguntas equivalentes são o tipo de arranque do serviço e as suas dependências, porque um serviço definido como Manual não pode bloquear um processo no arranque. Se o seu requisito inclui tráfego antes do início de sessão, só um arranjo ao nível do dispositivo o satisfaz: um túnel de dispositivo Always On VPN autentica-se com um certificado de máquina e liga-se antes de o utilizador iniciar sessão, e a Microsoft documenta a configuração do túnel de dispositivo separadamente do túnel de utilizador. O Android segue o outro caminho, impondo VPN always-on e bloqueando as ligações sem ela a partir do sistema e não de um processo de aplicação.

Execute o teste e depois compare duas cronologias

Reinicie com um destino que não custa nada se escapar, e capture o estado durante o intervalo em vez de depois. O método mais limpo é uma sonda de arranque: uma unidade oneshot ou uma tarefa agendada que arranca o mais cedo que a plataforma permite, registra a rota predefinida e o estado da firewall, tenta um pedido com um tempo limite curto e acrescenta uma linha a um ficheiro local. Compare esse registo com a hora de arranque do serviço de VPN de journalctl -b -u ou do registo do sistema.

Depois faça o teste habitual: túnel em cima, corte a ligação, veja se o tráfego direto é bloqueado, restaure. Passar o segundo e falhar o primeiro é o resultado normal, e significa que a imposição é do lado do cliente, aplicada quando o cliente se liga e não no arranque. Na última máquina que auditei, o bloqueio vinha de um script despachante do NetworkManager: presente e correto e inútil para os segundos antes de a interface subir. Anote os dois resultados, porque sobreviver a um reinício só significa algo quando diz que camada sobreviveu e a partir de que momento.

Feche o intervalo sem cortar o seu caminho de volta

Se o bloqueio faltar no arranque, desça a imposição uma camada em vez de acrescentar uma segunda regra de cliente. Guarde o conjunto de regras e carregue-o a partir de uma unidade ordenada antes de a rede estar utilizável, e garanta que essa unidade não precisa de uma consulta DNS nem de uma montagem de rede que supostamente protege. O alcance importa tanto como o momento: as regras que correspondem a um ID de utilizador ou a um cgroup deixam todos os daemons do sistema fora do bloqueio, e um conjunto de regras que só trata de IPv4 deixa o IPv6 e o DNS acessíveis.

Deixe-se um caminho de volta. Uma máquina que bloqueia tudo no arranque e depois não consegue autenticar-se não tem rede nenhuma, e a correção não é apagar o bloqueio mas reparar a credencial ou a ordem. Mantenha um procedimento documentado de consola local e uma exceção estreita e deliberada para o que o túnel realmente precisa, como o endereço do servidor e o resolvedor usado antes de o túnel existir.

Antes de confiar na configuração, confirme quatro coisas por ordem. A política está guardada onde o arranque lê. Esse leitor corre antes de a interface estar utilizável. O bloqueio cobre as duas famílias de endereços e o DNS. A VPN ainda consegue autenticar-se enquanto o bloqueio está ativo. Quando as quatro se verificam, um reinício não muda nada.