Tasker og WireGuard: den rigtige intent til én tunnel

Når WireGuard-aktiviteten startes, bringes en app i forgrunden, ikke en bestemt tunnel op. En automatisering, der åbner appen og venter, består i testen og fejler første gang, telefonen allerede står på hjemmeskærmen. WireGuard stiller en understøttet fjernstyringsvej til rådighed for navngivne tunneler, og den er smallere, end de fleste opskrifter antyder. Tjeklisten nedenfor går ad den vej fra tilladelse til observeret resultat.

Kontroller, at fjernstyring er slået til

Fjernstyringsmodtageren lytter ikke altid. WireGuard-indstillingerne indeholder en mulighed, der slår fjernstyring af tunneler til, og indtil den er slået til, ignorerer modtageren anmodninger i stedet for at fejle højlydt. Standarden er bevidst, fordi en eksporteret modtager, der kunne rejse tunneler, ville være et sikkerhedshul på enhver enhed, hvor appen er installeret. Slå den til via grænsefladen, og skriv ned, at du gjorde det, fordi det er en indstilling, en fremtidig bruger kan slå fra uden at vide, hvad der afhang af den.

Modtageren ovenover håndterer kun navngivne UP- og DOWN-anmodninger, så der er ingen vej her til at oprette en tunnel eller redigere dens konfiguration. Bekræft, at komponenten findes i den installerede build, før du regner med den: adb shell dumpsys package com.wireguard.android | grep -i receiver viser de deklarerede modtagere, og en build uden fjernstyringsmodtageren svarer aldrig. Hvis arbejdsgangen har brug for et andet endepunkt eller en anden peer, er det en anden tunnel og en særskilt manuel opsætning inde i appen.

Kontroller hvilken tilladelse styringen har

WireGuard beskytter modtageren med en farlig tilladelse, com.wireguard.android.permission.CONTROL_TUNNELS, som den styrende app skal have. En egen broadcast kan ikke fremstille en tilladelse, som afsenderen aldrig har deklareret eller aldrig har fået. Det er det trin, hvor automatiseringsopskrifter stille antager en evne, som automatiseringen ikke har.

Kontroller begge sider, før du skriver opgaven. Den første kommando viser den deklarerede tilladelse, og den anden viser, om styringens pakke faktisk har den. En styring, der deklarerer tilladelsen i sin manifest, men aldrig fik den tildelt ved kørsel, fejler stadig, og fejlen kommer som tavshed 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 styringen ikke har tilladelsen, brug den integration, appen faktisk understøtter, i stedet for at bygge en broadcast i hånden. At sende en intent og se, at kaldet lykkedes, beviser kun, at Android accepterede det, ikke at WireGuard handlede på det. Behandl en uverificeret afsendelse som ukendt, ikke som en succes.

Kontroller intent-felterne mod den installerede app

Fire felter bærer hele anmodningen, og hvert har en fejlmåde, der ser præcis ud som de andre. Få handlingen, tunnel-ekstraen, pakken og målet rigtigt som et sæt.

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

Handlingen navngiver UP eller DOWN og intet andet, ekstraen bærer det præcise konfigurerede tunnelnavn, pakken begrænser leveringen til WireGuard, og målet skal være modtageren frem for en aktivitet. Et tunnelnavn med en slåfejl giver den samme tavshed som en deaktiveret modtager, så læs navnet i appen, før du konkluderer, at automatiseringen er i stykker. DOWN-handlingen er com.wireguard.android.action.SET_TUNNEL_DOWN med den samme ekstra og pakke. Send én anmodning ad gangen under test, fordi to broadcasts, der løber om kap, giver en tilstand, som ingen kan tilskrive.

Test den samme anmodning fra en shell på enheden for at skille intenten fra automatiseringen. Hvis kommandoen fejler, mens Tasker-opgaven lykkes, er forskellen afsenderens tilladelse og ikke feltværdierne.

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, hvad triggeren ikke dækker

En app-start- eller forgrundshændelse kan anmode om en forbindelse, men appen kan allerede have forsøgt et navneopslag eller en indledende anmodning, før hændelsen behandles. Triggeren udløses, når systemet bemærker tilstandsændringen, hvilket er efter, at appen er begyndt at arbejde. Hvis appen aldrig må kommunikere uden for tunnelen, er en start-trigger ikke en blokeringsregel og kan ikke gøres til én ved at tilføje en forsinkelse. Konfigurer en understøttet altid-til- eller per-app-politik for blokeringsadfærden, og behold triggeren kun for bekvemmelighed.

Blokeringsadfærden bor et helt andet sted. adb shell settings get global always_on_vpn_app navngiver den pakke, der er fastgjort som altid-til, og adb shell dumpsys connectivity | grep -i vpn viser de VPN-netværk, som systemet følger lige nu. Ingen af dem er noget, en start-trigger kan erstatte.

Den samme ræsonnement gælder i den anden ende af sessionen. At tage tunnelen ned, fordi ét vindue mistede fokus, ødelægger baggrundsarbejde, godkendelseshjælpere og enhver anden app, der regnede med forbindelsen. Definer en bevidst afslutning af sessionen i stedet for et fokusskift, og undgå hurtige UP- og DOWN-sekvenser, når automatiseringen skifter kontekst.

Kontroller resultatet, ikke afsendelsen

En broadcast, der vender tilbage uden fejl, er accepteret af Android og intet mere. Læs tunnelens tilstand fra appen, og læs arbejdsgangens parathed ud fra, hvad næste trin faktisk har brug for. Det er to forskellige kontroller, og at bestå den første indebærer ikke den anden.

Læs også grænsefladens tilstand direkte: adb shell ip -brief addr show tun0 udskriver tunnelgrænsefladen og dens adresse, og en grænseflade, der findes uden adresse, er oppe uden at være brugbar. Bekræft derefter selve den private tjeneste, fordi en tunnel, der er oppe uden handshake eller uden rute, stadig fejler i den opgave, der betød noget. En automatisering, der styrer én navngivet forbindelse inden for sin reelle tilladelsesgrænse, behøver ikke at trykke på grænsefladen, køre en root-kommando eller svække Androids netværksbeskyttelser.