Tasker a WireGuard: anfon yr Intent cywir ar gyfer un twnnel

Mae lansio gweithgaredd WireGuard yn dod ag ap i’r blaen, nid yn codi twnnel penodol. Bydd awtomeiddio sy’n agor yr ap ac yn aros yn llwyddo yn y prawf ac yn methu’r tro cyntaf pan fydd y ffôn eisoes yn eistedd ar y sgrin gartref. Mae WireGuard yn amlygu llwybr rheoli o bell a gefnogir ar gyfer twnelau a enwir, ac mae’n gulach na’r hyn y mae’r rhan fwyaf o ryseitiau’n ei awgrymu. Mae’r rhestr wirio isod yn cerdded y llwybr hwnnw o ganiatâd i ganlyniad a welwyd.

Gwiriwch fod rheolaeth o bell wedi’i chynnwys

Nid yw’r derbynnydd rheoli o bell bob amser yn gwrando. Mae gosodiadau WireGuard yn cynnwys opsiwn sy’n galluogi rheolaeth o bell ar dwnelau, a hyd nes bod yr opsiwn hwnnw ymlaen mae’r derbynnydd yn anwybyddu ceisiadau yn lle methu’n uchel. Mae’r rhagosodiad yn fwriadol, oherwydd byddai derbynnydd a allai godi twnelau yn dwll diogelwch ar bob dyfais a osododd yr ap. Galluogwch ef drwy’r rhyngwyneb ac ysgrifennwch eich bod wedi gwneud, oherwydd mae’n osodiad y gall defnyddiwr yn y dyfodol ei ddiffodd heb wybod beth oedd yn dibynnu arno.

Dim ond ceisiadau UP a DOWN a enwir y mae’r derbynnydd uwch yn eu trin, felly nid oes llwybr yma ar gyfer creu twnnel na golygu ei ffurfweddiad. Cadarnhewch fod y gydran yn y gosodiad sydd wedi’i osod cyn dibynnu arni: mae adb shell dumpsys package com.wireguard.android | grep -i receiver yn rhestru’r derbynyddion a ddatganwyd, ac ni fydd gosodiad heb y derbynnydd rheoli o bell byth yn ateb. Os oes angen pen draw gwahanol neu gymar gwahanol ar y llif gwaith, twnnel gwahanol yw hwnnw a gosodiad â llaw ar wahân y tu mewn i’r ap.

Gwiriwch y caniatâd sydd gan y rheolydd

Mae WireGuard yn diogelu’r derbynnydd â chaniatâd peryglus, com.wireguard.android.permission.CONTROL_TUNNELS, y mae’n rhaid i’r ap rheoli ei gael. Ni all darllediad cyfaddas greu caniatâd na ddatganodd yr anfonwr erioed ac na roddwyd erioed iddo. Dyma’r cam lle mae ryseitiau awtomeiddio’n tybio’n dawel allu nad yw’r awtomeiddio’n ei gael.

Gwiriwch y ddwy ochr cyn ysgrifennu’r dasg. Mae’r gorchymyn cyntaf yn rhestru’r caniatâd a ddatganwyd, ac mae’r ail yn dangos a yw pecyn y rheolydd yn ei gael mewn gwirionedd. Mae rheolydd sy’n datgan y caniatâd yn ei faniffest ond na roddwyd iddo erioed ar amser rhedeg yn methu o hyd, ac mae’r methiant yn dod fel tawelwch yn hytrach nag fel deialog.

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

Os nad oes gan y rheolydd y caniatâd, defnyddiwch y gyfannu y mae’r ap yn ei chefnogi mewn gwirionedd yn lle adeiladu darllediad â llaw. Mae anfon Intent a gweld bod y galwad wedi llwyddo ond yn profi bod Android wedi’i dderbyn, nid bod WireGuard wedi gweithredu arno. Triniwch anfoniad heb ei wirio fel anhysbys, nid fel llwyddiant.

Gwiriwch feysydd yr Intent yn erbyn yr ap sydd wedi’i osod

Mae pedwar maes yn cario’r cais cyfan, ac mae gan bob un fodd methu sy’n edrych yn union fel y lleill. Cewch y weithred, yr extra twnnel, y pecyn a’r targed yn iawn fel set.

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

