Tasker ja WireGuard: õige Intent ühe tunnelini jaoks

WireGuardi tegevuse käivitamine toob rakenduse ette, mitte ei tõsta kindlat tunnelit üles. Automatiseering, mis avab rakenduse ja ootab, läbib testi ja ebaõnnestub esimesel korral, kui telefon on juba avaekraanil. WireGuard pakub nimetatud tunnelite jaoks toetatud kaugjuhtimise teed ja see on kitsam, kui enamik retsepte vihjab. Allolev kontrollnimekiri käib selle tee läbi loast vaadeldud tulemuseni.

Kontrolli, kas kaugjuhtimine on lubatud

Kaugjuhtimise vastuvõtja ei kuula alati. WireGuardi seadetes on valik, mis lubab tunnelite kaugjuhtimist, ja kuni see valik on väljas, eirab vastuvõtja päringuid, selle asemel et valjult ebaõnnestuda. Vaikeväärtus on tahtlik, sest eksporditud vastuvõtja, mis suudaks tunneleid üles tõsta, oleks turvaauk igas seadmes, kuhu rakendus on paigaldatud. Luba see liidese kaudu ja kirjuta üles, et tegid seda, sest see on säte, mille tulevane kasutaja võib välja lülitada teadmata, millest see sõltus.

Ülalolev vastuvõtja käsitleb ainult nimetatud UP- ja DOWN-päringuid, seega siin ei ole teed tunnelit luua ega selle konfiguratsiooni muuta. Enne sellele toetumist kinnita, et komponent on paigaldatud buildis olemas: adb shell dumpsys package com.wireguard.android | grep -i receiver loetleb deklareeritud vastuvõtjad ja build ilma kaugjuhtimise vastuvõtjata ei vasta kunagi. Kui töövoog vajab teist lõpp-punkti või teist partnerit, on see teine tunnel ja eraldi käsitsi seadistus rakenduse sees.

Kontrolli, milline luba juhtlahendusel on

WireGuard kaitseb vastuvõtjat ohtliku loaga, com.wireguard.android.permission.CONTROL_TUNNELS, mis peab juhtival rakendusel olema. Oma saade ei suuda luua luba, mida saatja ei deklareerinud kunagi või mida talle kunagi ei antud. See on samm, kus automatiseerimise retseptid eeldavad vaikselt võimet, mida automatiseerimisel pole.

Kontrolli mõlemat poolt enne ülesande kirjutamist. Esimene käsk loetleb deklareeritud loa ja teine näitab, kas juhtlahenduse pakett seda tegelikult omab. Juhtlahendus, mis deklareerib loa oma manifestis, kuid ei saanud seda kunagi käitusajal, ebaõnnestub endiselt, ja ebaõnnestumine tuleb vaikusena, mitte dialoogina.

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

Kui juhtlahendusel pole luba, kasuta integreerimist, mida rakendus tegelikult toetab, selle asemel et saadet käsitsi ehitada. Intenti saatmine ja kutse õnnestumise nägemine tõestab ainult seda, et Android selle vastu võttis, mitte et WireGuard selle järgi tegutses. Käsitle kinnitamata saatmist tundmatuna, mitte õnnestumisena.

Kontrolli Intent välju paigaldatud rakenduse vastu

Neli välja kannavad kogu päringut ja igal on tõrkerežiim, mis näeb täpselt samasugune välja nagu teistel. Saa tegevus, tunneli lisaväli, pakett ja siht õigesti komplektina.

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

Tegevus nimetab UP või DOWN ja mitte midagi muud, lisaväli kannab täpset seadistatud tunneli nime, pakett piirab kohaletoimetamise WireGuardile ja siht peab olema vastuvõtja, mitte tegevus. Kirjaveaga tunneli nimi tekitab sama vaikuse kui väljalülitatud vastuvõtja, seega loe nimi rakenduses enne, kui järeldad, et automatiseerimine on katki. DOWN-tegevus on com.wireguard.android.action.SET_TUNNEL_DOWN sama lisavälja ja paketiga. Testimise ajal saada üks päring korraga, sest kaks saatet, mis teineteist taga ajavad, tekitavad oleku, mida keegi ei saa omistada.

Testi sama päringut seadme shellist, et eraldada Intent automatiseerimisest. Kui see käsk ebaõnnestub, samal ajal kui Taskeri ülesanne õnnestub, on erinevus saatja luba, mitte väljade väärtused.

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

Kontrolli, mida päästik ei kata

Rakenduse käivitamise või esiplaanile tulemise sündmus võib nõuda ühendust, kuid rakendus võib olla juba proovinud nimeotsingut või algset päringut enne, kui see sündmus käsitletakse. Päästik vallandub siis, kui süsteem märkab oleku muutust, mis on pärast seda, kui rakendus on tööd alustanud. Kui rakendus ei tohi kunagi väljaspool tunnelit suhelda, ei ole käivituspäästik blokeerimisreegel ja seda ei saa viivitust lisades selliseks muuta. Seadista blokeerimiskäitumise jaoks toetatud alati-ühendatud või rakendusepõhine poliitika ja hoia päästikut ainult mugavuse jaoks.

Blokeerimiskäitumine elab hoopis mujal. adb shell settings get global always_on_vpn_app nimetab paketi, mis on kinnitatud alati-ühendatud olekusse, ja adb shell dumpsys connectivity | grep -i vpn näitab VPN-võrke, mida süsteem praegu jälgib. Kumbki neist ei ole midagi, mida käivituspäästik saaks asendada.

Sama mõttekäik kehtib sessiooni teises otsas. Tunneli allatoomine seetõttu, et üks aken kaotas fookuse, lõhub taustatööd, autentimisabilised ja iga teise rakenduse, mis ühendusele lootis. Määra teadlik sessiooni lõpp, mitte fookuse muutus, ja väldi kiireid UP- ja DOWN-jadasid, kui automatiseerimine konteksti vahetab.

Kontrolli tulemust, mitte saatmist

Saade, mis naaseb veata, on Androidi poolt vastu võetud ja mitte rohkem. Loe tunneli olekut rakendusest ja töövoo valmidust sellest, mida järgmine samm tegelikult vajab. Need on kaks erinevat kontrolli ja esimese läbimine ei tähenda teist.

Loe ka liidese olekut otse: adb shell ip -brief addr show tun0 trükib tunneli liidese ja selle aadressi, ning liides, mis on olemas ilma aadressita, on üleval ilma kasutatav olemata. Seejärel kontrolli erateenust ennast, sest tunnel, mis on üleval ilma kätluseta või marsruudita, ebaõnnestub endiselt ülesandes, millel oli tähtsus. Automatiseerimine, mis juhib üht nimetatud ühendust oma tegeliku loa piires, ei pea liidest puudutama, root-käsku jooksutama ega Androidi võrgukaitset nõrgendama.