Sair ou desligar: dois resultados diferentes da VPN

O menu oferece Desligar, a janela tem um botão de fechar e o gerenciador de tarefas oferece Finalizar tarefa. Cada um parece uma forma de parar a VPN, e cada um pode deixar a máquina num estado diferente. Um pode parar o túnel e deixar um bloqueio ativo, outro pode limpar tudo como parte de uma saída ordenada, e um terceiro pode apenas esconder a interface enquanto o componente em segundo plano continua em execução. Tratar tudo isso como sinônimos é exatamente como um teste de privacidade chega a uma conclusão errada sobre o que aconteceu.

A documentação do cliente é o único lugar confiável para saber qual é qual.

Quatro controles, possivelmente quatro comportamentos

Desligar normalmente desmonta o túnel enquanto o cliente permanece residente, o que significa que um serviço, um componente da bandeja ou uma regra do kill switch podem sobreviver ao clique. Muitos clientes então continuam bloqueando o tráfego porque a política deles diz que o dispositivo não deve cair para acesso direto enquanto o cliente estiver presente. Esse comportamento parece uma rede quebrada e é uma proteção deliberada.

Sair serve para encerrar a aplicação, e um cliente bem comportado remove as suas regras ao sair. Alguns desenhos deixam, em vez disso, um auxiliar separado que aplica a política, e isso é uma escolha, não um defeito. Fechar a janela é uma ação da interface sem efeito definido sobre o túnel, e Pausar, quando oferecido, é um quarto comportamento com regras próprias.

Uma queda do lado do servidor é um quinto caminho completamente diferente, e é o que os usuários encontram mais frequentemente na prática.

Leia o estado antes e depois de cada ação

Registre a lista de processos, o estado do serviço e as regras do firewall antes da ação, e repita o registro imediatamente depois. Comparar as duas listas mostra o que o controle realmente fez, sem depender da descrição que a própria interface dá.

systemctl status wg-quick@wg0 --no-pager
pgrep -a -f 'openvpn|wireguard|vpnagent'
ip link show | grep -E 'tun|wg'
nft list ruleset | grep -E 'drop|reject' | head -20
scutil --nc list

Se as regras desaparecem junto com o processo, o cliente era o dono delas. Se as regras permanecem quando o processo já não está, algo mais aplica a política, e encontrar esse componente vem antes de qualquer mudança. Anote o estado do serviço no mesmo momento, porque uma interface parada não diz nada sobre um serviço do sistema.

Uma desconexão manual não é um travamento

Desligar executa o caminho de encerramento previsto, e um travamento o ignora. Por isso os resultados de um não se transferem para o outro, então um teste que usou um item de menu não pode sustentar uma afirmação sobre o comportamento quando o cliente morre.

Da mesma forma, um travamento não diz nada sobre uma pausa temporária aprovada. Mantenha essas três perguntas separadas no plano de testes e em tudo o que for escrito depois. O caminho de encerramento também explica por que uma saída limpa pode remover regras que um travamento deixa para trás. O mesmo botão, outro código, outra evidência.

Escolha o estado indisponível de que você realmente precisa

Se o tráfego tem de permanecer bloqueado sempre que o túnel estiver fora, verifique esse requisito durante a ação específica que lhe importa, com tráfego inofensivo para um destino conhecido. Inclua as exclusões de aplicativos e as exceções de rede local, porque a aplicação para o dispositivo inteiro costuma ser mais estreita do que o nome sugere. Depois confirme o que acontece após uma reinicialização, porque é quando o estado obsoleto costuma aparecer.

Se o objetivo é o acesso direto comum, use o controle documentado em vez de matar processos ou desativar o firewall inteiro. Regras obsoletas deixadas por uma saída interrompida são um problema diferente de um bloqueio intencional, e precisam de outra recuperação.

Anote qual componente parou: o túnel, a aplicação visível ou a camada que aplica a política. Essa única frase evita a maior parte da confusão que esses controles criam.