Tasker in WireGuard: pošiljanje pravega Intenta za en tunel

Zagon dejavnosti WireGuard prinese aplikacijo v ospredje, ne dvigne pa določenega tunela. Avtomatizacija, ki odpre aplikacijo in čaka, bo na preizkusu uspela in prvič spodletela, ko telefon že sedi na domačem zaslonu. WireGuard ponuja podprto pot daljinskega upravljanja za poimenovane tunele in ta je ožja, kot nakazuje večina receptov. Spodnji kontrolni seznam prehodi to pot od dovoljenja do opazovanega rezultata.

Preverite, ali je daljinsko upravljanje omogočeno

Sprejemnik za daljinsko upravljanje ne posluša vedno. Nastavitve WireGuarda vključujejo možnost, ki omogoči daljinsko upravljanje tunelov, in dokler ta možnost ni vklopljena, sprejemnik zahteve prezre, namesto da bi glasno spodletel. Privzeta vrednost je namerna, ker bi izvožen sprejemnik, ki bi lahko dvignil tunele, bil varnostna luknja na vsaki napravi z nameščeno aplikacijo. Omogočite jo prek vmesnika in zapišite, da ste to storili, ker je to nastavitev, ki jo lahko prihodnji uporabnik izklopi, ne da bi vedel, od česa je bila odvisna.

Zgornji sprejemnik obravnava samo poimenovane zahteve UP in DOWN, zato tukaj ni poti za ustvarjanje tunela ali urejanje njegove konfiguracije. Preden se nanj zanesete, potrdite, da komponenta obstaja v nameščeni izdelavi: adb shell dumpsys package com.wireguard.android | grep -i receiver navaja deklarirane sprejemnike, izdelava brez sprejemnika za daljinsko upravljanje pa nikoli ne bo odgovorila. Če delovni tok potrebuje drugo končno točko ali drugega partnerja, je to drug tunel in ločena ročna nastavitev znotraj aplikacije.

Preverite, katero dovoljenje ima krmilnik

WireGuard ščiti sprejemnik z nevarnim dovoljenjem, com.wireguard.android.permission.CONTROL_TUNNELS, ki ga mora imeti krmilna aplikacija. Lastno oddajanje ne more ustvariti dovoljenja, ki ga pošiljatelj ni nikoli deklariral ali mu ni bilo nikoli dodeljeno. To je korak, kjer recepti za avtomatizacijo tiho predpostavijo zmožnost, ki je avtomatizacija nima.

Pred pisanjem opravila preverite obe strani. Prvi ukaz navaja deklarirano dovoljenje, drugi pa pokaže, ali ga paket krmilnika res ima. Krmilnik, ki dovoljenje deklarira v manifestu, a mu med izvajanjem ni bilo nikoli dodeljeno, vseeno spodleti, in neuspeh pride kot tišina, ne kot pogovorno okno.

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

Če krmilnik dovoljenja nima, uporabite integracijo, ki jo aplikacija resnično podpira, namesto da bi ročno zgradili oddajanje. Pošiljanje Intenta in ugotovitev, da je klic uspel, dokazuje le, da ga je Android sprejel, ne pa, da je WireGuard po njem ukrepal. Nepreverjeno pošiljanje obravnavajte kot neznano, ne kot uspeh.

Primerjajte polja Intenta z nameščeno aplikacijo

Štiri polja nosijo celotno zahtevo in vsako ima način neuspeha, ki izgleda popolnoma enako kot ostala. Dejanje, dodatno polje tunela, paket in cilj nastavite pravilno kot en niz.

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

Dejanje poimenuje UP ali DOWN in nič drugega, dodatno polje nosi točno konfigurirano ime tunela, paket omejuje dostavo na WireGuard, cilj pa mora biti sprejemnik in ne dejavnost. Ime tunela s tipkarsko napako ustvari enako tišino kot izklopljen sprejemnik, zato preberite ime v aplikaciji, preden sklepate, da je avtomatizacija pokvarjena. Dejanje DOWN je com.wireguard.android.action.SET_TUNNEL_DOWN z istim dodatnim poljem in paketom. Med preizkušanjem pošiljajte eno zahtevo naenkrat, ker dve oddajanji, ki se prehitevata, ustvarita stanje, ki ga nihče ne more pripisati.

Preizkusite isto zahtevo iz lupine na napravi, da ločite Intent od avtomatizacije. Če ta ukaz spodleti, medtem ko opravilo v Taskerju uspe, je razlika dovoljenje pošiljatelja in ne vrednosti polj.

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

Preverite, česa sprožilec ne pokriva

Dogodek zagona ali prehoda aplikacije v ospredje lahko zahteva povezavo, vendar je aplikacija morda že poskusila iskanje imena ali začetno zahtevo, preden je bil ta dogodek obravnavan. Sprožilec se sproži, ko sistem opazi spremembo stanja, torej potem, ko je aplikacija začela delati. Če aplikacija nikoli ne sme komunicirati zunaj tunela, sprožilec zagona ni pravilo blokiranja in ga ni mogoče narediti takega z dodajanjem zakasnitve. Za vedenje blokiranja nastavite podprto pravilnik vedno vklopljenega ali za posamezno aplikacijo, sprožilec pa obdržite le za udobje.

Vedenje blokiranja živi povsem drugje. adb shell settings get global always_on_vpn_app poimenuje paket, pripet kot vedno vklopljen, adb shell dumpsys connectivity | grep -i vpn pa pokaže omrežja VPN, ki jih sistem trenutno spremlja. Nič od tega ni nekaj, kar bi sprožilec zagona lahko nadomestil.

Enako razmišljanje velja na drugem koncu seje. Spuščanje tunela zato, ker je eno okno izgubilo fokus, zlomi delo v ozadju, pomočnike za preverjanje pristnosti in vsako drugo aplikacijo, ki je računala na povezavo. Določite namerni konec seje namesto spremembe fokusa in se izogibajte hitrim zaporedjem UP in DOWN, ko avtomatizacija preklaplja kontekste.

Preverite rezultat, ne pošiljanja

Oddajanje, ki se vrne brez napake, je Android sprejel in nič več. Preberite stanje tunela iz aplikacije, pripravljenost delovnega toka pa iz tega, kar naslednji korak resnično potrebuje. To sta dve različni preverjanji in prehod prve ne pomeni druge.

Neposredno preberite tudi stanje vmesnika: adb shell ip -brief addr show tun0 izpiše vmesnik tunela in njegov naslov, vmesnik, ki obstaja brez naslova, pa je dvignjen, a ni uporaben. Nato preverite še samo zasebno storitev, ker tunel, dvignjen brez rokovanja ali brez poti, vseeno spodleti pri opravilu, na katerem je bilo treba. Avtomatizaciji, ki upravlja eno poimenovano povezavo znotraj svojih resničnih meja dovoljenja, ni treba dotakniti vmesnika, izvajati ukaza root ali slabiti omrežnih zaščit Androida.