Tasker og WireGuard: að senda rétta Intent fyrir einn göng

Að ræsa virkni WireGuard færir forrit fram í forgrunn, en rís ekki ákveðnum göngum. Sjálfvirkni sem opnar forritið og bíður mun standast prófið og mistakast í fyrsta skipti sem síminn situr þegar á heimaskjánum. WireGuard býður studda fjarstýringarleið fyrir nefnd göng, og hún er þrengri en flestar uppskriftir gefa til kynna. Gátlistinn hér fyrir neðan gengur þá leið frá heimild til athugaðrar niðurstöðu.

Athugaðu hvort fjarstýring er virk

Fjarstýringarmóttakarinn hlýðir ekki alltaf. Stillingar WireGuard innihalda valkost sem virkjar fjarstýringu ganga, og þar til sá valkostur er á hunsar móttakarinn beiðnir í stað þess að mistakast hávært. Sjálfgefið gildi er viljandi, því útfluttur móttakari sem gæti risið göngum væri öryggisgat á hverju tæki sem setti forritið upp. Virkjaðu hann í viðmótinu og skrifaðu hjá þér að þú gerðir það, því þetta er stilling sem framtíðarnotandi getur slökkt á án þess að vita hvað var háð henni.

Móttakarinn hér að ofan meðhöndlar aðeins nefndar UP- og DOWN-beiðnir, svo hér er engin leið til að búa til göng eða breyta stillingum þeirra. Staðfestu að einingin sé í uppsettu smíðinni áður en þú treystir á hana: adb shell dumpsys package com.wireguard.android | grep -i receiver telur upp skráða móttakara, og smíð án fjarstýringarmóttakarans svarar aldrei. Ef vinnuflæðið þarf annan endapunkt eða annan jafningja er það önnur göng og sérstök handvirk uppsetning inni í forritinu.

Athugaðu hvaða heimild stýringin hefur

WireGuard verndar móttakarann með hættulegri heimild, com.wireguard.android.permission.CONTROL_TUNNELS, sem stýriforritið verður að hafa. Sérsniðið útsending getur ekki búið til heimild sem sendandinn skráði aldrei eða fékk aldrei. Þetta er skrefið þar sem sjálfvirkniuppskriftir gera þegjandi ráð fyrir getu sem sjálfvirknin hefur ekki.

Athugaðu báðar hliðar áður en þú skrifar verkefnið. Fyrsta skipunin telur upp skráðu heimildina, og sú önnur sýnir hvort pakki stýringarinnar hefur hana í raun. Stýring sem skráir heimildina í manifestinu en fékk hana aldrei við keyrslu mistekst samt, og mistökin koma sem þögn frekar en sem gluggi.

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

Ef stýringin hefur ekki heimildina skaltu nota samþættinguna sem forritið styður í raun í stað þess að byggja útsendingu handvirkt. Að senda Intent og sjá að kallið tókst sannar aðeins að Android tók við því, ekki að WireGuard hafi brugðist við því. Líttu á óstaðfesta sendingu sem óþekkta, ekki sem árangur.

Berðu saman Intent-reiti og uppsetta forritið

Fjórir reitir bera alla beiðnina, og hver hefur misheppnunarmáta sem lítur nákvæmlega eins út og hinir. Fáðu aðgerðina, gönguviðbótina, pakkann og markið rétt sem eitt sett.

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

Aðgerðin nefnir UP eða DOWN og ekkert annað, viðbótin ber nákvæmt stillt gönguheiti, pakkinn takmarkar afhendingu við WireGuard, og markið verður að vera móttakarinn en ekki virkni. Gönguheiti með innsláttarvillu framleiðir sömu þögn og óvirkur móttakari, svo lestu heitið í forritinu áður en þú ályktar að sjálfvirknin sé brotin. DOWN-aðgerðin er com.wireguard.android.action.SET_TUNNEL_DOWN með sömu viðbót og pakka. Sendu eina beiðni í einu meðan þú prófar, því tvær útsendingar sem elta hvora aðra skapa stöðu sem enginn getur rakið.

Prófaðu sömu beiðni úr skel á tækinu til að aðskilja Intentið frá sjálfvirkninni. Ef sú skipun mistekst á meðan Tasker-verkefnið tekst er munurinn heimild sendandans en ekki gildi reitanna.

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

Athugaðu hvað kveikjan nær ekki yfir

Atburður um ræsingu forrits eða för í forgrunn getur beðið um tengingu, en forritið gæti þegar hafa reynt nafnaleit eða upphafsbeiðni áður en sá atburður er meðhöndlaður. Kveikjan fer af stað þegar kerfið tekur eftir stöðubreytingunni, sem er eftir að forritið byrjaði að vinna. Ef forritið má aldrei eiga samskipti utan ganganna er kveikja við ræsingu ekki blokkkunarregla og er ekki hægt að gera hana að slíkri með því að bæta við töf. Stilltu studda alltaf-á- eða fyrir-hvert-forrit stefnu fyrir blokkkunarhegðunina, og hafðu kveikjuna aðeins til þæginda.

Blokkkunarhegðunin býr allt annars staðar. adb shell settings get global always_on_vpn_app nefnir pakkann sem er festur sem alltaf-á, og adb shell dumpsys connectivity | grep -i vpn sýnir VPN-netin sem kerfið fylgist með núna. Hvort tveggja er eitthvað sem kveikja við ræsingu getur ekki komið í staðinn fyrir.

Sama röksemd á við á hinum enda setunnar. Að taka göngin niður af því að einn gluggi missti fókus eyðileggur bakgrunnsvinnu, auðkenningarhjálpara og hvert annað forrit sem reiddi sig á tenginguna. Skilgreindu viljandi setulok í stað fókusbreytingar, og forðastu hraðar UP- og DOWN-raðir þegar sjálfvirknin skiptir um samhengi.

Athugaðu niðurstöðuna, ekki sendinguna

Útsending sem kemur til baka án villu hefur verið samþykkt af Android og ekkert meira. Lestu stöðu ganganna úr forritinu, og lestu reiðubúnað vinnuflæðisins úr því sem næsta skref þarf í raun. Þetta eru tvö ólík próf, og að standast hið fyrra þýðir ekki hið síðara.

Lestu líka stöðu viðmótsins beint: adb shell ip -brief addr show tun0 prentar gangaviðmótið og vistfangið, og viðmót sem er til án vistfangs er uppi án þess að vera nothæft. Staðfestu síðan einkarekna þjónustuna sjálfa, því göng sem eru uppi án handbaks eða án slóðar mistakast samt verkefnið sem skipti máli. Sjálfvirkni sem stýrir einni nefndri tengingu innan raunverulegra heimildarmarka sinna þarf ekki að snerta viðmótið, keyra root-skipun eða veikja netvernd Android.