OpenVPN Connect und Tasker: die Profil-ID, nicht der Name

Eine Automatisierung, die monatelang zuverlässig verband, funktioniert nach einem Client-Update nicht mehr, während dasselbe Profil von Hand weiterhin verbindet. Dieses Muster deutet auf den Steuerungsvertrag hin und nicht auf den VPN-Server. Irgendjemand hat geändert, welche Aktion die App annimmt oder welche Kennung sie erwartet, und die Aufgabe sendet weiterhin die alte. Die Bindung neu aufzubauen kostet weniger Zeit, als den Server erneut zu prüfen.

Der Vertrag gehört zu einer App und einem Versionsbereich

OpenVPN Connect und OpenVPN for Android sind verschiedene Anwendungen, und ein Intent, der ein Paket benennt, bewirkt in der anderen nichts. Bevor du die Aufgabe anfasst, prüfe, welcher Client installiert ist und welche Version das Verhalten erzeugt hat, mit dem du vergleichst. Für Connect unter Android 3.3.2 oder neuer erwartet die dokumentierte Tasker-Integration eine Profil-ID. Ältere Anleitungen, die einem Anzeigenamen AS oder PC voranstellen, beschreiben einen früheren Vertrag, und sie in eine aktuelle Aufgabe zu kopieren ist der übliche Grund, warum nichts passiert.

Diese Versionsgrenze erklärt die meisten Meldungen der Art «das hat früher funktioniert». Die App hat die Funktion nicht kaputt gemacht; sie hat geändert, was die Funktion annimmt. Behandle den Versionsbereich als Teil des Vertrags, gegen den du schreibst.

Woher die Kennung kommt

Öffne das gewünschte Profil in Connect und kopiere seine Profil-ID aus den Details des Profils selbst. Verwende diesen Wert statt eines Namens, den du aus der Liste kennst, denn der Name ist eine Bezeichnung und die Kennung ist das, womit die App abgleicht. Die Verbindungsfelder der Aktion Send Intent in Tasker sehen aus wie der Block unten, wobei nur die Kennung ersetzt wird. Halte auch die App-Instanz des persönlichen oder des Arbeitsprofils konsistent.

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

Eine Kopie im Arbeitsprofil mit demselben Paketnamen und einem anderen gespeicherten Profil nimmt den Intent an und findet kein passendes Profil, was wie eine kaputte Aufgabe und nicht wie ein Bereichsfehler aussieht. Wird das Profil neu importiert oder ersetzt, behandle die Kennung als verdächtig und prüfe sie erneut. Ein Neuimport erzeugt oft einen neuen Profileintrag, selbst wenn der Anzeigename unverändert bleibt. Prüfe die Kennung, bevor du irgendetwas anderes änderst.

Lass nicht zusammenhängende Felder leer, wie dokumentiert. Felder für Kategorie, MIME-Typ und Daten, die die Anleitung nicht verlangt, können ändern, wie Android den Intent auflöst, und ein Intent, der anders aufgelöst wird, kann die App starten, ohne dein Profil zu starten.

Was die Aktion tut und was sie dir überlässt

Das Senden des Verbindungs-Intents bittet die App, ein Profil zu starten. Er umgeht nicht die Autorisierung, die dieses Profil verlangt. Connect zeigt möglicherweise weiterhin eine Abfrage, weshalb der dokumentierte autonome Fall annimmt, dass keine weitere Autorisierung und keine gespeicherten Verbindungsdaten vorliegen. Die Versuchung ist, diese Grenze zu entfernen, indem Passwörter oder Geheimnisse des privaten Schlüssels in einen geteilten Tasker-Export eingebettet werden.

Tu das nicht. Ein Aufgabenexport ist eine Textdatei, die Leute in Chat-Threads kopieren, und Geheimnisse darin sind offengelegt, sobald er geteilt wird. Nutze die gespeicherten Verbindungsdaten der App, wenn das Profil sie braucht, und lass MFA-Abfragen Abfragen bleiben. Alles, was die Abfrage durch Speichern der Antwort vermeidet, hat das Geheimnis verschoben, statt das Problem zu lösen.

Die Trennungsseite hat ihre eigene dokumentierte Aktion, und sie ist kein Trick gegen den Client:

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

Die Verbindung zu einem absichtlich nicht existierenden Profil zu erzwingen, um eine Trennung zu erzwingen, ist die Art Workaround, die in alten Threads auftaucht und nach einem Update still fehlschlägt. Nutze die ausdrückliche Aktion.

Prüfe den Zustand, bevor der nächste Schritt läuft

Ein erfolgreicher Intent-Start beweist, dass die Anfrage zugestellt wurde, nicht dass ein Tunnel besteht. Wenn die Aufgabe danach eine interne Anwendung öffnet,braucht dieser Schritt eine Bereitschaftsbedingung mit begrenztem Zeitlimit. Eine unmittelbare Aktion nach dem Senden wird irgendwann gegen eine Abfrage laufen.

$ 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

Die resolve-Abfrage bestätigt, dass Paket und Activity, auf die du zielst, auf diesem Gerät existieren, was einen Tippfehler im Klassenfeld ausschließt. Der Activity-Dump zeigt, was nach dem Lauf deiner Aufgabe tatsächlich im Vordergrund steht, und er ist der billigste Weg zu sehen, ob die App eine Abfrage geöffnet hat, statt zu verbinden. Führe beides nach einer fehlgeschlagenen Aufgabe aus, statt zu raten, welches Feld falsch ist. Eine Abweichung im Klassennamen erzeugt sofort einen Fehler, während ein fehlendes Profil überhaupt keinen sichtbaren Fehler erzeugt.

Entscheide die Zuständigkeit für das Trennen, bevor du die Aufgabe auslieferst. Eine Abkürzung, die einen Tunnel abbaut, von dem eine andere Arbeitsaufgabe abhängt, erzeugt ein Support-Ticket, das seiner Ursache in nichts ähnelt. Zwei Automatisierungen zu behalten, die denselben Client steuern, erzeugt ein Rennen, das du aus den Protokollen nicht debuggen kannst, also lösche die überholte Aktion, sobald die neue funktioniert.