Obrir una URL privada i esperar que el túnel s'aixequi primer és una cursa, i normalment guanya el navegador. Una drecera que reacciona a una pàgina que ja s'està carregant s'ha saltat la consulta DNS i sovint la primera connexió, que és justament la part que necessitava la VPN. El flux de treball ha de posseir l'ordre en lloc d'observar-lo. Tres condicions decideixen si aquest flux pertany a Tasker o no.

Un sol punt d'entrada ha de posseir la seqüència

Doneu al servei privat un únic punt d'entrada aprovat i deixeu que aquest punt faci els passos en ordre. Valideu la destinació, seleccioneu el perfil previst, sol·liciteu la connexió, espereu un resultat de disponibilitat amb un límit de quant esperareu i només després obriu la URL. Si falla qualsevol pas, atureu-vos i digueu-ho en lloc de passar a una obertura directa.

Aquesta última clàusula és la que la gent s'estalvia. Un flux que obre la URL igualment en esgotar-se el temps és pitjor que cap automatització, perquè produeix una petició que sembla una VPN fallida quan mai n'ha usat cap.

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

La llista numerada de dalt és el contracte, no un perfil exportat. Cada client implementa la seva superfície de control de manera diferent, i alguns requereixen un connector, un permís de control explícit o un consentiment únic de l'usuari que cap automatització pot proporcionar.

Connectat no és el mateix que a punt

Un estat que diu que el túnel s'ha iniciat demostra que el client ha acceptat la petició. No demostra que el resolutor torni ara adreces privades ni que el servei previst sigui abastable. Són resultats separats, i l'escletxa entre ells és on una drecera que obre massa aviat falla en silenci. El client informa del seu propi estat, no de l'estat del camí que farà servir la URL.

Definiu la disponibilitat respecte d'alguna cosa que el flux pugui observar. Un estat de connexió del client, una adreça resolta del rang esperat o una sonda d'abastabilitat al servei concret funcionen, sempre que la sonda no pugui recaure en el camí de xarxa ordinari. Una sonda que té èxit per la ruta normal no us diu res.

Limiteu l'espera. Una condició de disponibilitat sense temps d'espera converteix un perfil trencat en una drecera que es penja, i els usuaris ho denuncien com el telèfon que es congela, no com un problema de VPN.

Què pot fer Tasker i què no

Tasker aporta el pegament: un disparador, una llista ordenada d'accions, condicions i una acció d'URL. La seva acció d'obrir URL fa només el pas d'obertura i res més. El pas de connexió ha de venir del client de VPN, mitjançant un connector, un intent o un servei exposat que el client documenti i permeti.

OpenVPN for Android, per exemple, documenta una interfície de control remot basada en AIDL i intents. Això és una capacitat d'aquell client, no una llicència perquè qualsevol tasca del dispositiu el governi. Concediu el control només a l'aplicació que voleu, perquè una capa d'automatització que pot connectar i desconnectar un túnel és una superfície de control que val la pena protegir.

Si el client instal·lat no exposa cap mecanisme de control compatible, la resposta honesta és que aquest flux no es pot construir sobre aquell client. Una pàgina antiga de comparació de funcions no és una especificació de capacitats per a la versió del telèfon.

Quan el límit ha de ser obligatori

L'automatització és una comoditat, i una comoditat no pot imposar un límit de seguretat. Si el requisit és que les aplicacions cobertes no es comuniquin mai sense la VPN, feu servir la configuració de VPN permanent i bloqueig de la plataforma, o la configuració gestionada equivalent. Un esdeveniment del navegador que es dispara després que hagi començat la navegació no pot substituir aquesta imposició, per acurada que sigui l'ordre de la tasca.

Decidiu quin dels dos construïu. Una drecera que primer connecta i després obre és útil i no és una garantia. Un dispositiu gestionat amb el bloqueig activat és una garantia i no necessita cap seqüència de Tasker.

RequirementMechanism
Open the page after the tunnel is readyOrdered task with a bounded readiness wait
Never allow traffic outside the tunnelAlways-on VPN with blocking, or managed policy
Only some apps use the tunnelPer-app VPN or work-profile scope
Different URL every timeValidate the input before opening it

Proveu tres desenllaços, no un

Executeu el flux amb una connexió correcta, un temps d'espera deliberat i una reconnexió ordinària després que caigui el túnel. El cas del temps d'espera és el que revela si la seqüència s'atura de debò, i el cas de la reconnexió revela si la disponibilitat es comprova o només se suposa a partir d'un èxit anterior. Executeu primer el cas del temps d'espera, perquè un flux que ignora el fracàs no val la pena provar-lo per a l'èxit.

Permeteu només destinacions de la llista aprovada i comproveu qualsevol enllaç que arribi de fora abans d'obrir-lo. Una tasca que accepta enllaços arbitraris es converteix en una manera de llançar esquemes inesperats, i una pàgina d'administració privada assolida així és un resultat pitjor que una drecera fallida.

Anoteu el perfil, la condició de disponibilitat i el temps d'espera al costat de la tasca. La propera persona que canviï el client de VPN necessitarà les tres coses, i cap d'elles no es veu des de la icona de la drecera.

Articles relacionats