Tasker i WireGuard: com enviar l’Intent correcte per a un túnel

Iniciar l’activitat de WireGuard porta una aplicació al davant, no aixeca un túnel concret. Una automatització que obre l’aplicació i espera passarà a les proves i fallarà el primer cop que el telèfon ja sigui a la pantalla d’inici. WireGuard exposa un camí de control remot compatible per a túnels amb nom, i és més estret del que suggereixen la majoria de receptes. La llista de comprovació de sota recorre aquest camí des del permís fins al resultat observat.

Comprovar que el control remot està activat

El receptor de control remot no sempre està escoltant. La configuració de WireGuard inclou una opció que activa el control remot dels túnels, i mentre aquesta opció no estigui activada el receptor ignora les peticions en lloc de fallar sorollosament. El valor per defecte és deliberat, perquè un receptor exportat que pogués aixecar túnels seria una escletxa de seguretat a cada dispositiu que hagués instal·lat l’aplicació. Activeu-lo des de la interfície i anoteu que ho heu fet, perquè és un paràmetre que un usuari futur pot desactivar sense saber què en depenia.

El receptor d’origen només gestiona peticions UP i DOWN amb nom, així que aquí no hi ha cap camí per crear un túnel ni per editar-ne la configuració. Confirmeu que el component existeix a la compilació instal·lada abans de confiar-hi: adb shell dumpsys package com.wireguard.android | grep -i receiver llista els receptors declarats, i una compilació sense el receptor de control remot no respondrà mai. Si el flux de treball necessita un altre punt final o un altre parell, això és un altre túnel i una configuració manual a part dins de l’aplicació.

Comprovar el permís que té el controlador

WireGuard protegeix el receptor amb un permís perillós, com.wireguard.android.permission.CONTROL_TUNNELS, que l’aplicació controladora ha de tenir. Un broadcast propi no pot fabricar un permís que l’emissor no ha declarat mai o que no se li ha concedit mai. Aquest és el pas on les receptes d’automatització assumeixen en silenci una capacitat que l’automatització no té.

Comproveu les dues bandes abans d’escriure la tasca. La primera ordre llista el permís declarat, i la segona mostra si el paquet del controlador el té realment. Un controlador que declara el permís al seu manifest però que mai el va rebre en temps d’execució també falla, i el fracàs arriba com a silenci i no com a diàleg.

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

Si el controlador no té el permís, feu servir la integració que l’aplicació suporta de debò en lloc de construir un broadcast a mà. Enviar un Intent i veure que la crida ha anat bé només demostra que Android l’ha acceptat, no que WireGuard hi hagi actuat. Tracteu un enviament no verificat com un desconegut, no com un èxit.

Comprovar els camps de l’Intent amb l’aplicació instal·lada

Quatre camps porten tota la petició, i cadascun té una manera de fallar que sembla exactament igual que les altres. Encerta l’acció, l’extra del túnel, el paquet i l’objectiu com un conjunt.

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

L’acció nomena UP o DOWN i res més, l’extra porta el nom exacte del túnel configurat, el paquet restringeix el lliurament a WireGuard, i l’objectiu ha de ser el receptor i no una activitat. Un nom de túnel amb una errata produeix el mateix silenci que un receptor desactivat, així que llegiu el nom a l’aplicació abans de concloure que l’automatització està trencada. L’acció DOWN és com.wireguard.android.action.SET_TUNNEL_DOWN amb el mateix extra i el mateix paquet. Envieu una petició cada vegada mentre proveu, perquè dos broadcasts que es persegueixen produeixen un estat que ningú no pot atribuir.

Proveu la mateixa petició des d’un shell al dispositiu per separar l’Intent de l’automatització. Si aquesta ordre falla mentre la tasca de Tasker funciona, la diferència és el permís de l’emissor i no els valors dels camps.

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

Comprovar què no cobreix el desencadenant

Un esdeveniment d’inici o de primer pla pot demanar una connexió, però l’aplicació pot haver intentat ja una resolució de nom o una petició inicial abans que es gestioni aquest esdeveniment. El desencadenant s’activa quan el sistema nota el canvi d’estat, que és després que l’aplicació hagi començat a treballar. Si l’aplicació no ha de comunicar-se mai fora del túnel, un desencadenant d’inici no és una regla de bloqueig i no es pot convertir en una afegint un retard. Configureu una política compatible d’activació permanent o per aplicació per al comportament de bloqueig, i reserveu el desencadenant només per comoditat.

El comportament de bloqueig viu en un altre lloc completament. adb shell settings get global always_on_vpn_app anomena el paquet fixat com a permanent, i adb shell dumpsys connectivity | grep -i vpn mostra les xarxes VPN que el sistema segueix ara mateix. Cap de les dues coses no és una cosa que un desencadenant d’inici pugui substituir.

El mateix raonament s’aplica a l’altre extrem de la sessió. Baixar el túnel perquè una finestra ha perdut el focus trenca la feina en segon pla, els assistents d’autenticació i qualsevol altra aplicació que compta amb la connexió. Definiu un final de sessió deliberat en lloc d’un canvi de focus, i eviteu seqüències ràpides d’UP i DOWN quan l’automatització canvia de context.

Comprovar el resultat, no l’enviament

Un broadcast que torna sense error ha estat acceptat per Android i res més. Llegiu l’estat del túnel a l’aplicació, i llegiu la preparació del flux de treball en el que el pas següent necessita de debò. Són dues comprovacions diferents, i passar la primera no implica la segona.

Llegiu també l’estat de la interfície directament: adb shell ip -brief addr show tun0 imprimeix la interfície del túnel i la seva adreça, i una interfície que existeix sense adreça està aixecada sense ser utilitzable. Després verifiqueu el servei privat mateix, perquè un túnel aixecat sense handshake o sense ruta encara falla la tasca que importava. Una automatització que controla una connexió amb nom dins dels seus límits reals de permís no necessita tocar la interfície, executar una ordre root ni debilitar les proteccions de xarxa d’Android.