Tasker e WireGuard: enviar o Intent correcto para un túnel

Iniciar a actividade de WireGuard trae unha aplicación á fronte, non levanta un túnel concreto. Unha automatización que abre a aplicación e espera pasará na proba e fallará a primeira vez que o teléfono xa estea na pantalla de inicio. WireGuard expón unha ruta de control remoto compatible para túneles con nome, e é máis estreita do que suxiren a maioría das receitas. A lista de comprobación de abaixo percorre esa ruta desde o permiso ata o resultado observado.

Comprobar que o control remoto está activado

O receptor de control remoto non sempre está escoitando. Os axustes de WireGuard inclúen unha opción que activa o control remoto de túneles, e mentres esa opción estea desactivada o receptor ignora as peticións en lugar de fallar ruidosamente. O valor por defecto é deliberado, porque un receptor exportado que puidese levantar túneles sería un burato de seguridade en cada dispositivo que instalase a aplicación. Actívao desde a interface e anota que o fixeches, porque é un axuste que un usuario futuro pode desactivar sen saber do que dependía.

O receptor de arriba só atende peticións UP e DOWN con nome, así que aquí non hai ruta para crear un túnel nin para editar a súa configuración. Confirma que o compoñente existe na compilación instalada antes de confiar nel: adb shell dumpsys package com.wireguard.android | grep -i receiver lista os receptores declarados, e unha compilación sen o receptor de control remoto nunca responderá. Se o fluxo de traballo necesita outro punto final ou outro par, iso é outro túnel e unha configuración manual aparte dentro da aplicación.

Comprobar o permiso que ten o controlador

WireGuard protexe o receptor cun permiso perigoso, com.wireguard.android.permission.CONTROL_TUNNELS, que a aplicación controladora debe ter. Un broadcast propio non pode fabricar un permiso que o emisor nunca declarou ou que nunca se lle concedeu. Este é o paso no que as receitas de automatización asumen en silencio unha capacidade que a automatización non ten.

Comproba ambos os lados antes de escribir a tarefa. O primeiro comando lista o permiso declarado, e o segundo mostra se o paquete do controlador o ten realmente. Un controlador que declara o permiso no seu manifesto pero nunca o recibiu en tempo de execución segue fallando, e o fallo chega como silencio en lugar de como diálogo.

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

Se o controlador non ten o permiso, usa a integración que a aplicación si admite en lugar de construír un broadcast a man. Enviar un Intent e ver que a chamada foi ben só demostra que Android o aceptou, non que WireGuard actuase en consecuencia. Trata un envío sen verificar como un descoñecido, non como un éxito.

Comprobar os campos do Intent coa aplicación instalada

Catro campos levan toda a petición, e cada un ten un modo de fallo que se parece exactamente aos demais. Acerta a acción, o extra do túnel, o paquete e o obxectivo como un conxunto.

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

A acción nomea UP ou DOWN e nada máis, o extra leva o nome exacto do túnel configurado, o paquete restrinxe a entrega a WireGuard, e o obxectivo ten que ser o receptor e non unha actividade. Un nome de túnel cunha errata produce o mesmo silencio que un receptor desactivado, así que le o nome na aplicación antes de concluír que a automatización está rota. A acción DOWN é com.wireguard.android.action.SET_TUNNEL_DOWN co mesmo extra e o mesmo paquete. Envía unha petición cada vez mentres probas, porque dous broadcasts que se perseguen producen un estado que ninguén pode atribuír.

Proba a mesma petición desde un shell no dispositivo para separar o Intent da automatización. Se ese comando falla mentres a tarefa de Tasker funciona, a diferenza é o permiso do emisor e non os valores dos campos.

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

Comprobar o que non cobre o disparador

Un evento de inicio ou de primeiro plano pode pedir unha conexión, pero a aplicación pode ter tentado xa unha resolución de nome ou unha petición inicial antes de que se atenda ese evento. O disparador actívase cando o sistema nota o cambio de estado, que é despois de que a aplicación comezase a traballar. Se a aplicación non debe comunicarse nunca fóra do túnel, un disparador de inicio non é unha regra de bloqueo e non pode converterse nunha engadindo un atraso. Configura unha política compatible de sempre activo ou por aplicación para o comportamento de bloqueo, e reserva o disparador só para comodidade.

O comportamento de bloqueo vive noutro sitio por completo. adb shell settings get global always_on_vpn_app nomea o paquete fixado como sempre activo, e adb shell dumpsys connectivity | grep -i vpn mostra as redes VPN que o sistema segue agora mesmo. Ningunha das dúas é algo que un disparador de inicio poida substituír.

O mesmo razoamento aplícase no outro extremo da sesión. Baixar o túnel porque unha ventá perdeu o foco rompe o traballo en segundo plano, os asistentes de autenticación e calquera outra aplicación que contase coa conexión. Define un final de sesión deliberado en lugar dun cambio de foco, e evita secuencias rápidas de UP e DOWN cando a automatización cambia de contexto.

Comprobar o resultado, non o envío

Un broadcast que volve sen erro foi aceptado por Android e nada máis. Le o estado do túnel na aplicación, e le a preparación do fluxo de traballo no que o seguinte paso necesita de verdade. Son dúas comprobacións distintas, e pasar a primeira non implica a segunda.

Le tamén o estado da interface directamente: adb shell ip -brief addr show tun0 imprime a interface do túnel e o seu enderezo, e unha interface que existe sen enderezo está levantada sen ser utilizábel. Despois verifica o servizo privado en si, porque un túnel levantado sen handshake ou sen ruta segue fallando na tarefa que importaba. Unha automatización que controla unha conexión con nome dentro dos seus límites reais de permiso non necesita tocar a interface, executar un comando root nin debilitar as proteccións de rede de Android.