Script de derrubada ou regra de firewall: qual interrompe a fuga?

Dois projetos prometem a mesma coisa: quando o túnel cai, nada sai em claro. Um executa um script na derrubada e corta as interfaces. O outro deixa uma regra de firewall em vigor e não pede nada ao cliente VPN. Diferem em quem tem o privilégio de agir, no que acontece durante a lacuna e em como a máquina volta a ficar online depois. Compará-los nesses três pontos é mais útil do que discutir qual é mais rigoroso.

O mesmo trabalho por dois mecanismos

O cliente pode executar gatilhos quando o túnel sobe e quando é derrubado, desde que o perfil permita a execução de scripts. Esse gatilho corre dentro do ciclo de vida do cliente, no momento em que a conexão se fecha. Uma regra de firewall, por outro lado, pertence ao sistema e não se importa se o cliente está a correr, falhou ou foi morto.

Essa tabela é todo o argumento. Um script que só corre num encerramento limpo cobre o caso que menos o preocupava; o caso que importa é a falha ou a rede que desaparece, e nenhum dos dois produz uma derrubada limpa.

O que o gatilho de derrubada pode e não pode fazer

O padrão documentado percorre as interfaces de rede e derruba tudo excepto loopback. Com o dispositivo físico em baixo, nada pode escapar para fora do túnel, e é exatamente essa a intenção.

#!/bin/sh
for dev in /sys/class/net/*; do
  name=$(basename "$dev")
  [ "$name" = lo ] || ip link set dev "$name" down
done

Também derruba a rede local, qualquer serviço que a máquina aloje e o caminho que usaria para corrigir o problema. Num portátil, o dispositivo sem fios às vezes precisa de uma comutação manual depois, pelo que uma breve interrupção se torna uma sessão de reparação. Pior ainda, o gatilho pode não ter permissão para fazer nada disso: quando o cliente abdica dos privilégios, o script de derrubada corre com a conta sem privilégios e cada alteração de interface falha com um erro de permissões escrito no momento em que ninguém lê o registo.

Verifique como o cliente é iniciado antes de confiar no gatilho. Um script que funciona quando o executa à mão como root não prova nada sobre o serviço que arranca no arranque.

O que a regra de firewall faz de diferente

Uma regra que só permite o tráfego do túnel continua a funcionar quando o processo do cliente desapareceu, porque o kernel não depende desse processo. A regra também é mais estreita: bloqueia exatamente os fluxos que correspondem e deixa em paz loopback, a sub-rede local e o caminho de recuperação, e é por isso que não deixa a máquina isolada.

O preço é que a regra tem de ser escrita e mantida por quem possui a firewall do anfitrião, e tem de nomear o dispositivo de túnel que o cliente cria de facto. Isso significa que a regra e o perfil têm de ser mantidos em conjunto; uma interface renomeada deixa uma firewall que bloqueia tudo e não explica nada.

Nenhum dos mecanismos torna o outro redundante. Uma regra de firewall que nunca é recarregada após uma edição é tão fictícia como um script que nunca corre.

persist-tun decide se existe uma lacuna

Quando o dispositivo de túnel sobrevive a uma desconexão, as rotas que apontam para ele também sobrevivem. O tráfego é então descartado em vez de redirecionado, pelo que a rota predefinida não recua para a gateway física. É este comportamento que torna uma fuga improvável ainda antes de qualquer regra de firewall entrar em jogo.

Sem essa definição, o dispositivo é removido e as rotas com ele, e a rota predefinida pode voltar a apontar para a gateway física. Se o faz depende da plataforma e do cliente, e é precisamente por isso que o estado tem de ser observado em vez de assumido. Trate a definição como parte do kill switch, não como uma opção de desempenho.

Mantenha o caminho de reconexão vivo e depois teste quatro estados

Um bloqueio estrito também pode impedir o cliente de se reconectar, porque o cliente continua a precisar de uma rota para o servidor através da gateway física enquanto tudo o resto é negado. Instale uma rota de anfitrião para esse único endereço antes de o túnel subir, e resolva o nome primeiro, porque o DNS pode estar bloqueado na altura em que precisar dele.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Depois verifique os estados e não o rótulo. Exercite quatro momentos de propósito: um arranque a frio sem túnel, uma sessão saudável, uma queda que ninguém pediu e a sessão depois de recuperar. Em cada momento leia a rota predefinida e faça um pedido cujo endereço de saída seja visível. Uma aplicação que desiste enquanto o túnel está em baixo não diz nada sobre um cliente de correio ou um atualizador, por isso repita a última verificação com uma aplicação em segundo plano. Anote a regra, os nomes das interfaces e os passos de recuperação, porque um kill switch que ninguém consegue verificar é um rumor.