Tasker og WireGuard: sende riktig Intent for én tunnel

Å starte WireGuard-aktiviteten bringer en app i forgrunnen, ikke en bestemt tunnel opp. En automatisering som åpner appen og venter, vil bestå i testen og feile første gang telefonen allerede står på hjemmeskjermen. WireGuard tilbyr en støttet fjernkontrollvei for navngitte tunneler, og den er smalere enn de fleste oppskrifter antyder. Sjekklisten nedenfor går den veien fra tillatelse til observert resultat.

Kontroller at fjernkontroll er slått på

Fjernkontrollmottakeren lytter ikke alltid. Innstillingene i WireGuard inneholder et valg som slår på fjernkontroll av tunneler, og så lenge det valget er av, ignorerer mottakeren forespørsler i stedet for å feile høyt. Standardverdien er bevisst, fordi en eksportert mottaker som kunne reise tunneler, ville være et sikkerhetshull på hver enhet der appen er installert. Slå den på via grensesnittet og skriv ned at du gjorde det, fordi det er en innstilling en fremtidig bruker kan slå av uten å vite hva som var avhengig av den.

Mottakeren ovenfor håndterer bare navngitte UP- og DOWN-forespørsler, så det finnes ingen vei her til å opprette en tunnel eller redigere konfigurasjonen dens. Bekreft at komponenten finnes i den installerte byggingen før du regner med den: adb shell dumpsys package com.wireguard.android | grep -i receiver viser de deklarerte mottakerne, og en bygging uten fjernkontrollmottakeren svarer aldri. Hvis arbeidsflyten trenger et annet endepunkt eller en annen peer, er det en annen tunnel og et eget manuelt oppsett inne i appen.

Kontroller hvilken tillatelse kontrolleren har

WireGuard beskytter mottakeren med en farlig tillatelse, com.wireguard.android.permission.CONTROL_TUNNELS, som den styrende appen må ha. En egen broadcast kan ikke fremstille en tillatelse som avsenderen aldri har deklarert eller aldri har fått. Dette er trinnet der automatiserte oppskrifter stille antar en evne automatiseringen ikke har.

Kontroller begge sider før du skriver oppgaven. Den første kommandoen viser den deklarerte tillatelsen, og den andre viser om pakken til kontrolleren faktisk har den. En kontroller som deklarerer tillatelsen i manifestet sitt, men aldri fikk den tildelt ved kjøring, feiler likevel, og feilen kommer som stillhet i stedet for som en dialog.

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

Hvis kontrolleren ikke har tillatelsen, bruk integrasjonen appen faktisk støtter i stedet for å bygge en broadcast for hånd. Å sende en Intent og se at kallet lyktes beviser bare at Android godtok det, ikke at WireGuard handlet på det. Behandle en uverifisert sending som ukjent, ikke som en suksess.

Kontroller Intent-feltene mot den installerte appen

Fire felt bærer hele forespørselen, og hvert har en feilmåte som ser nøyaktig ut som de andre. Få handlingen, tunnel-ekstraen, pakken og målet riktig som ett sett.

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

Handlingen navngir UP eller DOWN og ingenting annet, ekstraen bærer det nøyaktige konfigurerte tunnelnavnet, pakken begrenser leveringen til WireGuard, og målet må være mottakeren og ikke en aktivitet. Et tunnelnavn med skrivefeil gir samme stillhet som en deaktivert mottaker, så les navnet i appen før du konkluderer med at automatiseringen er ødelagt. DOWN-handlingen er com.wireguard.android.action.SET_TUNNEL_DOWN med den samme ekstraen og pakken. Send én forespørsel om gangen under testing, fordi to broadcaster som løper om kapp gir en tilstand ingen kan tilskrive.

Test den samme forespørselen fra et shell på enheten for å skille Intenten fra automatiseringen. Hvis kommandoen feiler mens Tasker-oppgaven lykkes, er forskjellen avsenderens tillatelse og ikke feltverdiene.

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 hva utløseren ikke dekker

En appstart- eller forgrunnshendelse kan be om en tilkobling, men appen kan allerede ha forsøkt navneoppslag eller en innledende forespørsel før hendelsen behandles. Utløseren fyrer når systemet merker tilstandsendringen, altså etter at appen har begynt å arbeide. Hvis appen aldri skal kommunisere utenfor tunnelen, er en startutløser ikke en blokkeringsregel og kan ikke gjøres til en ved å legge til en forsinkelse. Konfigurer en støttet alltid-på- eller per-app-policy for blokkeringsatferden, og behold utløseren bare for bekvemmelighet.

Blokkeringsatferden bor helt andre steder. adb shell settings get global always_on_vpn_app navngir pakken som er festet som alltid-på, og adb shell dumpsys connectivity | grep -i vpn viser VPN-nettverkene systemet følger akkurat nå. Ingen av dem er noe en startutløser kan erstatte.

Samme resonnement gjelder i den andre enden av økten. Å ta tunnelen ned fordi ett vindu mistet fokus ødelegger bakgrunnsarbeid, autentiseringshjelpere og enhver annen app som regnet med tilkoblingen. Definer en bevisst slutten av økten i stedet for et fokusskifte, og unngå raske UP- og DOWN-sekvenser når automatiseringen bytter kontekst.

Kontroller resultatet, ikke sendingen

En broadcast som kommer tilbake uten feil, er godtatt av Android og ikke mer. Les tunnelens tilstand fra appen, og les arbeidsflytens beredskap fra det neste trinn faktisk trenger. Det er to forskjellige kontroller, og å bestå den første innebærer ikke den andre.

Les også grensesnittets tilstand direkte: adb shell ip -brief addr show tun0 skriver ut tunnelgrensesnittet og adressen, og et grensesnitt som finnes uten adresse er oppe uten å være brukbart. Bekreft deretter selve den private tjenesten, fordi en tunnel som er oppe uten håndtrykk eller uten rute fortsatt feiler i oppgaven som betydde noe. En automatisering som styrer én navngitt tilkobling innenfor sin reelle tillatelsesgrense, trenger ikke å trykke på grensesnittet, kjøre en root-kommando eller svekke Androids nettverksbeskyttelse.