Tasker : connecter le VPN avant d'ouvrir une URL privée
Tasker doit se connecter et attendre avant d'ouvrir une URL privée : définir la disponibilité, utiliser l'interface de contrôle du client et conserver le mode permanent pour une limite stricte.
Ouvrir une URL privée en espérant que le tunnel monte en premier est une course, et le navigateur gagne généralement. Un raccourci qui réagit à une page déjà en cours de chargement a manqué la résolution DNS et souvent la première connexion, soit exactement la partie qui avait besoin du VPN. Le flux de travail doit posséder l'ordre plutôt que l'observer. Trois conditions décident si ce flux a sa place dans Tasker.
Un seul point d'entrée doit posséder la séquence
Donnez au service privé un point d'entrée unique et approuvé, et laissez ce point exécuter les étapes dans l'ordre. Validez la destination, sélectionnez le profil prévu, demandez la connexion, attendez un résultat de disponibilité avec une limite sur votre temps d'attente, et seulement ensuite ouvrez l'URL. Si une étape échoue, arrêtez-vous et dites-le au lieu de basculer vers une ouverture directe.
C'est cette dernière clause que les gens sautent. Un flux qui ouvre quand même l'URL au-delà du délai est pire que pas d'automatisation, parce qu'il produit une requête qui ressemble à un VPN en échec alors qu'il n'en a jamais utilisé.
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 liste numérotée ci-dessus est le contrat, pas un profil exporté. Chaque client implémente sa surface de contrôle différemment, et certains exigent une extension, une autorisation de contrôle explicite ou un consentement utilisateur unique qu'aucune automatisation ne peut fournir.
Connecté n'est pas la même chose que prêt
Un statut qui dit que le tunnel a démarré prouve que le client a accepté la requête. Il ne prouve pas que le résolveur renvoie désormais des adresses privées ni que le service prévu est joignable. Ce sont des résultats distincts, et l'écart entre eux est l'endroit où un raccourci qui ouvre trop tôt échoue silencieusement. Le client rapporte son propre état, pas l'état du chemin que l'URL utilisera.
Définissez la disponibilité par rapport à quelque chose que le flux peut observer. Un état de connexion du client, une adresse résolue dans la plage attendue ou une sonde de joignabilité vers le service précis fonctionnent, à condition que la sonde ne puisse pas retomber sur le chemin réseau ordinaire. Une sonde qui réussit par la route normale ne vous dit rien.
Bornez l'attente. Une condition de disponibilité sans délai transforme un profil cassé en raccourci qui se bloque, ce que les utilisateurs signalent comme un téléphone qui gèle plutôt que comme un problème de VPN.
Ce que Tasker peut et ne peut pas faire
Tasker fournit la colle : un déclencheur, une liste d'actions ordonnée, des conditions et une action URL. Son action d'ouverture d'URL n'effectue que l'étape d'ouverture et rien d'autre. L'étape de connexion doit venir du client VPN, via une extension, un intent ou un service exposé que le client documente et autorise.
OpenVPN for Android documente par exemple une interface de contrôle à distance bâtie sur AIDL et les intents. C'est une capacité de ce client, pas une licence pour n'importe quelle tâche de l'appareil de le piloter. N'accordez le contrôle qu'à l'application que vous visez, car une couche d'automatisation capable de connecter et de déconnecter un tunnel est une surface de contrôle qui mérite d'être protégée.
Si le client installé n'expose aucun mécanisme de contrôle pris en charge, la réponse honnête est que ce flux ne peut pas être construit sur ce client. Une vieille page de comparaison de fonctionnalités n'est pas une spécification des capacités de la version présente sur le téléphone.
Quand la limite doit être obligatoire
L'automatisation est une commodité, et une commodité ne peut pas imposer une limite de sécurité. Si l'exigence est que les applications couvertes ne communiquent jamais sans le VPN, utilisez le réglage VPN permanent et blocage de la plateforme, ou la configuration gérée équivalente. Un événement du navigateur déclenché après le début de la navigation ne peut pas remplacer cette imposition, aussi soigneusement la tâche soit-elle ordonnée.
Décidez lequel vous construisez. Un raccourci qui se connecte d'abord puis ouvre est utile et ce n'est pas une garantie. Un appareil géré avec le blocage activé est une garantie et n'a pas du tout besoin d'une séquence 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 |
Testez trois issues, pas une
Exécutez le flux contre une connexion réussie, un délai volontaire et une reconnexion ordinaire après la chute du tunnel. Le cas du délai est celui qui révèle si la séquence s'arrête vraiment, et le cas de la reconnexion révèle si la disponibilité est vérifiée ou simplement supposée à partir d'un succès antérieur. Exécutez d'abord le cas du délai, car un flux qui ignore l'échec ne mérite pas d'être testé pour le succès.
N'autorisez que les destinations de la liste approuvée, et vérifiez tout lien venu de l'extérieur avant de l'ouvrir. Une tâche qui accepte des liens arbitraires devient un moyen de lancer des schémas inattendus, et une page d'administration privée atteinte ainsi est un résultat pire qu'un raccourci raté.
Notez le profil, la condition de disponibilité et le délai à côté de la tâche. La prochaine personne qui changera le client VPN aura besoin des trois, et aucun d'eux n'est visible depuis l'icône du raccourci.