Tasker y WireGuard: enviar el Intent correcto para un túnel

Lanzar la actividad de WireGuard trae una aplicación al frente, no levanta un túnel concreto. Una automatización que abre la aplicación y espera pasará en las pruebas y fallará la primera vez que el teléfono ya esté en la pantalla de inicio. WireGuard expone una ruta de control remoto compatible para túneles con nombre, y es más estrecha de lo que sugieren la mayoría de las recetas. La lista de comprobación de abajo recorre esa ruta desde el permiso hasta el resultado observado.

Comprobar que el control remoto está activado

El receptor de control remoto no siempre está escuchando. Los ajustes de WireGuard incluyen una opción que activa el control remoto de túneles, y mientras esa opción esté desactivada el receptor ignora las peticiones en lugar de fallar ruidosamente. El valor por defecto es deliberado, porque un receptor exportado que pudiera levantar túneles sería un agujero de seguridad en cada dispositivo que instalara la aplicación. Actívalo desde la interfaz y anota que lo has hecho, porque es un ajuste que un usuario futuro puede desactivar sin saber de qué dependía.

El receptor de arriba solo atiende peticiones UP y DOWN con nombre, así que aquí no hay ruta para crear un túnel ni para editar su configuración. Confirma que el componente existe en la compilación instalada antes de confiar en él: adb shell dumpsys package com.wireguard.android | grep -i receiver lista los receptores declarados, y una compilación sin el receptor de control remoto nunca responderá. Si el flujo de trabajo necesita otro punto final u otro par, eso es otro túnel y una configuración manual aparte dentro de la aplicación.

Comprobar el permiso que tiene el controlador

WireGuard protege el receptor con un permiso peligroso, com.wireguard.android.permission.CONTROL_TUNNELS, que la aplicación controladora debe tener. Un broadcast propio no puede fabricar un permiso que el emisor nunca declaró o que nunca se le concedió. Este es el paso en el que las recetas de automatización asumen en silencio una capacidad que la automatización no tiene.

Comprueba ambos lados antes de escribir la tarea. El primer comando lista el permiso declarado, y el segundo muestra si el paquete del controlador lo tiene realmente. Un controlador que declara el permiso en su manifiesto pero nunca lo recibió en tiempo de ejecución sigue fallando, y el fallo llega 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

Si el controlador no tiene el permiso, usa la integración que la aplicación sí admite en lugar de construir un broadcast a mano. Enviar un Intent y ver que la llamada ha ido bien solo demuestra que Android lo aceptó, no que WireGuard haya actuado en consecuencia. Trata un envío sin verificar como un desconocido, no como un éxito.

Comprobar los campos del Intent con la aplicación instalada

Cuatro campos llevan toda la petición, y cada uno tiene un modo de fallo que se parece exactamente a los demás. Acierta la acción, el extra del túnel, el paquete y el objetivo como un conjunto.

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

La acción nombra UP o DOWN y nada más, el extra lleva el nombre exacto del túnel configurado, el paquete restringe la entrega a WireGuard, y el objetivo tiene que ser el receptor y no una actividad. Un nombre de túnel con una errata produce el mismo silencio que un receptor desactivado, así que lee el nombre en la aplicación antes de concluir que la automatización está rota. La acción DOWN es com.wireguard.android.action.SET_TUNNEL_DOWN con el mismo extra y el mismo paquete. Envía una petición cada vez mientras pruebas, porque dos broadcasts que se persiguen producen un estado que nadie puede atribuir.

Prueba la misma petición desde un shell en el dispositivo para separar el Intent de la automatización. Si ese comando falla mientras la tarea de Tasker funciona, la diferencia es el permiso del emisor y no los valores de los 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 qué no cubre el desencadenante

Un evento de inicio o de primer plano puede pedir una conexión, pero la aplicación puede haber intentado ya una resolución de nombre o una petición inicial antes de que se atienda ese evento. El desencadenante se dispara cuando el sistema nota el cambio de estado, que es después de que la aplicación haya empezado a trabajar. Si la aplicación no debe comunicarse nunca fuera del túnel, un desencadenante de inicio no es una regla de bloqueo y no puede convertirse en una añadiendo un retardo. Configura una política compatible de siempre activo o por aplicación para el comportamiento de bloqueo, y reserva el desencadenante solo para comodidad.

El comportamiento de bloqueo vive en otro sitio por completo. adb shell settings get global always_on_vpn_app nombra el paquete fijado como siempre activo, y adb shell dumpsys connectivity | grep -i vpn muestra las redes VPN que el sistema sigue ahora mismo. Ninguna de las dos es algo que un desencadenante de inicio pueda sustituir.

El mismo razonamiento se aplica en el otro extremo de la sesión. Bajar el túnel porque una ventana ha perdido el foco rompe el trabajo en segundo plano, los asistentes de autenticación y cualquier otra aplicación que contara con la conexión. Define un final de sesión deliberado en lugar de un cambio de foco, y evita secuencias rápidas de UP y DOWN cuando la automatización cambia de contexto.

Comprobar el resultado, no el envío

Un broadcast que vuelve sin error ha sido aceptado por Android y nada más. Lee el estado del túnel en la aplicación, y lee la preparación del flujo de trabajo en lo que el siguiente paso necesita de verdad. Son dos comprobaciones distintas, y pasar la primera no implica la segunda.

Lee también el estado de la interfaz directamente: adb shell ip -brief addr show tun0 imprime la interfaz del túnel y su dirección, y una interfaz que existe sin dirección está levantada sin ser utilizable. Después verifica el servicio privado en sí, porque un túnel levantado sin handshake o sin ruta sigue fallando en la tarea que importaba. Una automatización que controla una conexión con nombre dentro de sus límites reales de permiso no necesita tocar la interfaz, ejecutar un comando root ni debilitar las protecciones de red de Android.