Tasker: ligue a VPN antes de abrir um URL privado

Abrir um URL privado e esperar que o túnel suba primeiro é uma corrida, e o navegador costuma ganhar. Um atalho que reage a uma página que já está a carregar perdeu a consulta DNS e muitas vezes a primeira ligação, que é exatamente a parte que precisava da VPN. O fluxo de trabalho tem de possuir a ordem em vez de a observar. Três condições decidem se esse fluxo pertence ao Tasker.

Um único ponto de entrada deve possuir a sequência

Dê ao serviço privado um único ponto de entrada aprovado e deixe esse ponto executar os passos por ordem. Valide o destino, selecione o perfil pretendido, peça a ligação, aguarde um resultado de prontidão com um limite de quanto vai esperar e só então abra o URL. Se qualquer passo falhar, pare e diga-o em vez de passar a uma abertura direta.

É essa última cláusula que as pessoas saltam. Um fluxo que abre o URL mesmo assim ao esgotar o tempo é pior do que nenhuma automatização, porque produz um pedido com o aspeto de uma VPN falhada quando nunca usou nenhuma.

1. validate destination against the approved list
2. select the intended VPN profile
3. request connection through the client's supported interface
4. wait for readiness, maximum 20 seconds
5. open the URL only if readiness succeeded
6. on timeout, stop and report

A lista numerada acima é o contrato, não um perfil exportado. Cada cliente implementa a sua superfície de controlo de forma diferente, e alguns exigem um plugin, uma permissão de controlo explícita ou um consentimento único do utilizador que nenhuma automatização pode fornecer.

Ligado não é o mesmo que pronto

Um estado que diz que o túnel arrancou prova que o cliente aceitou o pedido. Não prova que o resolvedor devolva agora endereços privados nem que o serviço pretendido esteja acessível. São resultados separados, e a lacuna entre eles é onde um atalho que abre demasiado cedo falha em silêncio. O cliente relata o seu próprio estado, não o estado do caminho que o URL vai usar.

Defina a prontidão em relação a algo que o fluxo possa observar. Um estado de ligação do cliente, um endereço resolvido a partir do intervalo esperado ou uma sonda de acessibilidade ao serviço concreto funcionam, desde que a sonda não possa recair no caminho de rede comum. Uma sonda que tem sucesso pela rota normal não lhe diz nada.

Limite a espera. Uma condição de prontidão sem tempo limite transforma um perfil avariado num atalho que fica pendurado, e os utilizadores relatam isso como o telemóvel a congelar, não como um problema de VPN.

O que o Tasker pode e não pode fazer

O Tasker fornece a cola: um acionador, uma lista ordenada de ações, condições e uma ação de URL. A sua ação de abrir URL executa apenas o passo de abertura e nada mais. O passo de ligação tem de vir do cliente de VPN, através de um plugin, um intent ou um serviço exposto que o cliente documente e permita.

O OpenVPN for Android, por exemplo, documenta uma interface de controlo remoto construída sobre AIDL e intents. Isso é uma capacidade desse cliente, não uma licença para qualquer tarefa do dispositivo o controlar. Conceda o controlo apenas à aplicação que pretende, porque uma camada de automatização que consegue ligar e desligar um túnel é uma superfície de controlo que vale a pena proteger.

Se o cliente instalado não expõe qualquer mecanismo de controlo suportado, a resposta honesta é que este fluxo não pode ser construído sobre esse cliente. Uma página antiga de comparação de funcionalidades não é uma especificação de capacidades para a versão que está no telemóvel.

Quando o limite tem de ser obrigatório

A automatização é uma comodidade, e uma comodidade não pode impor um limite de segurança. Se o requisito é que as aplicações abrangidas nunca comuniquem sem a VPN, use a definição de VPN sempre ativa e bloqueio da plataforma, ou a configuração gerida equivalente. Um evento do navegador que dispara depois de a navegação ter começado não pode substituir essa imposição, por mais cuidadosamente ordenada que esteja a tarefa.

Decida qual está a construir. Um atalho que liga primeiro e depois abre é útil e não é uma garantia. Um dispositivo gerido com o bloqueio ativado é uma garantia e não precisa de sequência nenhuma do Tasker.

Teste três desfechos, não um

Execute o fluxo contra uma ligação bem-sucedida, um tempo limite deliberado e uma religação normal após a queda do túnel. O caso do tempo limite é o que revela se a sequência realmente para, e o caso da religação revela se a prontidão é verificada ou apenas assumida a partir de um sucesso anterior. Execute primeiro o caso do tempo limite, porque um fluxo que ignora a falha não merece ser testado para o sucesso.

Permita apenas destinos da lista aprovada e verifique qualquer ligação que venha de fora antes de a abrir. Uma tarefa que aceita ligações arbitrárias torna-se uma forma de lançar esquemas inesperados, e uma página de administração privada alcançada assim é um resultado pior do que um atalho falhado.

Anote o perfil, a condição de prontidão e o tempo limite junto à tarefa. A próxima pessoa que alterar o cliente de VPN vai precisar dos três, e nenhum deles é visível a partir do ícone do atalho.