Mae’r weithred yn enwi UP neu DOWN a dim arall, mae’r extra yn cario union enw’r twnnel a ffurfweddwyd, mae’r pecyn yn cyfyngu dosbarthu i WireGuard, ac mae’n rhaid i’r targed fod y derbynnydd yn hytrach nag actifedd. Mae enw twnnel â gwall teipio yn cynhyrchu’r un tawelwch â derbynnydd wedi’i anablu, felly darllenwch yr enw yn yr ap cyn casglu bod yr awtomeiddio wedi torri. Y weithred DOWN yw com.wireguard.android.action.SET_TUNNEL_DOWN gyda’r un extra a’r un pecyn. Anfonwch un cais ar y tro wrth brofi, oherwydd mae dau ddarllediad yn rasio ei gilydd yn cynhyrchu cyflwr na all neb ei briodoli.

Profwch yr un cais o gragen ar y ddyfais i wahanu’r Intent oddi wrth yr awtomeiddio. Os yw’r gorchymyn hwnnw’n methu tra bo tasg Tasker yn llwyddo, y caniatâd anfonwr yw’r gwahaniaeth, nid gwerthoedd y meysydd.

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

Gwiriwch beth nad yw’r sbardun yn ei gwmpasu

Gall digwyddiad lansio ap neu flaendir ofyn am gysylltiad, ond mae’n bosibl bod yr ap eisoes wedi ceisio chwiliad enw neu gais cychwynnol cyn i’r digwyddiad hwnnw gael ei drin. Mae’r sbardun yn tanio pan fydd y system yn sylwi ar y newid cyflwr, sef ar ôl i’r ap ddechrau gweithio. Os na chaiff yr ap byth gyfathrebu y tu allan i’r twnnel, nid yw sbardun lansio yn rheol flocio ac ni ellir ei droi’n un drwy ychwanegu oedi. Ffurfweddwch bolisi cefnogol o fod ymlaen bob amser neu fesul ap ar gyfer yr ymddygiad blocio, a chadwch y sbardun ar gyfer cyfleustra yn unig.

Mae’r ymddygiad blocio yn byw yn hollol rhywle arall. Mae adb shell settings get global always_on_vpn_app yn enwi’r pecyn sydd wedi’i binio fel un sydd ymlaen bob amser, ac mae adb shell dumpsys connectivity | grep -i vpn yn dangos y rhwydweithiau VPN y mae’r system yn eu holrhain ar hyn o bryd. Nid yw’r naill na’r llall yn rhywbeth y gall sbardun lansio gymryd ei le.

Mae’r un rhesymu yn berthnasol ar ben arall y sesiwn. Mae dod â’r twnnel i lawr oherwydd bod un ffenestr wedi colli ffocws yn torri gwaith cefndir, cymorthwyr dilysu ac unrhyw ap arall a oedd yn dibynnu ar y cysylltiad. Diffiniwch ddiwedd sesiwn bwriadol yn hytrach na newid ffocws, ac osgowch ddilyniannau UP a DOWN cyflym pan fydd yr awtomeiddio’n newid cyd-destunau.

Gwiriwch y canlyniad, nid yr anfoniad

Mae darllediad sy’n dychwelyd heb wall wedi’i dderbyn gan Android a dim mwy. Darllenwch gyflwr y twnnel o’r ap, a darllenwch barodrwydd y llif gwaith o’r hyn y mae’r cam nesaf ei angen mewn gwirionedd. Dau wiriad gwahanol yw’r rhain, ac nid yw pasio’r cyntaf yn awgrymu’r ail.

Darllenwch gyflwr y rhyngwyneb yn uniongyrchol hefyd: mae adb shell ip -brief addr show tun0 yn argraffu rhyngwyneb y twnnel a’i gyfeiriad, ac mae rhyngwyneb sy’n bodoli heb gyfeiriad i fyny heb fod yn ddefnyddiadwy. Yna gwiriwch y gwasanaeth preifat ei hun, oherwydd mae twnnel sydd i fyny heb handshake neu heb lwybr yn methu’r dasg a oedd yn bwysig o hyd. Nid oes angen i awtomeiddio sy’n rheoli un cysylltiad a enwir o fewn ei ffin caniatâd wirioneddol tapio’r rhyngwyneb, rhedeg gorchymyn root na gwanhau amddiffyniadau rhwydwaith Android.