Tasker и WireGuard: слање исправног Intent-а за један тунел

Покретање активности WireGuard доводи апликацију у први план, а не подиже одређени тунел. Аутоматизација која отвара апликацију и чека проћи ће на тесту и пасти први пут када телефон већ стоји на почетном екрану. WireGuard нуди подржан пут даљинског управљања за именоване тунеле, и он је ужи него што већина рецепата сугерише. Контролна листа испод прелази тај пут од дозволе до запаженог резултата.

Проверите да ли је даљинско управљање укључено

Пријемник за даљинско управљање не слуша увек. Подешавања WireGuard-а укључују опцију која омогућава даљинско управљање тунелима, и док та опција није укључена, пријемник игнорише захтеве уместо да гласно не успе. Подразумевана вредност је намерна, јер би извезени пријемник који може да подигне тунеле био безбедносна рупа на сваком уређају на који је апликација инсталирана. Укључите је преко интерфејса и запишите да сте то учинили, јер је то подешавање које будући корисник може да искључи не знајући шта је од њега зависило.

Пријемник горе обрађује само именоване захтеве UP и DOWN, тако да овде нема пута за стварање тунела или уређивање његове конфигурације. Пре него што се на њега ослоните, потврдите да компонента постоји у инсталираној верзији: adb shell dumpsys package com.wireguard.android | grep -i receiver наводи декларисане пријемнике, а верзија без пријемника за даљинско управљање никада неће одговорити. Ако је радном току потребна друга крајња тачка или други партнер, то је други тунел и посебно ручно подешавање унутар апликације.

Проверите коју дозволу има контролер

WireGuard штити пријемник опасном дозволом, com.wireguard.android.permission.CONTROL_TUNNELS, коју апликација која управља мора да има. Сопствено емитовање не може да створи дозволу коју пошиљалац никада није декларисао или му никада није додељена. Ово је корак у којем рецепти за аутоматизацију тихо претпостављају способност коју аутоматизација нема.

Проверите обе стране пре писања задатка. Прва наредба наводи декларисану дозволу, а друга показује да ли је пакет контролера заиста има. Контролер који дозволу декларише у манифесту, али му никада није додељена током извршавања, ипак не успева, а неуспех долази као тишина, а не као дијалог.

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

Ако контролер нема дозволу, користите интеграцију коју апликација заиста подржава уместо да ручно градите емитовање. Слање Intent-а и виђење да је позив успео доказује само да га је Android прихватио, а не да је WireGuard поступио по њему. Третирајте непроверено слање као непознато, а не као успех.

Упоредите поља Intent-а са инсталираном апликацијом

Четири поља носе цео захтев, и свако има начин неуспеха који изгледа потпуно исто као остали. Поставите радњу, додатно поље тунела, пакет и циљ исправно као један скуп.

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

Радња именује UP или DOWN и ништа друго, додатно поље носи тачно конфигурисано име тунела, пакет ограничава испоруку на WireGuard, а циљ мора да буде пријемник, а не активност. Име тунела са словном грешком производи исти мук као искључен пријемник, зато прочитајте име у апликацији пре него што закључите да је аутоматизација покварена. Радња DOWN је com.wireguard.android.action.SET_TUNNEL_DOWN са истим додатним пољем и пакетом. Током тестирања шаљите један захтев одједном, јер два емитовања која се престижу стварају стање које нико не може да припише.

Тестирајте исти захтев из љуске на уређају да бисте одвојили Intent од аутоматизације. Ако та наредба не успе, а задатак у Tasker-у успе, разлика је дозвола пошиљаоца, а не вредности поља.

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

Проверите шта окидач не покрива

Догађај покретања или изласка апликације у први план може да затражи везу, али је апликација можда већ покушала тражење имена или почетни захтев пре него што је тај догађај обрађен. Окидач се активира када систем примети промену стања, то јест пошто је апликација почела да ради. Ако апликација никада не сме да комуницира изван тунела, окидач покретања није правило блокирања и не може се у такво претворити додавањем кашњења. Конфигуришите подржану политику сталног укључивања или по апликацији за понашање блокирања, а окидач задржите само ради удобности.

Понашање блокирања живи сасвим на другом месту. adb shell settings get global always_on_vpn_app именује пакет закачен као стално укључен, а adb shell dumpsys connectivity | grep -i vpn приказује VPN мреже које систем тренутно прати. Ниједно од тога није нешто што окидач покретања може да замени.

Исто размишљање важи на другом крају сесије. Спуштање тунела зато што је један прозор изгубио фокус квари рад у позадини, помагаче за аутентификацију и сваку другу апликацију која је рачунала на везу. Дефинишите намерни крај сесије уместо промене фокуса, и избегавајте брзе низове UP и DOWN када аутоматизација мења контексте.

Проверите резултат, а не слање

Емитовање које се врати без грешке Android је прихватио и ништа више. Читајте стање тунела из апликације, а спремност радног тока из онога што следећем кораку заиста треба. То су две различите провере, и пролазак прве не подразумева другу.

Читајте и стање интерфејса директно: adb shell ip -brief addr show tun0 исписује интерфејс тунела и његову адресу, а интерфејс који постоји без адресе је подигнут, али није употребљив. Затим проверите саму приватну услугу, јер тунел подигнут без руковању или без руте ипак не успева у задатку који је био важан. Аутоматизација која управља једном именованом везом у оквиру својих стварних граница дозволе не мора да дира интерфејс, извршава root наредбу или слаби мрежне заштите Android-а.