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.