Tasker och WireGuard: skicka rätt Intent för en tunnel

Att starta WireGuard-aktiviteten tar en app till förgrunden, inte upp en viss tunnel. En automatisering som öppnar appen och väntar klarar testet och misslyckas första gången telefonen redan står på hemskärmen. WireGuard erbjuder en stödd fjärrkontrollväg för namngivna tunnlar, och den är smalare än de flesta recept antyder. Checklistan nedan går den vägen från behörighet till observerat resultat.

Kontrollera att fjärrkontroll är påslagen

Fjärrkontrollmottagaren lyssnar inte alltid. Inställningarna i WireGuard innehåller ett val som slår på fjärrkontroll av tunnlar, och så länge det valet är av ignoreras förfrågningar av mottagaren i stället för att misslyckas högljutt. Standardvärdet är avsiktligt, eftersom en exporterad mottagare som kunde resa tunnlar skulle vara en säkerhetsläcka på varje enhet där appen är installerad. Slå på den via gränssnittet och skriv ned att du gjorde det, eftersom det är en inställning som en framtida användare kan stänga av utan att veta vad som berodde på den.

Mottagaren ovan hanterar bara namngivna UP- och DOWN-förfrågningar, så här finns ingen väg att skapa en tunnel eller redigera dess konfiguration. Bekräfta att komponenten finns i den installerade byggversionen innan du förlitar dig på den: adb shell dumpsys package com.wireguard.android | grep -i receiver listar de deklarerade mottagarna, och en byggversion utan fjärrkontrollmottagaren svarar aldrig. Om arbetsflödet behöver en annan ändpunkt eller en annan peer är det en annan tunnel och en separat manuell inställning inuti appen.

Kontrollera vilken behörighet styrenheten har

WireGuard skyddar mottagaren med en farlig behörighet, com.wireguard.android.permission.CONTROL_TUNNELS, som den styrande appen måste ha. En egen sändning kan inte skapa en behörighet som avsändaren aldrig deklarerade eller aldrig fick. Det här är steget där automatiseringsrecept tyst förutsätter en förmåga som automatiseringen inte har.

Kontrollera båda sidor innan du skriver uppgiften. Det första kommandot listar den deklarerade behörigheten, och det andra visar om styrenhetens paket faktiskt har den. En styrenhet som deklarerar behörigheten i sin manifest men aldrig fick den tilldelad vid körning misslyckas ändå, och felet kommer som tystnad i stället för 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

Om styrenheten inte har behörigheten, använd integrationen som appen faktiskt stöder i stället för att bygga en sändning för hand. Att skicka en Intent och se att anropet lyckades bevisar bara att Android tog emot den, inte att WireGuard agerade på den. Behandla en overifierad sändning som okänd, inte som en framgång.

Kontrollera Intent-fälten mot den installerade appen

Fyra fält bär hela förfrågan, och varje fält har ett felbeteende som ser exakt ut som de andra. Få åtgärden, tunnel-extra, paketet och målet rätt som en uppsättning.

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

Åtgärden namnger UP eller DOWN och inget annat, extra-fältet bär det exakta konfigurerade tunnelnamnet, paketet begränsar leveransen till WireGuard, och målet måste vara mottagaren och inte en aktivitet. Ett tunnelnamn med stavfel ger samma tystnad som en avstängd mottagare, så läs namnet i appen innan du drar slutsatsen att automatiseringen är trasig. DOWN-åtgärden är com.wireguard.android.action.SET_TUNNEL_DOWN med samma extra-fält och paket. Skicka en förfrågan i taget under testning, eftersom två sändningar som jagar varandra ger ett tillstånd som ingen kan tillskriva.

Testa samma förfrågan från ett skal på enheten för att skilja Intenten från automatiseringen. Om kommandot misslyckas medan Tasker-uppgiften lyckas är skillnaden avsändarens behörighet och inte fältvärdena.

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

Kontrollera vad utlösaren inte täcker

En appstart- eller förgrundshändelse kan begära en anslutning, men appen kan redan ha försökt med en namnsökning eller en inledande förfrågan innan händelsen hanteras. Utlösaren avfyras när systemet märker tillståndsändringen, vilket är efter att appen börjat arbeta. Om appen aldrig får kommunicera utanför tunneln är en startutlösare ingen blockeringsregel och kan inte göras till en genom att lägga till en fördröjning. Konfigurera en stödd alltid-på- eller per-app-princip för blockeringsbeteendet, och behåll utlösaren bara för bekvämlighet.

Blockeringsbeteendet bor någon helt annanstans. adb shell settings get global always_on_vpn_app namnger paketet som är fäst som alltid-på, och adb shell dumpsys connectivity | grep -i vpn visar de VPN-nätverk som systemet följer just nu. Inget av dem är något som en startutlösare kan ersätta.

Samma resonemang gäller i andra änden av sessionen. Att ta ned tunneln för att ett fönster tappade fokus bryter bakgrundsarbete, autentiseringshjälpare och varje annan app som räknade med anslutningen. Definiera ett avsiktligt sessionsslut i stället för ett fokusbyte, och undvik snabba UP- och DOWN-sekvenser när automatiseringen byter kontext.

Kontrollera resultatet, inte sändningen

En sändning som kommer tillbaka utan fel har accepterats av Android och inget mer. Läs tunnelns tillstånd från appen, och läs arbetsflödets beredskap från vad nästa steg faktiskt behöver. Det är två olika kontroller, och att klara den första innebär inte den andra.

Läs också gränssnittets tillstånd direkt: adb shell ip -brief addr show tun0 skriver ut tunnelgränssnittet och dess adress, och ett gränssnitt som finns utan adress är uppe utan att vara användbart. Bekräfta sedan själva den privata tjänsten, eftersom en tunnel som är uppe utan handskakning eller utan rutt fortfarande misslyckas i uppgiften som betydde något. En automatisering som styr en namngiven anslutning inom sin verkliga behörighetsgräns behöver inte trycka på gränssnittet, köra ett root-kommando eller försvaga Androids nätverksskydd.