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.