Tasker und WireGuard: den richtigen Intent für einen Tunnel senden

Das Starten der WireGuard-Activity bringt eine App in den Vordergrund, nicht einen bestimmten Tunnel nach oben. Eine Automatisierung, die die App öffnet und wartet, besteht im Test und scheitert beim ersten Mal, wenn das Telefon bereits auf dem Startbildschirm liegt. WireGuard bietet einen unterstützten Fernsteuerungspfad für benannte Tunnel, und er ist enger, als die meisten Rezepte vermuten lassen. Die folgende Checkliste geht diesen Pfad von der Berechtigung bis zum beobachteten Ergebnis.

Prüfen, ob die Fernsteuerung aktiviert ist

Der Fernsteuerungs-Empfänger lauscht nicht immer. Die WireGuard-Einstellungen enthalten eine Option, die die Fernsteuerung von Tunneln aktiviert, und solange diese Option aus ist, ignoriert der Empfänger Anfragen, statt laut zu scheitern. Die Voreinstellung ist Absicht, denn ein exportierter Empfänger, der Tunnel hochfahren könnte, wäre auf jedem Gerät mit installierter App ein Sicherheitsloch. Aktiviere sie über die Oberfläche und schreibe auf, dass du es getan hast, denn es ist eine Einstellung, die ein künftiger Nutzer abschalten kann, ohne zu wissen, was davon abhing.

Der Empfänger weiter oben behandelt nur benannte UP- und DOWN-Anfragen, es gibt hier also keinen Weg, einen Tunnel zu erstellen oder seine Konfiguration zu bearbeiten. Bestätige, dass die Komponente im installierten Build vorhanden ist, bevor du dich darauf verlässt: adb shell dumpsys package com.wireguard.android | grep -i receiver listet die deklarierten Empfänger auf, und ein Build ohne den Fernsteuerungs-Empfänger antwortet nie. Wenn der Workflow einen anderen Endpunkt oder einen anderen Peer braucht, ist das ein anderer Tunnel und eine separate manuelle Einrichtung in der App.

Prüfen, welche Berechtigung der Controller hat

WireGuard schützt den Empfänger mit einer gefährlichen Berechtigung, com.wireguard.android.permission.CONTROL_TUNNELS, die die steuernde App besitzen muss. Ein eigener Broadcast kann keine Berechtigung erzeugen, die der Absender nie deklariert hat oder die ihm nie erteilt wurde. Das ist der Schritt, an dem Automatisierungsrezepte stillschweigend eine Fähigkeit annehmen, die die Automatisierung nicht hat.

Prüfe beide Seiten, bevor du die Aufgabe schreibst. Der erste Befehl listet die deklarierte Berechtigung auf, und der zweite zeigt, ob das Paket des Controllers sie tatsächlich besitzt. Ein Controller, der die Berechtigung in seinem Manifest deklariert, dem sie zur Laufzeit aber nie erteilt wurde, scheitert trotzdem, und der Fehler kommt als Stille statt als Dialog.

adb shell pm list permissions -g -d | grep -i control_tunnels
adb shell dumpsys package net.dinglisch.android.taskerm | grep -i control_tunnels

Wenn der Controller die Berechtigung nicht besitzt, nutze die Integration, die die App tatsächlich unterstützt, statt einen Broadcast von Hand zu bauen. Einen Intent zu senden und zu sehen, dass der Aufruf erfolgreich war, beweist nur, dass Android ihn angenommen hat, nicht dass WireGuard darauf reagiert hat. Behandle ein unbestätigtes Senden als unbekannt, nicht als Erfolg.

Die Intent-Felder gegen die installierte App prüfen

Vier Felder tragen die ganze Anfrage, und jedes hat eine Fehlerart, die genau wie die anderen aussieht. Triff die Aktion, den Tunnel-Extra, das Paket und das Ziel als Satz richtig.

Action:  com.wireguard.android.action.SET_TUNNEL_UP
Extra:   tunnel:lab-wg
Package: com.wireguard.android
Target:  Broadcast Receiver

