Tasker at WireGuard: pagpapadala ng tamang Intent para sa isang tunnel

Ang pagsisimula ng aktibidad ng WireGuard ay nagdadala ng app sa harapan, hindi nag-aangat ng partikular na tunnel. Ang automation na nagbubukas ng app at naghihintay ay papasa sa pagsubok at mabibigo sa unang pagkakataon na ang telepono ay nakaupo na sa home screen. Nagbibigay ang WireGuard ng sinusuportahang landas ng remote control para sa mga pinangalanang tunnel, at ito ay mas makitid kaysa sa iminumungkahi ng karamihan ng recipe. Ang checklist sa ibaba ay dumadaan sa landas na iyon mula sa pahintulot hanggang sa naobserbahang resulta.

Tiyakin na naka-enable ang remote control

Hindi laging nakikinig ang remote-control receiver. May opsyon sa mga setting ng WireGuard na nagbibigay-daan sa remote control ng mga tunnel, at hangga't hindi ito naka-on, binabalewala ng receiver ang mga kahilingan sa halip na mabigong malakas. Sinasadya ang default, dahil ang naka-export na receiver na makakapag-angat ng mga tunnel ay magiging butas sa seguridad sa bawat device na nag-install ng app. I-enable ito sa interface at isulat na ginawa mo, dahil ito ay setting na maaaring patayin ng susunod na user nang hindi alam kung ano ang umaasa rito.

Ang receiver sa itaas ay humahawak lamang ng mga pinangalanang kahilingang UP at DOWN, kaya walang landas dito upang gumawa ng tunnel o i-edit ang configuration nito. Tiyakin na umiiral ang component sa naka-install na build bago umasa rito: inililista ng adb shell dumpsys package com.wireguard.android | grep -i receiver ang mga idineklarang receiver, at ang build na walang remote-control receiver ay hindi kailanman sasagot. Kung kailangan ng workflow ng ibang endpoint o ibang peer, iyon ay ibang tunnel at hiwalay na manu-manong setup sa loob ng app.

Tiyakin ang pahintulot na hawak ng controller

Pinoprotektahan ng WireGuard ang receiver gamit ang mapanganib na pahintulot, com.wireguard.android.permission.CONTROL_TUNNELS, na dapat hawak ng controlling app. Hindi makakagawa ang custom na broadcast ng pahintulot na hindi kailanman idineklara ng sender o hindi kailanman ibinigay dito. Ito ang hakbang kung saan tahimik na ipinapalagay ng mga recipe ng automation ang kakayahang wala sa automation.

Tingnan ang dalawang panig bago isulat ang gawain. Inililista ng unang command ang idineklarang pahintulot, at ipinapakita ng pangalawa kung talagang hawak ito ng package ng controller. Ang controller na nagdeklara ng pahintulot sa manifest nito ngunit hindi kailanman nabigyan sa runtime ay nabibigo pa rin, at dumarating ang kabiguan bilang katahimikan sa halip na dialog.

adb shell pm list permissions -g -d | grep -i control_tunnels
adb shell dumpsys package net.dinglisch.android.taskerm | grep -i control_tunnels

Kung wala sa controller ang pahintulot, gamitin ang integrasyon na talagang sinusuportahan ng app sa halip na mano-manong bumuo ng broadcast. Ang pagpapadala ng Intent at pagkitang nagtagumpay ang tawag ay nagpapatunay lamang na tinanggap ito ng Android, hindi na kumilos ang WireGuard ayon dito. Ituring ang hindi na-verify na pagpapadala bilang hindi alam, hindi bilang tagumpay.

Itugma ang mga field ng Intent sa naka-install na app

Apat na field ang nagdadala ng buong kahilingan, at bawat isa ay may paraan ng kabiguan na eksaktong kamukha ng iba. Tamang makuha ang aksyon, ang extra ng tunnel, ang package at ang target bilang isang set.

Action:  com.wireguard.android.action.SET_TUNNEL_UP
Extra:   tunnel:lab-wg
Package: com.wireguard.android
Target:  Broadcast Receiver

