Tasker: VPN verbinden, bevor eine private URL geöffnet wird

Eine private URL zu öffnen und zu hoffen, dass der Tunnel zuerst hochkommt, ist ein Wettrennen, und der Browser gewinnt meist. Eine Verknüpfung, die auf eine bereits ladende Seite reagiert, hat die DNS-Abfrage und oft die erste Verbindung verpasst, also genau den Teil, der das VPN gebraucht hätte. Der Workflow muss die Reihenfolge besitzen, statt sie zu beobachten. Drei Bedingungen entscheiden, ob dieser Workflow überhaupt zu Tasker gehört.

Ein Einstiegspunkt sollte die Abfolge besitzen

Geben Sie dem privaten Dienst einen einzigen genehmigten Einstiegspunkt, und lassen Sie diesen Einstiegspunkt die Schritte der Reihe nach ausführen. Prüfen Sie das Ziel, wählen Sie das vorgesehene Profil, fordern Sie die Verbindung an, warten Sie auf ein Bereitschaftsergebnis mit einer Obergrenze für die Wartezeit und öffnen Sie erst dann die URL. Wenn ein Schritt fehlschlägt, halten Sie an und sagen Sie es, statt zu einem direkten Öffnen durchzufallen.

Genau diese letzte Klausel überspringen die Leute. Ein Workflow, der die URL bei Zeitüberschreitung trotzdem öffnet, ist schlimmer als keine Automatisierung, weil er eine Anfrage erzeugt, die wie ein gescheitertes VPN aussieht, obwohl nie eines benutzt wurde.

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

Die nummerierte Liste oben ist der Vertrag, kein exportiertes Profil. Jeder Client implementiert seine Steuerungsoberfläche anders, und manche verlangen ein Plugin, eine ausdrückliche Steuerungsberechtigung oder eine einmalige Nutzereinwilligung, die keine Automatisierung liefern kann.

Verbunden ist nicht dasselbe wie bereit

Ein Status, der sagt, dass der Tunnel gestartet ist beweist, dass der Client die Anfrage angenommen hat. Er beweist nicht, dass der Resolver jetzt private Adressen zurückgibt oder dass der vorgesehene Dienst erreichbar ist. Das sind getrennte Ergebnisse, und die Lücke dazwischen ist die Stelle, an der eine zu früh öffnende Verknüpfung still scheitert. Der Client meldet seinen eigenen Zustand, nicht den Zustand des Pfads, den die URL nutzen wird.

Definieren Sie Bereitschaft anhand von etwas, das der Workflow beobachten kann. Ein Verbindungszustand vom Client, eine aufgelöste Adresse aus dem erwarteten Bereich oder eine Erreichbarkeitsprüfung gegen den konkreten Dienst funktionieren alle, sofern die Prüfung nicht auf den gewöhnlichen Netzwerkpfad zurückfallen kann. Eine Prüfung, die über die normale Route gelingt, sagt Ihnen nichts.

Begrenzen Sie die Wartezeit. Eine Bereitschaftsbedingung ohne Zeitlimit macht aus einem defekten Profil eine hängende Verknüpfung, was Nutzer als einfrierendes Telefon melden und nicht als VPN-Problem.

Was Tasker kann und was nicht

Tasker liefert den Kitt: einen Auslöser, eine geordnete Aktionsliste, Bedingungen und eine URL-Aktion. Seine Aktion zum Öffnen einer URL führt nur den Öffnungsschritt aus und sonst nichts. Der Verbindungsschritt muss vom VPN-Client kommen, über ein Plugin, einen Intent oder einen offengelegten Dienst, den der Client dokumentiert und erlaubt.

OpenVPN for Android dokumentiert zum Beispiel eine Fernsteuerungsschnittstelle auf Basis von AIDL und Intents. Das ist eine Fähigkeit dieses Clients, keine Lizenz für beliebige Aufgaben auf dem Gerät, ihn zu steuern. Erteilen Sie Steuerung nur der App, die Sie meinen, denn eine Automatisierungsschicht, die einen Tunnel verbinden und trennen kann, ist eine Steuerungsoberfläche, die es wert ist, geschützt zu werden.

Wenn der installierte Client keinen unterstützten Steuerungsmechanismus bereitstellt, lautet die ehrliche Antwort, dass dieser Workflow auf diesem Client nicht gebaut werden kann. Eine alte Funktionsvergleichsseite ist keine Fähigkeitsspezifikation für die Version auf dem Telefon.

Wenn die Grenze zwingend sein muss

Automatisierung ist eine Bequemlichkeit, und eine Bequemlichkeit kann keine Sicherheitsgrenze durchsetzen. Wenn die Anforderung lautet, dass abgedeckte Anwendungen niemals ohne das VPN kommunizieren, nutzen Sie die Always-on-VPN- und Sperreinstellung der Plattform oder die entsprechende verwaltete Konfiguration. Ein Browser-Ereignis, das nach Beginn der Navigation ausgelöst wird, kann diese Durchsetzung nicht ersetzen, so sorgfältig die Aufgabe auch geordnet ist.

Entscheiden Sie, was Sie bauen. Eine Verknüpfung, die zuerst verbindet und dann öffnet, ist nützlich, und sie ist keine Garantie. Ein verwaltetes Gerät mit aktivierter Sperre ist eine Garantie, und es braucht überhaupt keine Tasker-Sequenz.

Testen Sie drei Ausgänge, nicht einen

Führen Sie den Workflow gegen eine erfolgreiche Verbindung, eine absichtliche Zeitüberschreitung und eine gewöhnliche Wiederverbindung nach einem Tunnelabbruch aus. Der Zeitüberschreitungsfall ist der, der zeigt, ob die Abfolge wirklich anhält, und der Wiederverbindungsfall zeigt, ob Bereitschaft geprüft oder nur aus einem früheren Erfolg angenommen wird. Führen Sie den Zeitüberschreitungsfall zuerst aus, denn ein Workflow, der Fehler ignoriert, ist es nicht wert, auf Erfolg getestet zu werden.

Erlauben Sie nur Ziele aus der genehmigten Liste, und prüfen Sie jeden Link, der von außen kommt, bevor Sie ihn öffnen. Eine Aufgabe, die beliebige Links akzeptiert, wird zu einer Möglichkeit, unerwartete Schemata zu starten, und eine so erreichte private Verwaltungsseite ist ein schlechteres Ergebnis als eine gescheiterte Verknüpfung.

Schreiben Sie das Profil, die Bereitschaftsbedingung und das Zeitlimit neben die Aufgabe. Die nächste Person, die den VPN-Client ändert, braucht alle drei, und keines davon ist vom Verknüpfungssymbol aus sichtbar.