Tasker en WireGuard: die regte intent vir een tonnel

Om die WireGuard-aktiwiteit te begin, bring ’n app na die voorgrond, nie ’n bepaalde tonnel op nie. ’n Outomatisering wat die app oopmaak en wag, sal in die toets slaag en die eerste keer misluk wanneer die foon reeds op die tuisskerm sit. WireGuard bied ’n ondersteunde afstandsbeheer-pad vir genoemde tonnele, en dit is smaller as wat die meeste resepte voorstel. Die kontrolelys hieronder volg daardie pad van toestemming tot waargeneemde resultaat.

Kontroleer of afstandsbeheer geaktiveer is

Die afstandsbeheer-ontvanger luister nie altyd nie. WireGuard se instellings sluit ’n opsie in wat afstandsbeheer van tonnele aktiveer, en totdat daardie opsie aan is, ignoreer die ontvanger versoeke in plaas daarvan om hard te misluk. Die verstek is doelbewus, want ’n uitgevoerde ontvanger wat tonnele kon oopmaak, sou ’n sekuriteitsgat op elke toestel wees wat die app geïnstalleer het. Aktiveer dit deur die koppelvlak en skryf neer dat jy dit gedoen het, want dit is ’n instelling wat ’n toekomstige gebruiker kan afskakel sonder om te weet wat daarvan afhanklik was.

Die opstroom-ontvanger hanteer slegs genoemde UP- en DOWN-versoeke, so daar is geen pad hier om ’n tonnel te skep of sy konfigurasie te wysig nie. Bevestig dat die komponent in die geïnstalleerde bou bestaan voordat jy daarop staatmaak: adb shell dumpsys package com.wireguard.android | grep -i receiver lys die verklaarde ontvangers, en ’n bou sonder die afstandsbeheer-ontvanger sal nooit antwoord nie. As die werkvloei ’n ander eindpunt of ’n ander eweknie nodig het, is dit ’n ander tonnel en ’n afsonderlike handmatige opstelling binne die app.

Kontroleer watter toestemming die beheerder het

WireGuard beskerm die ontvanger met ’n gevaarlike toestemming, com.wireguard.android.permission.CONTROL_TUNNELS, wat die beherende app moet hê. ’n Pasgemaakte uitsending kan nie ’n toestemming skep wat die sender nooit verklaar het of nooit toegestaan is nie. Dit is die stap waar outomatiseringsresepte stilweg ’n vermoë aanneem wat die outomatisering nie het nie.

Kontroleer beide kante voordat jy die taak skryf. Die eerste opdrag lys die verklaarde toestemming, en die tweede wys of die beheerderpakket dit werklik het. ’n Beheerder wat die toestemming in sy manifest verklaar maar dit nooit tydens looptyd toegestaan is nie, misluk steeds, en die mislukking kom as stilte eerder as as ’n dialoog.

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

As die beheerder nie die toestemming het nie, gebruik die integrasie wat die app werklik ondersteun in plaas daarvan om ’n uitsending met die hand te bou. Om ’n intent te stuur en te sien dat die oproep geslaag het, bewys net dat Android dit aanvaar het, nie dat WireGuard daarop gereageer het nie. Behandel ’n ongeverifieerde stuur as ’n onbekende, nie as ’n sukses nie.

Kontroleer die intent-velde teen die geïnstalleerde app

Vier velde dra die hele versoek, en elkeen het ’n mislukkingsmodus wat presies soos die ander lyk. Kry die aksie, die tonnel-extra, die pakket en die teiken as ’n stel reg.

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

Die aksie noem UP of DOWN en niks anders nie, die extra dra die presiese gekonfigureerde tonnelnaam, die pakket beperk aflewering tot WireGuard, en die teiken moet die ontvanger wees eerder as ’n aktiwiteit. ’n Tonnelnaam met ’n tikfout lewer dieselfde stilte as ’n gedeaktiveerde ontvanger, so lees die naam in die app voordat jy tot die gevolgtrekking kom dat die outomatisering stukkend is. Die DOWN-aksie is com.wireguard.android.action.SET_TUNNEL_DOWN met dieselfde extra en pakket. Stuur een versoek op ’n slag terwyl jy toets, want twee uitsendings wat mekaar inhaal lewer ’n toestand op wat niemand kan toeskryf nie.

Toets dieselfde versoek vanaf ’n dop op die toestel om die intent van die outomatisering te skei. As daardie opdrag misluk terwyl die Tasker-taak slaag, is die verskil die sender se toestemming eerder as die veldwaardes.

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

Kontroleer wat die sneller nie dek nie

’n App-begin- of voorgrondgebeurtenis kan ’n verbinding aanvra, maar die app het dalk reeds ’n naamsoektog of ’n aanvanklike versoek probeer voordat daardie gebeurtenis hanteer is. Die sneller vuur wanneer die stelsel die toestandsverandering opmerk, wat ná die app begin werk het is. As die app nooit buite die tonnel mag kommunikeer nie, is ’n begin-sneller nie ’n blokkeringsreël nie en kan dit nie een gemaak word deur ’n vertraging by te voeg nie. Konfigureer ’n ondersteunde altyd-aan- of per-app-beleid vir die blokkeringsgedrag, en hou die sneller slegs vir gerief.

Die blokkeringsgedrag woon heeltemal elders. adb shell settings get global always_on_vpn_app noem die pakket wat as altyd-aan vasgepen is, en adb shell dumpsys connectivity | grep -i vpn wys die VPN-netwerke wat die stelsel tans volg. Nie een van dié is iets waarvoor ’n begin-sneller kan instaan nie.

Dieselfde redenasie geld aan die ander kant van die sessie. Om die tonnel af te bring omdat een venster fokus verloor het, breek agtergrondwerk, verifikasiehulpmiddels en enige ander app wat op die verbinding staatgemaak het. Definieer ’n doelbewuste einde van die sessie eerder as ’n fokusverandering, en vermy vinnige UP- en DOWN-reekse wanneer die outomatisering kontekste wissel.

Kontroleer die resultaat, nie die stuur nie

’n Uitsending wat sonder ’n fout terugkeer, is deur Android aanvaar en niks meer nie. Lees die tonneltoestand uit die app, en lees die werkvloei-gereedheid uit wat die volgende stap werklik nodig het. Dit is twee verskillende kontroles, en om die eerste te slaag beteken nie die tweede nie.

Lees ook die koppelvlaktoestand direk: adb shell ip -brief addr show tun0 druk die tonnelkoppelvlak en sy adres, en ’n koppelvlak wat bestaan sonder ’n adres is op sonder om bruikbaar te wees. Verifieer dan die private diens self, want ’n tonnel wat op is sonder ’n handdruk of sonder ’n roete slaag steeds nie die taak wat saak gemaak het nie. ’n Outomatisering wat een genoemde verbinding binne sy werklike toestemminggrens beheer, hoef nie die koppelvlak te tik, ’n root-opdrag te hardloop of Android se netwerkbeskermings te verswak nie.