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.