Tasker en WireGuard: de juiste Intent voor één tunnel

De WireGuard-activiteit starten brengt een app naar de voorgrond, niet een bepaalde tunnel omhoog. Een automatisering die de app opent en wacht, slaagt in de test en faalt de eerste keer dat de telefoon al op het startscherm staat. WireGuard biedt een ondersteund pad voor afstandsbediening van benoemde tunnels, en dat is smaller dan de meeste recepten suggereren. De checklist hieronder loopt dat pad van machtiging tot waargenomen resultaat.

Controleer of afstandsbediening is ingeschakeld

De ontvanger voor afstandsbediening luistert niet altijd. De instellingen van WireGuard bevatten een optie die afstandsbediening van tunnels inschakelt, en zolang die optie uit staat negeert de ontvanger verzoeken in plaats van luid te falen. De standaardwaarde is bewust, omdat een geëxporteerde ontvanger die tunnels kon opzetten een beveiligingslek zou zijn op elk apparaat waarop de app is geïnstalleerd. Schakel hem in via de interface en schrijf op dat je dat hebt gedaan, want het is een instelling die een toekomstige gebruiker kan uitzetten zonder te weten wat ervan afhing.

De ontvanger hierboven verwerkt alleen benoemde UP- en DOWN-verzoeken, dus er is hier geen pad om een tunnel aan te maken of de configuratie ervan te bewerken. Bevestig dat de component in de geïnstalleerde build bestaat voordat je erop vertrouwt: adb shell dumpsys package com.wireguard.android | grep -i receiver vermeldt de gedeclareerde ontvangers, en een build zonder de ontvanger voor afstandsbediening antwoordt nooit. Als de workflow een ander eindpunt of een andere peer nodig heeft, is dat een andere tunnel en een aparte handmatige configuratie in de app.

Controleer welke machtiging de controller heeft

WireGuard beschermt de ontvanger met een gevaarlijke machtiging, com.wireguard.android.permission.CONTROL_TUNNELS, die de aansturende app moet hebben. Een eigen broadcast kan geen machtiging maken die de afzender nooit heeft gedeclareerd of nooit heeft gekregen. Dit is de stap waar automatiseringsrecepten stilzwijgend een vermogen aannemen dat de automatisering niet heeft.

Controleer beide kanten voordat je de taak schrijft. De eerste opdracht vermeldt de gedeclareerde machtiging, en de tweede laat zien of het pakket van de controller die echt heeft. Een controller die de machtiging in zijn manifest declareert maar die nooit kreeg tijdens runtime, faalt alsnog, en de fout komt als stilte in plaats van als dialoog.

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

Als de controller de machtiging niet heeft, gebruik dan de integratie die de app echt ondersteunt in plaats van een broadcast met de hand te bouwen. Een Intent sturen en zien dat de aanroep is gelukt bewijst alleen dat Android hem heeft geaccepteerd, niet dat WireGuard erop heeft gehandeld. Behandel een niet-geverifieerde verzending als onbekend, niet als succes.

Controleer de Intent-velden tegen de geïnstalleerde app

Vier velden dragen het hele verzoek, en elk heeft een faalwijze die er precies zo uitziet als de andere. Zet de actie, de tunnel-extra, het pakket en het doel als één set goed.

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

De actie noemt UP of DOWN en niets anders, de extra draagt de exacte geconfigureerde tunnelnaam, het pakket beperkt de aflevering tot WireGuard, en het doel moet de ontvanger zijn en niet een activiteit. Een tunnelnaam met een typefout levert dezelfde stilte op als een uitgeschakelde ontvanger, dus lees de naam in de app voordat je concludeert dat de automatisering kapot is. De DOWN-actie is com.wireguard.android.action.SET_TUNNEL_DOWN met dezelfde extra en hetzelfde pakket. Stuur tijdens het testen één verzoek tegelijk, want twee broadcasts die elkaar inhalen leveren een toestand op die niemand kan toeschrijven.

Test hetzelfde verzoek vanuit een shell op het apparaat om de Intent van de automatisering te scheiden. Als die opdracht faalt terwijl de Tasker-taak slaagt, is het verschil de machtiging van de afzender en niet de veldwaarden.

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

Controleer wat de trigger niet dekt

Een gebeurtenis bij het starten of naar de voorgrond komen van een app kan een verbinding aanvragen, maar de app heeft misschien al een naamopzoeking of een eerste verzoek geprobeerd voordat die gebeurtenis wordt afgehandeld. De trigger vuurt wanneer het systeem de toestandswijziging opmerkt, dat is nadat de app is begonnen met werken. Als de app nooit buiten de tunnel mag communiceren, is een starttrigger geen blokkeerregel en kan die dat niet worden door een vertraging toe te voegen. Configureer een ondersteund altijd-aan- of per-app-beleid voor het blokkeergedrag, en houd de trigger alleen voor het gemak.

Het blokkeergedrag woont heel ergens anders. adb shell settings get global always_on_vpn_app noemt het pakket dat als altijd-aan is vastgezet, en adb shell dumpsys connectivity | grep -i vpn toont de VPN-netwerken die het systeem nu volgt. Geen van beide is iets wat een starttrigger kan vervangen.

Dezelfde redenering geldt aan de andere kant van de sessie. De tunnel laten zakken omdat één venster de focus verloor, breekt achtergrondwerk, authenticatiehulpen en elke andere app die op de verbinding rekende. Definieer een bewust einde van de sessie in plaats van een focuswissel, en vermijd snelle UP- en DOWN-reeksen wanneer de automatisering van context wisselt.

Controleer het resultaat, niet het verzenden

Een broadcast die zonder fout terugkomt, is door Android geaccepteerd en niets meer. Lees de tunneltoestand uit de app, en lees de gereedheid van de workflow uit wat de volgende stap echt nodig heeft. Dat zijn twee verschillende controles, en de eerste halen betekent niet de tweede.

Lees ook de toestand van de interface direct: adb shell ip -brief addr show tun0 drukt de tunnelinterface en het adres af, en een interface die zonder adres bestaat is omhoog zonder bruikbaar te zijn. Controleer daarna de privédienst zelf, want een tunnel die omhoog is zonder handshake of zonder route faalt nog steeds op de taak die erop aankwam. Een automatisering die één benoemde verbinding binnen zijn echte machtigingsgrens bestuurt, hoeft de interface niet aan te tikken, geen root-opdracht uit te voeren of Androids netwerkbescherming te verzwakken.