Tasker et WireGuard : envoyer le bon Intent pour un tunnel

Lancer l’activité WireGuard amène une application au premier plan, pas un tunnel précis en haut. Une automatisation qui ouvre l’application et attend passera en test et échouera la première fois que le téléphone est déjà sur l’écran d’accueil. WireGuard expose un chemin de contrôle à distance pris en charge pour les tunnels nommés, et il est plus étroit que ne le suggèrent la plupart des recettes. La liste de vérification ci-dessous parcourt ce chemin de l’autorisation au résultat observé.

Vérifier que le contrôle à distance est activé

Le récepteur de contrôle à distance n’écoute pas toujours. Les réglages de WireGuard comportent une option qui active le contrôle à distance des tunnels, et tant qu’elle n’est pas activée, le récepteur ignore les demandes au lieu d’échouer bruyamment. La valeur par défaut est délibérée, car un récepteur exporté capable de monter des tunnels serait une faille de sécurité sur chaque appareil ayant installé l’application. Activez-la via l’interface et notez que vous l’avez fait, car c’est un réglage qu’un utilisateur futur peut désactiver sans savoir ce qui en dépendait.

Le récepteur ci-dessus ne traite que les demandes UP et DOWN nommées, il n’y a donc ici aucun chemin pour créer un tunnel ni modifier sa configuration. Confirmez que le composant existe dans la version installée avant de vous y fier : adb shell dumpsys package com.wireguard.android | grep -i receiver liste les récepteurs déclarés, et une version sans le récepteur de contrôle à distance ne répondra jamais. Si le flux de travail a besoin d’un autre point de terminaison ou d’un autre pair, c’est un autre tunnel et une configuration manuelle distincte dans l’application.

Vérifier l’autorisation dont dispose le contrôleur

WireGuard protège le récepteur par une autorisation dangereuse, com.wireguard.android.permission.CONTROL_TUNNELS, que l’application contrôleuse doit détenir. Un broadcast personnalisé ne peut pas fabriquer une autorisation que l’émetteur n’a jamais déclarée ou qui ne lui a jamais été accordée. C’est l’étape où les recettes d’automatisation supposent silencieusement une capacité que l’automatisation n’a pas.

Vérifiez les deux côtés avant d’écrire la tâche. La première commande liste l’autorisation déclarée, et la seconde montre si le paquet du contrôleur la détient réellement. Un contrôleur qui déclare l’autorisation dans son manifeste mais à qui elle n’a jamais été accordée à l’exécution échoue quand même, et l’échec arrive sous forme de silence plutôt que de boîte de dialogue.

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

Si le contrôleur ne détient pas l’autorisation, utilisez l’intégration que l’application prend réellement en charge au lieu de construire un broadcast à la main. Envoyer un Intent et constater que l’appel a réussi prouve seulement qu’Android l’a accepté, pas que WireGuard y a réagi. Traitez un envoi non vérifié comme une inconnue, pas comme un succès.

Vérifier les champs de l’Intent face à l’application installée

Quatre champs portent toute la demande, et chacun a un mode d’échec qui ressemble exactement aux autres. Réglez correctement l’action, l’extra de tunnel, le paquet et la cible comme un ensemble.

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

L’action nomme UP ou DOWN et rien d’autre, l’extra porte le nom exact du tunnel configuré, le paquet restreint la livraison à WireGuard, et la cible doit être le récepteur et non une activité. Un nom de tunnel avec une faute de frappe produit le même silence qu’un récepteur désactivé, alors lisez le nom dans l’application avant de conclure que l’automatisation est cassée. L’action DOWN est com.wireguard.android.action.SET_TUNNEL_DOWN avec le même extra et le même paquet. Envoyez une demande à la fois pendant les tests, car deux broadcasts qui se poursuivent produisent un état que personne ne peut attribuer.

Testez la même demande depuis un shell sur l’appareil pour séparer l’Intent de l’automatisation. Si cette commande échoue alors que la tâche Tasker réussit, la différence est l’autorisation de l’émetteur et non les valeurs des champs.

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

Vérifier ce que le déclencheur ne couvre pas

Un événement de lancement ou de premier plan peut demander une connexion, mais l’application a peut-être déjà tenté une résolution de nom ou une demande initiale avant que cet événement soit traité. Le déclencheur se déclenche quand le système remarque le changement d’état, c’est-à-dire après que l’application a commencé à travailler. Si l’application ne doit jamais communiquer hors du tunnel, un déclencheur de lancement n’est pas une règle de blocage et ne peut pas le devenir en ajoutant un délai. Configurez une politique prise en charge de toujours actif ou par application pour le comportement de blocage, et gardez le déclencheur pour le seul confort.

Le comportement de blocage vit ailleurs, entièrement. adb shell settings get global always_on_vpn_app nomme le paquet épinglé comme toujours actif, et adb shell dumpsys connectivity | grep -i vpn montre les réseaux VPN que le système suit actuellement. Aucun des deux n’est quelque chose qu’un déclencheur de lancement puisse remplacer.

Le même raisonnement s’applique à l’autre bout de la session. Faire tomber le tunnel parce qu’une fenêtre a perdu le focus casse le travail en arrière-plan, les assistants d’authentification et toute autre application qui comptait sur la connexion. Définissez une fin de session délibérée plutôt qu’un changement de focus, et évitez les séquences rapides d’UP et de DOWN quand l’automatisation change de contexte.

Vérifier le résultat, pas l’envoi

Un broadcast qui revient sans erreur a été accepté par Android et rien de plus. Lisez l’état du tunnel dans l’application, et lisez la disponibilité du flux de travail dans ce dont l’étape suivante a réellement besoin. Ce sont deux vérifications différentes, et réussir la première n’implique pas la seconde.

Lisez aussi l’état de l’interface directement : adb shell ip -brief addr show tun0 affiche l’interface du tunnel et son adresse, et une interface qui existe sans adresse est montée sans être utilisable. Vérifiez ensuite le service privé lui-même, car un tunnel monté sans handshake ou sans route échoue encore à la tâche qui comptait. Une automatisation qui contrôle une connexion nommée dans les limites réelles de son autorisation n’a pas besoin de toucher l’interface, d’exécuter une commande root ni d’affaiblir les protections réseau d’Android.