Pinapangalanan ng aksyon ang UP o DOWN at wala nang iba, dinadala ng extra ang eksaktong naka-configure na pangalan ng tunnel, nililimitahan ng package ang paghahatid sa WireGuard, at ang target ay dapat ang receiver at hindi isang aktibidad. Ang pangalan ng tunnel na may typo ay gumagawa ng parehong katahimikan tulad ng patay na receiver, kaya basahin ang pangalan sa app bago magpasyang sira ang automation. Ang aksyong DOWN ay com.wireguard.android.action.SET_TUNNEL_DOWN na may parehong extra at package. Magpadala ng isang kahilingan sa isang pagkakataon habang nagsubok, dahil ang dalawang broadcast na nag-uunahan ay gumagawa ng estadong walang makapag-uugnay.

Subukan ang parehong kahilingan mula sa shell sa device upang ihiwalay ang Intent sa automation. Kung nabibigo ang command na iyon habang nagtatagumpay ang gawain sa Tasker, ang pagkakaiba ay ang pahintulot ng sender at hindi ang mga halaga ng field.

adb shell am broadcast -a com.wireguard.android.action.SET_TUNNEL_UP -e tunnel lab-wg --receiver-permission com.wireguard.android.permission.CONTROL_TUNNELS

Tiyakin kung ano ang hindi sakop ng trigger

Ang event ng paglunsad o pagharap ng app ay maaaring humiling ng koneksyon, ngunit maaaring sinubukan na ng app ang paghahanap ng pangalan o paunang kahilingan bago pa maproseso ang event na iyon. Pumapaputok ang trigger kapag napansin ng system ang pagbabago ng estado, na pagkatapos magsimulang magtrabaho ang app. Kung hindi kailanman dapat makipag-ugnayan ang app sa labas ng tunnel, ang trigger ng paglunsad ay hindi patakaran ng pagharang at hindi ito magagawang ganoon sa pamamagitan ng pagdaragdag ng pagkaantala. I-configure ang sinusuportahang patakaran ng laging-naka-on o kada-app para sa pag-uugali ng pagharang, at panatilihin ang trigger para sa kaginhawahan lamang.

Nakatira ang pag-uugali ng pagharang sa ibang lugar nang buo. Pinapangalanan ng adb shell settings get global always_on_vpn_app ang package na naka-pin bilang laging-naka-on, at ipinapakita ng adb shell dumpsys connectivity | grep -i vpn ang mga VPN network na sinusubaybayan ng system ngayon. Wala sa dalawa ang kayang palitan ng trigger ng paglunsad.

Ganoon din ang pangangatwiran sa kabilang dulo ng sesyon. Ang pagbaba ng tunnel dahil nawalan ng focus ang isang window ay sumisira sa trabahong nasa background, mga helper ng authentication at anumang ibang app na umasa sa koneksyon. Tukuyin ang sinadyang pagtatapos ng sesyon sa halip na pagbabago ng focus, at iwasan ang mabilis na pagkakasunod-sunod ng UP at DOWN kapag nagpapalit ng konteksto ang automation.

Tingnan ang resulta, hindi ang pagpapadala

Ang broadcast na bumabalik nang walang error ay tinanggap ng Android at wala nang iba. Basahin ang estado ng tunnel mula sa app, at basahin ang kahandaan ng workflow mula sa talagang kailangan ng susunod na hakbang. Dalawang magkaibang pagsusuri iyon, at ang pagpasa sa una ay hindi nangangahulugan ng pangalawa.

Basahin din ang estado ng interface nang direkta: ipiniprint ng adb shell ip -brief addr show tun0 ang interface ng tunnel at ang address nito, at ang interface na umiiral nang walang address ay nakaangat ngunit hindi magagamit. Pagkatapos i-verify ang pribadong serbisyo mismo, dahil ang tunnel na nakaangat nang walang handshake o walang ruta ay nabibigo pa rin sa gawaing mahalaga. Ang automation na kumokontrol ng isang pinangalanang koneksyon sa loob ng tunay nitong hangganan ng pahintulot ay hindi kailangang tapikin ang interface, magpatakbo ng root command o pahinain ang mga proteksyon ng network ng Android.