Tasker: conecta a VPN antes de abrir un URL privado
Tasker debe conectarse e agardar antes de abrir un URL privado: define a dispoñibilidade, usa a interface de control do cliente e mantén a conexión permanente para un límite ríxido.
Abrir un URL privado e confiar en que o túnel suba primeiro é unha carreira, e o navegador adoita gañar. Un atallo que reacciona a unha páxina que xa se está cargando perdeu a consulta DNS e a miúdo a primeira conexión, que é xusto a parte que necesitaba a VPN. O fluxo de traballo debe posuír a orde en lugar de observala. Tres condicións deciden se ese fluxo pertence a Tasker.
Un único punto de entrada debe posuír a secuencia
Dálle ao servizo privado un único punto de entrada aprobado e deixa que ese punto execute os pasos en orde. Valida o destino, selecciona o perfil previsto, solicita a conexión, agarda un resultado de dispoñibilidade cun límite de canto vas agardar e só entón abre o URL. Se falla calquera paso, detente e dío en lugar de pasar a unha apertura directa.
Esa última cláusula é a que a xente salta. Un fluxo que abre o URL de todos os xeitos ao esgotarse o tempo é peor que non ter automatización, porque produce unha petición que parece unha VPN fallida cando nunca usou ningunha.
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 de arriba é o contrato, non un perfil exportado. Cada cliente implementa a súa superficie de control de forma distinta, e algúns requiren un complemento, un permiso de control explícito ou un consentimento único do usuario que ningunha automatización pode achegar.
Conectado non é o mesmo que listo
Un estado que di que o túnel se iniciou demostra que o cliente aceptou a petición. Non demostra que o resolutor devolva agora enderezos privados nin que o servizo previsto sexa alcanzable. Son resultados separados, e a fenda entre eles é onde un atallo que abre demasiado pronto falla en silencio. O cliente informa do seu propio estado, non do estado da ruta que usará o URL.
Define a dispoñibilidade fronte a algo que o fluxo poida observar. Un estado de conexión do cliente, un enderezo resolto do rango esperado ou unha sonda de alcanzabilidade ao servizo concreto funcionan, sempre que a sonda non poida recaer na ruta de rede ordinaria. Unha sonda que ten éxito pola ruta normal non che di nada.
Limita a espera. Unha condición de dispoñibilidade sen tempo de espera converte un perfil roto nun atallo que se colga, e os usuarios denúnciano como o teléfono conxelándose, non como un problema de VPN.
Que pode e que non pode facer Tasker
Tasker achega o pegamento: un disparador, unha lista ordenada de accións, condicións e unha acción de URL. A súa acción de abrir URL realiza só o paso de apertura e nada máis. O paso de conexión ten que vir do cliente de VPN, mediante un complemento, un intent ou un servizo exposto que o cliente documente e permita.
OpenVPN for Android, por exemplo, documenta unha interface de control remoto construída sobre AIDL e intents. Iso é unha capacidade dese cliente, non unha licenza para que calquera tarefa do dispositivo o controle. Concede o control só á aplicación que pretendes, porque unha capa de automatización que pode conectar e desconectar un túnel é unha superficie de control que merece protección.
Se o cliente instalado non expón ningún mecanismo de control compatible, a resposta honesta é que este fluxo non se pode construír sobre ese cliente. Unha páxina antiga de comparación de funcións non é unha especificación de capacidades para a versión do teléfono.
Cando o límite debe ser obrigatorio
A automatización é unha comodidade, e unha comodidade non pode impoñer un límite de seguridade. Se o requisito é que as aplicacións cubertas nunca se comuniquen sen a VPN, usa o axuste de VPN permanente e bloqueo da plataforma, ou a configuración xestionada equivalente. Un evento do navegador que se dispara despois de que a navegación comezase non pode substituír esa imposición, por coidadosamente ordenada que estea a tarefa.
Decide cal dos dous constrúes. Un atallo que conecta primeiro e logo abre é útil e non é unha garantía. Un dispositivo xestionado co bloqueo activado é unha garantía e non necesita ningunha secuencia de Tasker.
| Requirement | Mechanism |
|---|---|
| Open the page after the tunnel is ready | Ordered task with a bounded readiness wait |
| Never allow traffic outside the tunnel | Always-on VPN with blocking, or managed policy |
| Only some apps use the tunnel | Per-app VPN or work-profile scope |
| Different URL every time | Validate the input before opening it |
Proba tres desenlaces, non un
Executa o fluxo contra unha conexión correcta, un tempo de espera deliberado e unha reconexión ordinaria tras a caída do túnel. O caso do tempo de espera é o que revela se a secuencia se detén de verdade, e o caso da reconexión revela se a dispoñibilidade se comproba ou só se supón a partir dun éxito anterior. Executa primeiro o caso do tempo de espera, porque un fluxo que ignora o fallo non merece ser probado para o éxito.
Permite só destinos da lista aprobada, e comproba calquera ligazón que chegue de fóra antes de abrila. Unha tarefa que acepta ligazóns arbitrarias convértese nunha forma de lanzar esquemas inesperados, e unha páxina de administración privada alcanzada así é un resultado peor que un atallo fallido.
Anota o perfil, a condición de dispoñibilidade e o tempo de espera xunto á tarefa. A seguinte persoa que cambie o cliente de VPN necesitará as tres cousas, e ningunha delas se ve desde a icona do atallo.