Tasker a WireGuard: odoslanie správneho Intentu pre jeden tunel

Spustenie aktivity WireGuard privedie aplikáciu do popredia, ale nezdvihne konkrétny tunel. Automatizácia, ktorá otvorí aplikáciu a čaká, prejde testom a prvýkrát zlyhá, keď telefón už sedí na domovskej obrazovke. WireGuard ponúka podporovanú cestu diaľkového ovládania pre pomenované tunely a tá je užšia, než naznačuje väčšina receptov. Kontrolný zoznam nižšie prechádza touto cestou od oprávnenia k pozorovanému výsledku.

Skontrolujte, či je diaľkové ovládanie zapnuté

Prijímač diaľkového ovládania nepočúva vždy. V nastaveniach WireGuardu je voľba, ktorá zapína diaľkové ovládanie tunelov, a kým nie je zapnutá, prijímač žiadosti ignoruje namiesto hlasného zlyhania. Predvolená hodnota je zámerná, pretože exportovaný prijímač, ktorý by mohol zdvíhať tunely, by bol bezpečnostnou dierou na každom zariadení s nainštalovanou aplikáciou. Zapnite ju cez rozhranie a poznamenajte si, že ste to urobili, pretože je to nastavenie, ktoré budúci používateľ môže vypnúť bez toho, aby vedel, čo od neho záviselo.

Prijímač vyššie spracúva len pomenované žiadosti UP a DOWN, takže tu nie je cesta na vytvorenie tunela ani na úpravu jeho konfigurácie. Skôr než sa naň spoľahnete, overte, že komponent v nainštalovanom zostavení existuje: adb shell dumpsys package com.wireguard.android | grep -i receiver vypisuje deklarované prijímače a zostavenie bez prijímača diaľkového ovládania nikdy neodpovie. Ak pracovný postup potrebuje iný koncový bod alebo iného partnera, je to iný tunel a samostatné manuálne nastavenie vnútri aplikácie.

Skontrolujte, aké oprávnenie má ovládač

WireGuard chráni prijímač nebezpečným oprávnením com.wireguard.android.permission.CONTROL_TUNNELS, ktoré musí mať ovládajúca aplikácia. Vlastný broadcast nedokáže vytvoriť oprávnenie, ktoré odosielateľ nikdy nedeklaroval alebo ktoré mu nikdy nebolo udelené. Toto je krok, v ktorom recepty automatizácie ticho predpokladajú schopnosť, ktorú automatizácia nemá.

Pred napísaním úlohy skontrolujte obe strany. Prvý príkaz vypisuje deklarované oprávnenie a druhý ukazuje, či ho balík ovládača naozaj má. Ovládač, ktorý oprávnenie deklaruje v manifeste, ale počas behu ho nikdy nedostal, napriek tomu zlyhá, a zlyhanie prichádza ako ticho, nie ako dialóg.

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

Ak ovládač oprávnenie nemá, použite integráciu, ktorú aplikácia skutočne podporuje, namiesto ručného zostavenia broadcastu. Odoslanie Intentu a pozorovanie, že volanie uspelo, dokazuje len to, že ho Android prijal, nie že naň WireGuard zareagoval. Neoverené odoslanie berte ako neznámu, nie ako úspech.

Porovnajte polia Intentu s nainštalovanou aplikáciou

Celú žiadosť nesú štyri polia a každé má spôsob zlyhania, ktorý vyzerá presne ako ostatné. Akciu, extra položku tunela, balík a cieľ nastavte správne ako jednu sadu.

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

Akcia pomenúva UP alebo DOWN a nič iné, extra položka nesie presný nakonfigurovaný názov tunela, balík obmedzuje doručenie na WireGuard a cieľom musí byť prijímač, nie aktivita. Názov tunela s preklepom vytvára rovnaké ticho ako vypnutý prijímač, preto si názov prečítajte v aplikácii, skôr než usúdite, že automatizácia je pokazená. Akcia DOWN je com.wireguard.android.action.SET_TUNNEL_DOWN s tou istou extra položkou a balíkom. Pri testovaní posielajte jeden požiadavku naraz, pretože dva broadcasty, ktoré sa navzájom predbiehajú, vytvoria stav, ktorý nikto nevie priradiť.

Otestujte tú istú žiadosť z shellu na zariadení, aby ste oddelili Intent od automatizácie. Ak tento príkaz zlyhá, kým úloha v Taskeri uspeje, rozdielom je oprávnenie odosielateľa, nie 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

Skontrolujte, čo spúšťač nepokrýva

Udalosť spustenia alebo prechodu aplikácie do popredia môže požiadať o pripojenie, ale aplikácia už mohla skúsiť vyhľadanie názvu alebo počiatočnú žiadosť predtým, než bola táto udalosť spracovaná. Spúšťač sa aktivuje, keď systém zaznamená zmenu stavu, teda po tom, ako aplikácia začala pracovať. Ak aplikácia nikdy nesmie komunikovať mimo tunela, spúšťač spustenia nie je blokovacie pravidlo a nedá sa ním stať pridaním oneskorenia. Pre blokovacie správanie nastavte podporovanú zásadu trvalého zapnutia alebo pre jednotlivé aplikácie a spúšťač si nechajte len pre pohodlie.

Blokovacie správanie žije úplne inde. adb shell settings get global always_on_vpn_app pomenúva balík pripnutý ako trvalo zapnutý a adb shell dumpsys connectivity | grep -i vpn ukazuje siete VPN, ktoré systém práve sleduje. Ani jedno z toho nie je niečo, čo by spúšťač spustenia mohol nahradiť.

Rovnaká úvaha platí na druhom konci relácie. Zloženie tunela preto, že jedno okno stratilo fokus, rozbíja prácu na pozadí, pomocníkov overovania a každú ďalšiu aplikáciu, ktorá sa spoliehala na pripojenie. Definujte zámerný koniec relácie namiesto zmeny fokusu a vyhnite sa rýchlym postupnostiam UP a DOWN, keď automatizácia prepína kontexty.

Kontrolujte výsledok, nie odoslanie

Broadcast, ktorý sa vráti bez chyby, Android prijal a nič viac. Čítajte stav tunela z aplikácie a pripravenosť pracovného postupu z toho, čo nasledujúci krok naozaj potrebuje. Sú to dve rôzne kontroly a prechod prvej neznamená druhú.

Čítajte priamo aj stav rozhrania: adb shell ip -brief addr show tun0 vypíše rozhranie tunela a jeho adresu, a rozhranie, ktoré existuje bez adresy, je zdvihnuté, ale nepoužiteľné. Potom overte samotnú privátnu službu, pretože tunel zdvihnutý bez handshake alebo bez trasy stále zlyháva v úlohe, na ktorej záležalo. Automatizácia, ktorá ovláda jedno pomenované pripojenie v rámci svojich skutočných hraníc oprávnenia, nemusí klopať na rozhranie, spúšťať root príkaz ani oslabovať sieťové ochrany Androidu.