OpenVPN Connect et Tasker : l’ID du profil, pas le nom

Une automatisation qui se connectait de façon fiable pendant des mois cesse de fonctionner après une mise à jour du client, alors que le même profil se connecte toujours à la main. Ce schéma désigne le contrat de contrôle, pas le serveur VPN. Quelqu’un a changé l’action acceptée par l’application, ou l’identifiant qu’elle attend, et la tâche envoie toujours l’ancien. Reconstruire la liaison prend moins de temps que de revérifier le serveur.

Le contrat appartient à une application et à une plage de versions

OpenVPN Connect et OpenVPN for Android sont des applications différentes, et un intent qui nomme un paquet ne fait rien dans l’autre. Avant de toucher à la tâche, vérifiez quel client est installé et quelle version a produit le comportement auquel vous vous comparez. Pour Connect sous Android 3.3.2 ou version ultérieure, l’intégration Tasker documentée attend un ID de profil. Les instructions plus anciennes qui préfixent un nom d’affichage par AS ou PC décrivent un contrat précédent, et les recopier dans une tâche actuelle est la raison habituelle pour laquelle rien ne se passe.

Cette frontière de version explique la plupart des rapports « ça marchait avant ». L’application n’a pas cassé la fonction ; elle a changé ce que la fonction accepte. Traitez la plage de versions comme une partie du contrat pour lequel vous écrivez.

D’où vient l’identifiant

Ouvrez le profil voulu dans Connect et copiez son Profile ID depuis les détails du profil lui-même. Utilisez cette valeur plutôt qu’un nom que vous reconnaissez dans la liste, car le nom est une étiquette et l’identifiant est ce à quoi l’application compare. Les champs de connexion de l’action Send Intent de Tasker ressemblent au bloc ci-dessous, seul l’identifiant étant remplacé. Gardez aussi l’instance d’application personnelle ou de profil professionnel cohérente.

Action: net.openvpn.openvpn.CONNECT
Extra: net.openvpn.openvpn.AUTOSTART_PROFILE_ID:'PROFILE_ID'
Extra: net.openvpn.openvpn.AUTOCONNECT:true
Package: net.openvpn.openvpn
Class: net.openvpn.unified.MainActivity
Target: Activity

Une copie dans le profil professionnel, avec le même nom de paquet et un profil stocké différent, acceptera l’intent et ne trouvera aucun profil correspondant, ce qui ressemble à une tâche cassée plutôt qu’à une erreur de portée. Si le profil est réimporté ou remplacé, considérez l’identifiant comme suspect et vérifiez-le à nouveau. Une réimportation produit souvent une nouvelle entrée de profil même quand le nom d’affichage ne change pas. Vérifiez l’identifiant avant de changer quoi que ce soit d’autre.

Laissez vides les champs sans rapport, comme documenté. Les champs catégorie, type MIME et données que le guide ne demande pas peuvent changer la façon dont Android résout l’intent, et un intent qui se résout différemment peut lancer l’application sans démarrer votre profil.

Ce que fait l’action et ce qu’elle vous laisse

Envoyer l’intent de connexion demande à l’application de démarrer un profil. Il ne contourne pas l’autorisation que ce profil exige. Connect peut encore afficher une invite, et c’est pourquoi le cas autonome documenté suppose aucune autorisation supplémentaire ni identifiants de connectivité enregistrés. La tentation est de supprimer cette limite en intégrant des mots de passe ou des secrets de clé privée dans un export Tasker partagé.

Ne le faites pas. Un export de tâche est un fichier texte que les gens copient dans des fils de discussion, et les secrets qui y sont placés sont divulgués dès qu’il est partagé. Utilisez les identifiants de connectivité enregistrés par l’application si le profil en a besoin, et laissez les invites MFA rester des invites. Tout ce qui évite l’invite en stockant la réponse a déplacé le secret au lieu de résoudre le problème.

Le côté déconnexion a sa propre action documentée, et ce n’est pas un tour joué au client :

Action: net.openvpn.openvpn.DISCONNECT
Extra: net.openvpn.openvpn.STOP:true
Package: net.openvpn.openvpn
Class: net.openvpn.unified.MainActivity
Target: Activity

Se connecter à un profil volontairement inexistant pour forcer une déconnexion est le genre de contournement qui apparaît dans de vieux fils puis échoue silencieusement après une mise à jour. Utilisez l’action explicite.

Vérifiez l’état avant que l’étape suivante ne s’exécute

Un lancement d’intent réussi prouve que la demande a été livrée, pas qu’un tunnel existe. Si la tâche ouvre ensuite une application interne,cette étape a besoin d’une condition de disponibilité avec un délai borné. Une action immédiate après l’envoi finira par se déclencher contre une invite.

$ adb shell cmd package resolve-activity --brief net.openvpn.openvpn
net.openvpn.openvpn/net.openvpn.unified.MainActivity
$ adb shell dumpsys activity activities | grep -i openvpn

La requête resolve confirme que le paquet et l’activité visés existent sur cet appareil, ce qui écarte une faute de frappe dans le champ classe. Le vidage d’activité montre ce qui est réellement au premier plan après l’exécution de votre tâche, et c’est le moyen le moins coûteux de voir si l’application a ouvert une invite au lieu de se connecter. Exécutez les deux après une tâche échouée plutôt que de deviner quel champ est faux. Une divergence dans le nom de classe produit une erreur immédiate, tandis qu’un profil manquant ne produit aucune erreur visible.

Décidez la propriété de la déconnexion avant de livrer la tâche. Un raccourci qui coupe un tunnel dont dépend une autre tâche de travail générera un ticket d’assistance qui ne ressemble en rien à sa cause. Garder deux automatisations qui contrôlent le même client crée une course que vous ne pouvez pas déboguer depuis les journaux, alors supprimez l’action obsolète une fois que la nouvelle fonctionne.