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.