Tasker a WireGuard: jak odeslat správný Intent pro jeden tunel

Spuštění aktivity WireGuard přivede aplikaci do popředí, ale nezvedne konkrétní tunel. Automatizace, která aplikaci otevře a čeká, projde testem a poprvé selže, když telefon už sedí na domovské obrazovce. WireGuard nabízí podporovanou cestu dálkového ovládání pro pojmenované tunely a ta je užší, než většina receptů naznačuje. Kontrolní seznam níže prochází touto cestou od oprávnění k pozorovanému výsledku.

Zkontrolujte, zda je dálkové ovládání zapnuté

Přijímač dálkového ovládání neposlouchá vždy. Nastavení WireGuardu obsahuje volbu, která zapíná dálkové ovládání tunelů, a dokud tato volba není zapnutá, přijímač žádosti ignoruje, místo aby hlasitě selhal. Výchozí hodnota je záměrná, protože exportovaný přijímač, který by mohl zvedat tunely, by byl bezpečnostní dírou v každém zařízení, kde je aplikace nainstalovaná. Zapněte ji přes rozhraní a poznamenejte si, že jste to udělali, protože jde o nastavení, které budoucí uživatel může vypnout, aniž by věděl, co na něm záviselo.

Přijímač výše zpracovává jen pojmenované žádosti UP a DOWN, takže zde není cesta k vytvoření tunelu ani k úpravě jeho konfigurace. Než se na něj spolehnete, ověřte, že komponenta v nainstalovaném sestavení existuje: adb shell dumpsys package com.wireguard.android | grep -i receiver vypisuje deklarované přijímače a sestavení bez přijímače dálkového ovládání nikdy neodpoví. Pokud pracovní postup potřebuje jiný koncový bod nebo jiného partnera, je to jiný tunel a samostatné ruční nastavení uvnitř aplikace.

Zkontrolujte oprávnění, které ovladač má

WireGuard chrání přijímač nebezpečným oprávněním com.wireguard.android.permission.CONTROL_TUNNELS, které musí ovládající aplikace mít. Vlastní broadcast nedokáže vytvořit oprávnění, které odesílatel nikdy nedeklaroval nebo které mu nikdy nebylo uděleno. To je krok, kdy recepty na automatizaci tiše předpokládají schopnost, kterou automatizace nemá.

Před psaním úlohy zkontrolujte obě strany. První příkaz vypíše deklarované oprávnění a druhý ukáže, zda ho balíček ovladače skutečně má. Ovladač, který oprávnění deklaruje v manifestu, ale za běhu mu nikdy nebylo uděleno, přesto selže, a selhání přijde jako ticho, ne jako dialog.

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

Pokud ovladač oprávnění nemá, použijte integraci, kterou aplikace skutečně podporuje, místo ručního sestavování broadcastu. Odeslání Intentu a pozorování, že volání uspělo, dokazuje jen to, že ho Android přijal, ne že na něj WireGuard zareagoval. Neověřené odeslání berte jako neznámou, ne jako úspěch.

Zkontrolujte pole Intentu proti nainstalované aplikaci

Celý požadavek nesou čtyři pole a každé má způsob selhání, který vypadá naprosto stejně jako ostatní. Akci, extra položku tunelu, balíček a cíl trefte správně jako sadu.

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

Akce pojmenovává UP nebo DOWN a nic jiného, extra položka nese přesný nakonfigurovaný název tunelu, balíček omezuje doručení na WireGuard a cílem musí být přijímač, ne aktivita. Název tunelu s překlepem vytváří stejné ticho jako vypnutý přijímač, takže si název přečtěte v aplikaci, než usoudíte, že automatizace je rozbitá. Akce DOWN je com.wireguard.android.action.SET_TUNNEL_DOWN se stejnou extra položkou a balíčkem. Při testování posílejte jeden požadavek najednou, protože dva broadcasty, které se navzájem předhánějí, vytvoří stav, který nikdo nemůže připsat.

Otestujte stejný požadavek z shellu na zařízení, abyste oddělili Intent od automatizace. Pokud tento příkaz selže, zatímco úloha v Taskeru uspěje, rozdílem je oprávnění odesílatele, ne hodnoty polí.

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

Zkontrolujte, co spouštěč nepokrývá

Událost spuštění nebo přechodu do popředí může vyžádat připojení, ale aplikace už možná zkusila vyhledání názvu nebo počáteční požadavek dřív, než byla tato událost zpracována. Spouštěč se aktivuje, když systém zaznamená změnu stavu, tedy poté, co aplikace začala pracovat. Pokud aplikace nikdy nesmí komunikovat mimo tunel, spouštěč spuštění není blokovací pravidlo a nelze ho na něj změnit přidáním zpoždění. Pro blokovací chování nastavte podporovanou zásadu trvalého zapnutí nebo pro jednotlivé aplikace a spouštěč si nechte jen pro pohodlí.

Blokovací chování žije úplně jinde. adb shell settings get global always_on_vpn_app pojmenovává balíček připnutý jako trvale zapnutý a adb shell dumpsys connectivity | grep -i vpn ukazuje sítě VPN, které systém právě sleduje. Ani jedno z toho není něco, co by spouštěč spuštění mohl nahradit.

Stejná úvaha platí na druhém konci relace. Sundání tunelu proto, že jedno okno ztratilo fokus, rozbíjí práci na pozadí, pomocníky pro ověřování a každou další aplikaci, která na připojení spoléhala. Definujte záměrný konec relace místo změny fokusu a vyhněte se rychlým posloupnostem UP a DOWN, když automatizace přepíná kontexty.

Kontrolujte výsledek, ne odeslání

Broadcast, který se vrátí bez chyby, Android přijal a nic víc. Čtěte stav tunelu z aplikace a připravenost pracovního postupu z toho, co další krok skutečně potřebuje. To jsou dvě různé kontroly a projití první neznamená druhou.

Čtěte přímo i stav rozhraní: adb shell ip -brief addr show tun0 vypíše rozhraní tunelu a jeho adresu, a rozhraní, které existuje bez adresy, je zvednuté, ale nepoužitelné. Pak ověřte samotnou privátní službu, protože tunel, který je zvednutý bez handshake nebo bez trasy, stále selhává v úloze, na které záleželo. Automatizace, která ovládá jedno pojmenované připojení v rámci svých skutečných mezí oprávnění, nemusí klepat na rozhraní, spouštět root příkaz ani oslabovat síťové ochrany Androidu.