Interruptor de segurança ligado, uma aplicação excluída deliberadamente do túnel e os dois requisitos agora contradizem-se. Um diz que nada pode sair exceto pelo túnel, o outro diz que este programa deve ir direto. Cada cliente resolve esse conflito de forma diferente, e a página de definições raramente explica que regra vence. Escreva a política por aplicação antes de confiar em qualquer etiqueta.

Duas políticas, uma máquina

Um interruptor de segurança é uma promessa sobre a falha: quando o túnel não protege o tráfego, o tráfego para. O túnel dividido é uma promessa sobre a seleção: estes programas ou destinos usam o túnel, e aqueles não. A segunda promessa cria tráfego sobre o qual a primeira tem de decidir. Nenhuma promessa está errada; foram apenas escritas por pessoas diferentes para ameaças diferentes.

Há três resultados possíveis e só um é o que a implementação pretendia. A aplicação excluída pode ficar direta durante uma falha, o que respeita a divisão e quebra o interruptor. Pode ficar bloqueada com tudo o resto, o que respeita o interruptor e quebra a divisão. Ou pode ser bloqueada apenas às vezes, conforme a forma como a plataforma avalia a regra depois de uma interface desaparecer. É esse último caso que gera tickets.

Escreva a lista de aplicações antes da regra

Liste os programas que têm de usar o túnel, os que têm de ir diretos e os nomes ou destinos que nunca devem aparecer em nenhuma das listas. Inclua separadamente o comportamento do resolvedor e o lado IPv6, porque ambos podem seguir uma política diferente da do tráfego de páginas.

As regras por aplicação costumam corresponder a um executável ou a um pacote, não a um perfil dentro dele. Um perfil de navegador, uma janela privada e uma extensão não têm identidade de rede própria, por isso herdam o que o processo recebeu. Um processo auxiliar lançado por esse navegador pode não herdar a mesma regra de todo.

São precisas duas listas, não uma: o que o túnel deve transportar e o que nunca deve viajar fora dele por nenhum motivo. Uma aplicação que aparece nas duas é um conflito de requisitos e não um detalhe de implementação, e tem de ser resolvido antes de configurar o cliente.

O que o cliente faz durante uma falha

Algumas implementações bloqueiam as aplicações excluídas durante uma falha e repõem o acesso ao reconectar. Outras mantêm o caminho direto o tempo todo, o que é coerente com a divisão e mais fraco como propriedade de segurança. O bloqueio ao nível da plataforma pode anular por completo a seleção por aplicação do cliente. Essa diferença não é cosmética, porque decide se a aplicação excluída é uma exceção de política ou um buraco.

A VPN sempre ativa do Android com a opção de bloquear ligações sem VPN é o caso mais claro, porque é a plataforma que impõe o bloqueio e não o cliente, e o pacote excluído fica bloqueado com tudo o resto enquanto o túnel está em baixo. Um cliente de ambiente de trabalho que aplica exclusões por aplicação no seu próprio controlador deixa normalmente o processo excluído na interface física, porque nunca foi dono do tráfego desse processo. Os dois comportamentos são defensáveis e só um corresponde a um requisito que diga que a aplicação excluída tem de continuar utilizável. Pergunte que componente impõe a regra antes de interpretar o resultado.

Leia o comportamento do sistema operativo à sua frente, não a definição com o mesmo nome noutro sítio. As API de aplicação diferem, e uma caixa pode significar coisas estritamente diferentes num computador e num telefone. A versão também conta, porque o controlo de bloqueio mudou de ecrã entre versões do Android, e uma lista de exclusões do lado do cliente não é o mesmo controlo que um bloqueio de plataforma.

Três momentos: túnel ativo, túnel em baixo, reconexão

Use pedidos inofensivos em três momentos: enquanto o túnel funciona, durante a falha que lhe interessa e depois de reconectar. Um único resultado do navegador não consegue estabelecer o comportamento da aplicação excluída.

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --interface tun0 https://api.ipify.org
dig +short example.com

O endereço de saída mostra que caminho foi seguido, e o teste explícito de interface mostra o que acontece quando o túnel é a única saída disponível. Anote o resultado esperado ao lado de cada linha antes de executar qualquer uma delas, ou a saída será interpretada a posteriori.

Se uma aplicação excluída ficar offline, reveja a precedência de políticas antes de acrescentar uma permissão ampla na firewall, porque essa correção destrói a distinção que estava a testar. Se continuar direta, confirme que era a exceção documentada e não um retrocesso acidental. Para um requisito estrito de todo o dispositivo, encurte a lista de exceções até se poder testar à mão.

Artigos relacionados