Tasker og WireGuard: send riktig Intent for éin tunnel

Å starte WireGuard-aktiviteten bringer ein app i forgrunnen, ikkje ein bestemd tunnel opp. Ein automatisering som opnar appen og ventar, vil gå gjennom i testen og feile fyrste gong telefonen allereie står på heimeskjermen. WireGuard tilbyr ein støtta fjernkontrollveg for namngitte tunnelar, og han er smalare enn dei fleste oppskriftene antydar. Sjekklista nedanfor går den vegen frå løyve til observert resultat.

Kontroller at fjernkontroll er slått på

Fjernkontrollmottakaren lyttar ikkje alltid. Innstillingane i WireGuard inneheld eit val som slår på fjernkontroll av tunnelar, og så lenge det valet er av, ignorerer mottakaren førespurnader i staden for å feile høgt. Standardverdien er medvite vald, fordi ein eksportert mottakar som kunne reise tunnelar, ville vere eit sikkerheitshol på kvar eining der appen er installert. Slå han på via grensesnittet og skriv ned at du gjorde det, fordi det er ei innstilling ein framtidig brukar kan slå av utan å vite kva som var avhengig av henne.

Mottakaren ovanfor handterer berre namngitte UP- og DOWN-førespurnader, så det finst ingen veg her til å opprette ein tunnel eller redigere konfigurasjonen hans. Stadfest at komponenten finst i den installerte bygginga før du reknar med han: adb shell dumpsys package com.wireguard.android | grep -i receiver viser dei deklarerte mottakarane, og ei bygging utan fjernkontrollmottakaren svarar aldri. Viss arbeidsflyten treng eit anna endepunkt eller ein annan partnar, er det ein annan tunnel og eit eige manuelt oppsett inne i appen.

Kontroller kva løyve kontrolløren har

WireGuard verner mottakaren med eit farleg løyve, com.wireguard.android.permission.CONTROL_TUNNELS, som den styrande appen må ha. Ein eigen broadcast kan ikkje lage eit løyve som avsendaren aldri har deklarert eller aldri har fått. Dette er trinnet der automatiserte oppskrifter stille går ut frå ei evne som automatiseringa ikkje har.

Kontroller begge sider før du skriv oppgåva. Den fyrste kommandoen viser det deklarerte løyvet, og den andre viser om pakken til kontrolløren faktisk har det. Ein kontrollør som deklarerer løyvet i manifestet sitt, men aldri fekk det tildelt ved køyring, feilar likevel, og feilen kjem som stille i staden for som ein dialog.

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

Viss kontrolløren ikkje har løyvet, bruk integrasjonen appen faktisk støttar i staden for å byggje ein broadcast for hand. Å sende ein Intent og sjå at kallet lukkast beviser berre at Android godtok det, ikkje at WireGuard handla på det. Behandle ei uverifisert sending som ukjend, ikkje som ein suksess.

Kontroller Intent-felta mot den installerte appen

Fire felt ber heile førespurnaden, og kvart har ein feilmåte som ser nøyaktig ut som dei andre. Få handlinga, tunnel-ekstraen, pakken og målet rett som eitt sett.

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

Handlinga namngir UP eller DOWN og ingenting anna, ekstraen ber det nøyaktige konfigurerte tunnelnamnet, pakken avgrensar leveringa til WireGuard, og målet må vere mottakaren og ikkje ei aktivitet. Eit tunnelnamn med skrivefeil gir same stille som ein deaktivert mottakar, så les namnet i appen før du konkluderer med at automatiseringa er øydelagd. DOWN-handlinga er com.wireguard.android.action.SET_TUNNEL_DOWN med den same ekstraen og pakken. Send éin førespurnad om gongen under testing, fordi to broadcasts som spring om kapp gir ein tilstand ingen kan tilskrive.

Test den same førespurnaden frå eit skal på eininga for å skilje Intenten frå automatiseringa. Viss kommandoen feilar medan Tasker-oppgåva lukkast, er skilnaden løyvet til avsendaren og ikkje feltverdiane.

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

Kontroller kva utløysaren ikkje dekkjer

Ei hending ved oppstart eller når appen kjem i forgrunnen kan be om ei tilkopling, men appen kan allereie ha prøvd namneoppslag eller ein innleiande førespurnad før hendinga blir handsama. Utløysaren fyrer når systemet merkar tilstandsendringa, altså etter at appen har byrja å arbeide. Viss appen aldri skal kommunisere utanfor tunnelen, er ein startutløysar ikkje ein blokkeringsregel og kan ikkje bli det ved å leggje til ei forseinking. Konfigurer ein støtta alltid-på- eller per-app-policy for blokkeringsåtferda, og hald utløysaren berre for enkelheit.

Blokkeringsåtferda bur heilt andre stader. adb shell settings get global always_on_vpn_app namngir pakken som er festa som alltid-på, og adb shell dumpsys connectivity | grep -i vpn viser VPN-nettverka systemet følgjer akkurat no. Ingen av dei er noko ein startutløysar kan erstatte.

Same resonnementet gjeld i den andre enden av økta. Å ta tunnelen ned fordi eitt vindauge mista fokus, øydelegg bakgrunnsarbeid, autentiseringshjelparar og kvar annan app som rekna med tilkoplinga. Definer ein medviten slutt på økta i staden for eit fokusskifte, og unngå raske UP- og DOWN-rekkjer når automatiseringa byter kontekst.

Kontroller resultatet, ikkje sendinga

Ein broadcast som kjem tilbake utan feil, er godteken av Android og ikkje meir. Les tilstanden til tunnelen frå appen, og les beredskapen til arbeidsflyten frå det neste trinnet faktisk treng. Det er to ulike kontrollar, og å klare den fyrste inneber ikkje den andre.

Les òg tilstanden til grensesnittet direkte: adb shell ip -brief addr show tun0 skriv ut tunnelgrensesnittet og adressa, og eit grensesnitt som finst utan adresse er oppe utan å vere brukbart. Stadfest deretter sjølve den private tenesta, fordi ein tunnel som er oppe utan handtrykk eller utan rute framleis feilar i oppgåva som betydde noko. Ei automatisering som styrer éi namngitt tilkopling innanfor si reelle løyvegrense, treng ikkje å trykkje på grensesnittet, køyre ein root-kommando eller svekkje nettverksvernet til Android.