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.