Tasker e WireGuard: inviare l’Intent giusto per un tunnel

Avviare l’attività di WireGuard porta un’app in primo piano, non alza un tunnel specifico. Un’automazione che apre l’app e aspetta passerà in prova e fallirà la prima volta che il telefono è già sulla schermata iniziale. WireGuard espone un percorso di controllo remoto supportato per i tunnel con nome, ed è più stretto di quanto suggeriscano la maggior parte delle ricette. La lista di controllo qui sotto percorre quel percorso dal permesso al risultato osservato.

Verificare che il controllo remoto sia attivo

Il ricevitore di controllo remoto non è sempre in ascolto. Le impostazioni di WireGuard includono un’opzione che abilita il controllo remoto dei tunnel, e finché quell’opzione è spenta il ricevitore ignora le richieste invece di fallire rumorosamente. Il valore predefinito è voluto, perché un ricevitore esportato che potesse alzare tunnel sarebbe un buco di sicurezza su ogni dispositivo che ha installato l’app. Attivala dall’interfaccia e annota di averlo fatto, perché è un’impostazione che un utente futuro può disattivare senza sapere da cosa dipendeva.

Il ricevitore qui sopra gestisce solo richieste UP e DOWN con nome, quindi qui non c’è alcun percorso per creare un tunnel o modificarne la configurazione. Conferma che il componente esista nella build installata prima di farci affidamento: adb shell dumpsys package com.wireguard.android | grep -i receiver elenca i ricevitori dichiarati, e una build senza il ricevitore di controllo remoto non risponderà mai. Se il flusso di lavoro richiede un altro endpoint o un altro peer, quello è un altro tunnel e una configurazione manuale separata dentro l’app.

Verificare il permesso che ha il controllore

WireGuard protegge il ricevitore con un permesso pericoloso, com.wireguard.android.permission.CONTROL_TUNNELS, che l’app controllante deve possedere. Un broadcast personalizzato non può fabbricare un permesso che il mittente non ha mai dichiarato o che non gli è mai stato concesso. Questo è il passo in cui le ricette di automazione danno per scontata in silenzio una capacità che l’automazione non ha.

Verifica entrambi i lati prima di scrivere l’attività. Il primo comando elenca il permesso dichiarato, e il secondo mostra se il pacchetto del controllore lo possiede davvero. Un controllore che dichiara il permesso nel manifest ma non l’ha mai ricevuto a runtime fallisce comunque, e il fallimento arriva come silenzio invece che come finestra di dialogo.

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

Se il controllore non ha il permesso, usa l’integrazione che l’app supporta davvero invece di costruire un broadcast a mano. Inviare un Intent e vedere che la chiamata è riuscita dimostra solo che Android l’ha accettato, non che WireGuard abbia agito di conseguenza. Tratta un invio non verificato come un’incognita, non come un successo.

Verificare i campi dell’Intent rispetto all’app installata

Quattro campi portano tutta la richiesta, e ognuno ha un modo di fallire che sembra esattamente uguale agli altri. Indovina l’azione, l’extra del tunnel, il pacchetto e il bersaglio come un insieme.

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

L’azione nomina UP o DOWN e nient’altro, l’extra porta il nome esatto del tunnel configurato, il pacchetto limita la consegna a WireGuard, e il bersaglio deve essere il ricevitore e non un’attività. Un nome di tunnel con un errore di battitura produce lo stesso silenzio di un ricevitore disabilitato, quindi leggi il nome nell’app prima di concludere che l’automazione è rotta. L’azione DOWN è com.wireguard.android.action.SET_TUNNEL_DOWN con lo stesso extra e lo stesso pacchetto. Invia una richiesta alla volta durante i test, perché due broadcast che si inseguono producono uno stato che nessuno può attribuire.

Prova la stessa richiesta da una shell sul dispositivo per separare l’Intent dall’automazione. Se quel comando fallisce mentre il task di Tasker riesce, la differenza è il permesso del mittente e non i valori dei campi.

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

Verificare cosa non copre il trigger

Un evento di avvio o di primo piano può chiedere una connessione, ma l’app potrebbe aver già tentato una risoluzione del nome o una richiesta iniziale prima che quell’evento sia gestito. Il trigger scatta quando il sistema nota il cambio di stato, cioè dopo che l’app ha iniziato a lavorare. Se l’app non deve mai comunicare fuori dal tunnel, un trigger di avvio non è una regola di blocco e non può diventarlo aggiungendo un ritardo. Configura una politica supportata di sempre attivo o per app per il comportamento di blocco, e tieni il trigger solo per comodità.

Il comportamento di blocco vive altrove, del tutto. adb shell settings get global always_on_vpn_app nomina il pacchetto fissato come sempre attivo, e adb shell dumpsys connectivity | grep -i vpn mostra le reti VPN che il sistema sta seguendo in questo momento. Nessuna delle due è qualcosa che un trigger di avvio possa sostituire.

Lo stesso ragionamento vale all’altro capo della sessione. Abbassare il tunnel perché una finestra ha perso il focus rompe il lavoro in background, gli helper di autenticazione e ogni altra app che contava sulla connessione. Definisci una fine di sessione deliberata invece di un cambio di focus, ed evita sequenze rapide di UP e DOWN quando l’automazione cambia contesto.

Verificare il risultato, non l’invio

Un broadcast che torna senza errore è stato accettato da Android e nulla più. Leggi lo stato del tunnel dall’app, e leggi la prontezza del flusso di lavoro da ciò che il passo successivo richiede davvero. Sono due controlli diversi, e superare il primo non implica il secondo.

Leggi anche lo stato dell’interfaccia direttamente: adb shell ip -brief addr show tun0 stampa l’interfaccia del tunnel e il suo indirizzo, e un’interfaccia che esiste senza indirizzo è alzata senza essere utilizzabile. Poi verifica il servizio privato stesso, perché un tunnel alzato senza handshake o senza rotta fallisce ancora il compito che contava. Un’automazione che controlla una connessione con nome entro i limiti reali del suo permesso non ha bisogno di toccare l’interfaccia, eseguire un comando root né indebolire le protezioni di rete di Android.