Die Aktion benennt UP oder DOWN und nichts sonst, der Extra trägt den exakt konfigurierten Tunnelnamen, das Paket beschränkt die Zustellung auf WireGuard, und das Ziel muss der Empfänger statt einer Activity sein. Ein Tunnelname mit Tippfehler erzeugt dieselbe Stille wie ein deaktivierter Empfänger, lies den Namen also in der App, bevor du schließt, dass die Automatisierung kaputt ist. Die DOWN-Aktion ist com.wireguard.android.action.SET_TUNNEL_DOWN mit demselben Extra und Paket. Sende beim Testen jeweils eine Anfrage, denn zwei Broadcasts, die sich überholen, erzeugen einen Zustand, den niemand zuordnen kann.

Teste dieselbe Anfrage aus einer Shell auf dem Gerät, um den Intent von der Automatisierung zu trennen. Wenn dieser Befehl scheitert, während die Tasker-Aufgabe gelingt, ist der Unterschied die Absenderberechtigung und nicht die Feldwerte.

adb shell am broadcast -a com.wireguard.android.action.SET_TUNNEL_UP -e tunnel lab-wg --receiver-permission com.wireguard.android.permission.CONTROL_TUNNELS

Prüfen, was der Auslöser nicht abdeckt

Ein App-Start- oder Vordergrund-Ereignis kann eine Verbindung anfordern, aber die App hat vielleicht schon eine Namensauflösung oder eine erste Anfrage versucht, bevor dieses Ereignis behandelt wird. Der Auslöser feuert, wenn das System die Zustandsänderung bemerkt, also nachdem die App mit der Arbeit begonnen hat. Wenn die App nie außerhalb des Tunnels kommunizieren darf, ist ein Start-Auslöser keine Sperrregel und kann nicht durch eine Verzögerung zu einer gemacht werden. Konfiguriere eine unterstützte Always-on- oder Pro-App-Richtlinie für das Sperrverhalten und behalte den Auslöser nur zur Bequemlichkeit.

Das Sperrverhalten lebt ganz woanders. adb shell settings get global always_on_vpn_app benennt das Paket, das als Always-on festgelegt ist, und adb shell dumpsys connectivity | grep -i vpn zeigt die VPN-Netze, die das System gerade verfolgt. Nichts davon kann ein Start-Auslöser ersetzen.

Dieselbe Überlegung gilt am anderen Ende der Sitzung. Den Tunnel herunterzufahren, weil ein Fenster den Fokus verliert, bricht Hintergrundarbeit, Authentifizierungshilfen und jede andere App, die sich auf die Verbindung verlassen hat. Definiere ein bewusstes Sitzungsende statt eines Fokuswechsels und vermeide schnelle UP- und DOWN-Folgen, wenn die Automatisierung Kontexte wechselt.

Das Ergebnis prüfen, nicht das Senden

Ein Broadcast, der ohne Fehler zurückkehrt, wurde von Android angenommen und nichts weiter. Lies den Tunnelzustand aus der App und die Bereitschaft des Workflows aus dem, was der nächste Schritt tatsächlich braucht. Das sind zwei verschiedene Prüfungen, und die erste zu bestehen bedeutet nicht die zweite.

Lies auch den Zustand der Schnittstelle direkt: adb shell ip -brief addr show tun0 gibt die Tunnelschnittstelle und ihre Adresse aus, und eine Schnittstelle, die ohne Adresse existiert, ist oben, ohne nutzbar zu sein. Prüfe dann den privaten Dienst selbst, denn ein Tunnel, der ohne Handshake oder ohne Route oben ist, scheitert weiterhin an der Aufgabe, auf die es ankam. Eine Automatisierung, die eine benannte Verbindung innerhalb ihrer echten Berechtigungsgrenze steuert, muss die Schnittstelle nicht antippen, keinen Root-Befehl ausführen und Androids Netzwerkschutz nicht schwächen.