Tasker un WireGuard: pareizā Intent nosūtīšana vienam tunelim

WireGuard aktivitātes palaišana lietotni izvirza priekšplānā, bet nepaceļ konkrētu tuneli. Automatizācija, kas atver lietotni un gaida, izturēs testu un pirmajā reizē neizdosies, kad tālrunis jau atrodas sākuma ekrānā. WireGuard piedāvā atbalstītu tālvadības ceļu nosauktiem tuneļiem, un tas ir šaurāks, nekā liecina lielākā daļa recepšu. Zemāk esošais kontrolsaraksts iet šo ceļu no atļaujas līdz novērotajam rezultātam.

Pārbaudiet, vai tālvadība ir iespējota

Tālvadības uztvērējs ne vienmēr klausās. WireGuard iestatījumos ir opcija, kas iespējo tuneļu tālvadību, un, kamēr tā nav ieslēgta, uztvērējs ignorē pieprasījumus, nevis skaļi sabrūk. Noklusējums ir apzināts, jo eksportēts uztvērējs, kas varētu pacelt tuneļus, būtu drošības caurums katrā ierīcē, kurā lietotne ir instalēta. Iespējojiet to saskarnē un pierakstiet, ka to izdarījāt, jo tas ir iestatījums, ko nākamais lietotājs var izslēgt, nezinot, kas no tā bija atkarīgs.

Iepriekš minētais uztvērējs apstrādā tikai nosauktus UP un DOWN pieprasījumus, tāpēc šeit nav ceļa tuneļa izveidei vai tā konfigurācijas rediģēšanai. Pirms paļaujaties uz to, pārliecinieties, ka komponents ir instalētajā būvējumā: adb shell dumpsys package com.wireguard.android | grep -i receiver uzskaita deklarētos uztvērējus, un būvējums bez tālvadības uztvērēja nekad neatbildēs. Ja darbplūsmai vajag citu galapunktu vai citu partneri, tas ir cits tunelis un atsevišķa manuāla iestatīšana lietotnes iekšienē.

Pārbaudiet, kāda atļauja ir kontrolierim

WireGuard aizsargā uztvērēju ar bīstamu atļauju, com.wireguard.android.permission.CONTROL_TUNNELS, kurai jābūt pārvaldošajai lietotnei. Pašu izveidots apraide nevar radīt atļauju, ko sūtītājs nekad nav deklarējis vai kas tam nekad nav piešķirta. Šis ir solis, kurā automatizācijas receptes klusējot pieņem iespēju, kādas automatizācijai nav.

Pirms uzdevuma rakstīšanas pārbaudiet abas puses. Pirmā komanda uzskaita deklarēto atļauju, bet otrā parāda, vai kontroliera pakotnei tā patiešām ir. Kontrolieris, kas deklarē atļauju savā manifestā, bet izpildlaikā to nekad nav saņēmis, joprojām neizdosies, un neveiksme nāk kā klusums, nevis kā dialogs.

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

Ja kontrolierim nav atļaujas, izmantojiet integrāciju, ko lietotne patiešām atbalsta, nevis veidojiet apraidi ar roku. Intent nosūtīšana un veiksmīga izsaukuma redzēšana pierāda tikai to, ka Android to pieņēma, nevis to, ka WireGuard pēc tā rīkojās. Nepārbaudītu nosūtīšanu uzskatiet par nezināmu, nevis par panākumu.

Salīdziniet Intent laukus ar instalēto lietotni

Četri lauki nes visu pieprasījumu, un katram ir neveiksmes veids, kas izskatās tieši tāpat kā pārējiem. Pareizi iestatiet darbību, tuneļa papildu lauku, pakotni un mērķi kā vienu kopumu.

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

Darbība nosauc UP vai DOWN un neko citu, papildu lauks nes precīzu konfigurēto tuneļa nosaukumu, pakotne ierobežo piegādi ar WireGuard, un mērķim jābūt uztvērējam, nevis aktivitātei. Tuneļa nosaukums ar drukas kļūdu rada tādu pašu klusumu kā izslēgts uztvērējs, tāpēc nolasiet nosaukumu lietotnē, pirms secināt, ka automatizācija ir salauzta. DOWN darbība ir com.wireguard.android.action.SET_TUNNEL_DOWN ar to pašu papildu lauku un pakotni. Testēšanas laikā sūtiet vienu pieprasījumu vienlaikus, jo divas apraides, kas cenšas viena otru apsteigt, rada stāvokli, ko neviens nevar attiecināt.

Pārbaudiet to pašu pieprasījumu no ierīces čaulas, lai atdalītu Intent no automatizācijas. Ja šī komanda neizdodas, kamēr Tasker uzdevums izdodas, atšķirība ir sūtītāja atļauja, nevis lauku vērtības.

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

Pārbaudiet, ko trigeris neaptver

Lietotnes palaišanas vai priekšplāna notikums var pieprasīt savienojumu, bet lietotne jau var būt mēģinājusi nosaukuma meklēšanu vai sākotnējo pieprasījumu, pirms šis notikums tiek apstrādāts. Trigeris nostrādā, kad sistēma pamana stāvokļa izmaiņas, tas ir pēc tam, kad lietotne sākusi strādāt. Ja lietotnei nekad nav jāsazinās ārpus tuneļa, palaišanas trigeris nav bloķēšanas noteikums, un to nevar par tādu padarīt, pievienojot aizturi. Konfigurējiet atbalstītu vienmēr ieslēgtu vai uz lietotni attiecinātu politiku bloķēšanas uzvedībai, un trigeri paturiet tikai ērtībai.

Bloķēšanas uzvedība mīt pavisam citur. adb shell settings get global always_on_vpn_app nosauc pakotni, kas fiksēta kā vienmēr ieslēgta, un adb shell dumpsys connectivity | grep -i vpn parāda VPN tīklus, kurus sistēma pašlaik izseko. Nevienu no tiem palaišanas trigeris nevar aizstāt.

Tas pats pamatojums attiecas uz sesijas otru galu. Tuneļa nomešana tāpēc, ka viens logs zaudēja fokusu, salauž fona darbu, autentifikācijas palīgus un jebkuru citu lietotni, kas paļāvās uz savienojumu. Definējiet apzinātas sesijas beigas, nevis fokusa maiņu, un izvairieties no ātrām UP un DOWN secībām, kad automatizācija maina kontekstus.

Pārbaudiet rezultātu, nevis nosūtīšanu

Apraide, kas atgriežas bez kļūdas, ir pieņemta Android un nekas vairāk. Lasiet tuneļa stāvokli lietotnē, bet darbplūsmas gatavību lasiet tajā, kas nākamajam solim patiešām vajadzīgs. Tie ir divi dažādi pārbaudījumi, un pirmā izturēšana nenozīmē otro.

Lasiet arī saskarnes stāvokli tieši: adb shell ip -brief addr show tun0 izdrukā tuneļa saskarni un tās adresi, un saskarne, kas pastāv bez adreses, ir pacelta, bet nav lietojama. Pēc tam pārbaudiet pašu privāto pakalpojumu, jo tunelis, kas pacelts bez rokas sasveicināšanās vai bez maršruta, joprojām neizdodas uzdevumā, kuram bija nozīme. Automatizācijai, kas pārvalda vienu nosauktu savienojumu savas reālās atļaujas robežās, nav jāpieskaras saskarnei, jāpalaiž root komanda vai jāvājina Android tīkla aizsardzība.