Tasker kaj WireGuard: sendi la ĝustan Intencon por unu tunelo

Lanĉi la agadon de WireGuard venigas apon antaŭen, ne malfermas apartan tunelon. Aŭtomatigo, kiu malfermas la apon kaj atendas, sukcesos en la testo kaj malsukcesos la unuan fojon, kiam la telefono jam staras sur la hejma ekrano. WireGuard montras subtenatan teleregadan vojon por nomitaj tuneloj, kaj ĝi estas pli mallarĝa ol la plej multaj receptoj sugestas. La kontrolisto malsupre iras tiun vojon de permeso ĝis observita rezulto.

Kontrolu, ĉu teleregado estas ŝaltita

La teleregila ricevilo ne ĉiam aŭskultas. La agordoj de WireGuard inkluzivas opcion, kiu ŝaltas teleregadon de tuneloj, kaj ĝis tiu opcio estas ŝaltita, la ricevilo ignoras petojn anstataŭ malsukcesi laŭte. La defaŭlto estas intenca, ĉar eksportita ricevilo, kiu povus malfermi tunelojn, estus sekureca truo sur ĉiu aparato, kie la apo estas instalita. Ŝaltu ĝin per la interfaco kaj notu, ke vi faris tion, ĉar ĝi estas agordo, kiun estonta uzanto povas malŝalti sen scii, kio dependis de ĝi.

La ricevilo supre traktas nur nomitajn petojn UP kaj DOWN, do ĉi tie ne ekzistas vojo por krei tunelon aŭ redakti ĝian agordon. Konfirmu, ke la komponanto ekzistas en la instalita versio antaŭ ol fidi ĝin: adb shell dumpsys package com.wireguard.android | grep -i receiver listigas la deklaritajn ricevilojn, kaj versio sen la teleregila ricevilo neniam respondos. Se la laborfluo bezonas alian finpunkton aŭ alian partneron, tio estas alia tunelo kaj aparta permana agordo ene de la apo.

Kontrolu la permeson, kiun havas la regilo

WireGuard protektas la ricevilon per danĝera permeso, com.wireguard.android.permission.CONTROL_TUNNELS, kiun la reganta apo devas havi. Propra dissendo ne povas fabriki permeson, kiun la sendinto neniam deklaris aŭ neniam ricevis. Tio estas la paŝo, kie aŭtomatigaj receptoj kviete supozas kapablon, kiun la aŭtomatigo ne havas.

Kontrolu ambaŭ flankojn antaŭ ol skribi la taskon. La unua komando listigas la deklaran permeson, kaj la dua montras, ĉu la pako de la regilo vere havas ĝin. Regilo, kiu deklaras la permeson en sia manifestaĵo sed neniam ricevis ĝin dum plenumo, ankoraŭ malsukcesas, kaj la malsukceso venas kiel silento anstataŭ kiel dialogo.

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

Se la regilo ne havas la permeson, uzu la integriĝon, kiun la apo efektive subtenas, anstataŭ permane konstrui dissendon. Sendi Intencon kaj vidi, ke la voko sukcesis, pruvas nur, ke Android akceptis ĝin, ne ke WireGuard agis laŭ ĝi. Traktu nevalidigitan sendon kiel nekonatan, ne kiel sukceson.

Kontrolu la kampojn de la Intenco kontraŭ la instalita apo

Kvar kampoj portas la tutan peton, kaj ĉiu havas malsukcesmanieron, kiu aspektas precize kiel la aliaj. Trafe akiru la agon, la tunelan kromkampon, la pakon kaj la celon kiel aron.

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

La ago nomas UP aŭ DOWN kaj nenion alian, la kromkampo portas la ekzaktan agorditan tunelan nomon, la pako limigas liveradon al WireGuard, kaj la celo devas esti la ricevilo anstataŭ agado. Tunela nomo kun tajperaro produktas la saman silenton kiel malŝaltita ricevilo, do legu la nomon en la apo antaŭ ol konkludi, ke la aŭtomatigo rompiĝis. La ago DOWN estas com.wireguard.android.action.SET_TUNNEL_DOWN kun la sama kromkampo kaj pako. Sendu unu peton samtempe dum testado, ĉar du dissendoj, kiuj vetkuras unu la alian, produktas staton, kiun neniu povas atribui.

Testu la saman peton el ŝelo sur la aparato por apartigi la Intencon de la aŭtomatigo. Se tiu komando malsukcesas dum la tasko de Tasker sukcesas, la diferenco estas la permeso de la sendinto, ne la kampaj valoroj.

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

Kontrolu, kion la ellasilo ne kovras

Apa lanĉa aŭ antaŭplana evento povas peti konekton, sed la apo eble jam provis nomserĉon aŭ komencan peton antaŭ ol tiu evento estas traktata. La ellasilo ekagas, kiam la sistemo rimarkas la statŝanĝon, kio estas post kiam la apo komencis labori. Se la apo neniam rajtas komuniki ekster la tunelo, lanĉa ellasilo ne estas blokada regulo kaj ne povas fariĝi tia per aldono de prokrasto. Agordu subtenatan ĉiam-aktivan aŭ por-apan politikon por la blokada konduto, kaj konservu la ellasilon nur por komforto.

La blokada konduto loĝas tute alie. adb shell settings get global always_on_vpn_app nomas la pakon fiksitan kiel ĉiam-aktiva, kaj adb shell dumpsys connectivity | grep -i vpn montras la VPN-retojn, kiujn la sistemo nun spuras. Neniu el tiuj estas io, kion lanĉa ellasilo povas anstataŭigi.

La sama rezonado validas ĉe la alia fino de la seanco. Mallevi la tunelon ĉar unu fenestro perdis fokuson rompas fona laboro, aŭtentigajn helpilojn kaj ĉiun alian apon, kiu fidis la konekton. Difinu intencan finon de seanco anstataŭ fokusa ŝanĝo, kaj evitu rapidajn sinsekvojn UP kaj DOWN, kiam la aŭtomatigo ŝanĝas kuntekstojn.

Kontrolu la rezulton, ne la sendon

Dissendo, kiu revenas sen eraro, estis akceptita de Android kaj nenio pli. Legu la tunelan staton el la apo, kaj legu la pretecon de la laborfluo el tio, kion la sekva paŝo efektive bezonas. Tiuj estas du malsamaj kontroloj, kaj trapasi la unuan ne implicas la duan.

Legu ankaŭ la staton de la interfaco rekte: adb shell ip -brief addr show tun0 presas la tunelan interfacon kaj ĝian adreson, kaj interfaco, kiu ekzistas sen adreso, estas supre sen esti uzebla. Poste kontrolu la privatan servon mem, ĉar tunelo, kiu estas supre sen manpremo aŭ sen itinero, ankoraŭ malsukcesas en la tasko, kiu gravis. Aŭtomatigo, kiu regas unu nomitan konekton ene de sia reala permesa limo, ne bezonas tuŝi la interfacon, ruli radikan komandon aŭ malfortigi la retajn protektojn de Android.