Duas funções são descritas com a mesma palavra e fazem trabalhos diferentes. A reconexão automática tenta trazer o túnel de volta, e pode consegui-lo num segundo enquanto os pedidos falham nesse intervalo. O interruptor decide o que acontece ao tráfego nesse intervalo. Ler um cliente como se os dois fossem uma só definição é como as pessoas acabam a confiar num ícone em vez de numa política.

Bloquear e reconectar são decisões separadas

Um cliente bloqueia apenas quando a perda é inesperada, depois reconecta e levanta o bloqueio. Outro mantém um bloqueio ao nível do sistema até alguém mudar uma definição à mão, e um terceiro trata uma desconexão deliberada como permissão para restaurar o acesso normal. São três comportamentos diferentes, e a documentação do fornecedor diz qual deles a sua versão implementa.

Importar um perfil não decide nada nesta questão. O mesmo perfil de servidor carrega-se em dois clientes com comportamentos de bloqueio opostos, porque o perfil transporta definições e não uma promessa. É também por isso que uma caixa de seleção no computador e um interruptor no telemóvel com etiquetas semelhantes podem implementar regras diferentes. Leia a descrição junto ao controlo na sua plataforma e depois teste o que ele faz.

O mesmo perfil comporta-se de forma diferente em dois clientes

As definições da aplicação OpenVPN Connect descrevem um modo de túnel que retém o tráfego comum apenas enquanto o cliente comunica um estado de pausa ou de reconexão, o que é mais estreito do que uma promessa geral sobre cada evento em cada plataforma. Leia os estados enumerados, não o nome do produto. Uma descrição escrita para uma versão de cliente não se transfere para o cliente de outro fornecedor.

O Android mostra a mesma palavra em dois controlos, porque a VPN sempre ativa e o bloqueio de ligações sem VPN são documentados em separado. Um cliente de computador com uma caixa de nome semelhante pode implementar algo mais estreito ou mais amplo do que qualquer um deles. Considere uma etiqueta partilhada em dois menus uma coincidência enquanto não tiver lido as duas descrições. Os dispositivos geridos acrescentam uma terceira camada, porque um perfil de dispositivo pode impor uma definição que o utilizador não vê nem pode anular.

Definições de plataforma parecidas não são equivalentes

Compare o controlo que vê com a política que se aplica de facto. Num dispositivo gerido, o interruptor visível pode estar cinzento, ou pode estar ativo enquanto um perfil de nível superior impõe o contrário. Peça a política efetiva e não a local, e obtenha a resposta por escrito.

Registe o que cada camada afirma antes de testar seja o que for, porque as duas discordam com frequência e essa discordância perde-se facilmente assim que os testes começam. Um dispositivo que bloqueia corretamente durante um teste pode estar a bloquear por um motivo que ninguém documentou.

Execute um evento de cada vez e registe o código

Teste um evento por execução, com um pedido inofensivo, e faça de cada tentativa um pedido novo em vez de uma página que talvez já esteja em cache. Os comandos abaixo descem o túnel, pedem uma página e mostram se a interface voltou.

ip link set tun0 down
curl -s -o /dev/null -w "%{http_code}\n" --max-time 5 https://example.com
ip -brief address show tun0

A tabela associa cada ação à observação que importa e à evidência que vale a pena guardar. Um pedido que falha dentro do tempo limite diz que o bloqueio entrou em ação; um pedido que passa diz que o tráfego encontrou outro caminho, que pode ser uma rota excluída e não um bloqueio desativado. Repita todo o conjunto depois de uma atualização de software significativa ou de uma mudança de política de encaminhamento, porque qualquer das duas pode alterar o ramo sem que nenhuma definição visível se mova. No fim, quer um comportamento de falha previsível, não um ícone tranquilizador.

What I doWhat I watchEvidence to keep
Bring the tunnel down by handWhether a fresh request fails at onceThe HTTP code and the client state at that second
Choose Disconnect in the clientWhether ordinary access returns on purposeThe same request succeeding with no tunnel up
Quit the app, then rebootWhether the block outlives the clientA request made from a clean boot
Move from Wi-Fi to cellularWhether DNS and IPv6 follow the policyThe resolver answer, the route table and the code again

Exceções, portais de convidados e o que um bloqueio não pode

O acesso à rede local é a exceção comum, e altera o alcance da promessa. Um cliente pode chegar a uma impressora na mesma sub-rede enquanto bloqueia tudo o resto, o que é razoável em casa e discutível numa rede de convidados. Decida se quer essa exceção antes de um incidente a descobrir por si.

Um bloqueio estrito também torna o início de sessão no portal de uma rede de convidados incómodo, porque o portal é exatamente o tráfego direto que o bloqueio existe para parar. Aprenda a forma suportada de autorizar a rede e depois restaure a política de propósito em vez de desligar controlos até uma página carregar. Guarde a resposta do resolver e a tabela de rotas na mesma nota, como abaixo. O que um interruptor não pode fazer é tornar o serviço anónimo, porque bloquear tráfego fora do túnel não diz nada sobre o que acontece lá dentro.

resolvectl query example.com
ss -tunp | grep -v tun0

Artigos relacionados