Tasker e WireGuard: enviar o Intent certo para um túnel

Iniciar a atividade do WireGuard traz uma aplicação para a frente, não levanta um túnel específico. Uma automatização que abre a aplicação e espera passa no teste e falha na primeira vez que o telemóvel já está no ecrã inicial. O WireGuard expõe um caminho de controlo remoto suportado para túneis com nome, e é mais estreito do que a maioria das receitas sugere. A lista de verificação abaixo percorre esse caminho desde a permissão até ao resultado observado.

Verificar se o controlo remoto está ativado

O recetor de controlo remoto nem sempre está à escuta. As definições do WireGuard incluem uma opção que ativa o controlo remoto de túneis, e enquanto essa opção estiver desligada o recetor ignora pedidos em vez de falhar ruidosamente. O valor predefinido é deliberado, porque um recetor exportado que pudesse levantar túneis seria um buraco de segurança em cada dispositivo que instalasse a aplicação. Ative-o pela interface e anote que o fez, porque é uma definição que um utilizador futuro pode desligar sem saber do que dependia.

O recetor acima só trata pedidos UP e DOWN com nome, por isso aqui não há caminho para criar um túnel nem para editar a sua configuração. Confirme que o componente existe na compilação instalada antes de contar com ele: adb shell dumpsys package com.wireguard.android | grep -i receiver lista os recetores declarados, e uma compilação sem o recetor de controlo remoto nunca responderá. Se o fluxo de trabalho precisar de outro ponto final ou de outro par, isso é outro túnel e uma configuração manual à parte dentro da aplicação.

Verificar a permissão que o controlador tem

O WireGuard protege o recetor com uma permissão perigosa, com.wireguard.android.permission.CONTROL_TUNNELS, que a aplicação controladora tem de possuir. Um broadcast próprio não pode fabricar uma permissão que o emissor nunca declarou ou que nunca lhe foi concedida. Este é o passo em que as receitas de automatização assumem em silêncio uma capacidade que a automatização não tem.

Verifique os dois lados antes de escrever a tarefa. O primeiro comando lista a permissão declarada, e o segundo mostra se o pacote do controlador a possui mesmo. Um controlador que declara a permissão no manifesto mas nunca a recebeu em tempo de execução continua a falhar, e a falha chega como silêncio em vez de como caixa de 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 não tiver a permissão, use a integração que a aplicação realmente suporta em vez de construir um broadcast à mão. Enviar um Intent e ver que a chamada foi bem-sucedida prova apenas que o Android o aceitou, não que o WireGuard tenha agido em conformidade. Trate um envio não verificado como desconhecido, não como sucesso.

Confrontar os campos do Intent com a aplicação instalada

Quatro campos transportam o pedido inteiro, e cada um tem um modo de falha que se parece exatamente com os outros. Acerte na ação, no extra do túnel, no pacote e no alvo como um conjunto.

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

A ação nomeia UP ou DOWN e nada mais, o extra leva o nome exato do túnel configurado, o pacote restringe a entrega ao WireGuard, e o alvo tem de ser o recetor e não uma atividade. Um nome de túnel com um erro ortográfico produz o mesmo silêncio que um recetor desativado, por isso leia o nome na aplicação antes de concluir que a automatização está avariada. A ação DOWN é com.wireguard.android.action.SET_TUNNEL_DOWN com o mesmo extra e o mesmo pacote. Envie um pedido de cada vez durante os testes, porque dois broadcasts a perseguirem-se produzem um estado que ninguém consegue atribuir.

Teste o mesmo pedido a partir de uma shell no dispositivo para separar o Intent da automatização. Se esse comando falhar enquanto a tarefa do Tasker funciona, a diferença é a permissão do emissor e não 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

Verificar o que o acionador não cobre

Um evento de arranque ou de primeiro plano da aplicação pode pedir uma ligação, mas a aplicação pode já ter tentado uma resolução de nome ou um pedido inicial antes de esse evento ser tratado. O acionador dispara quando o sistema nota a mudança de estado, ou seja, depois de a aplicação ter começado a trabalhar. Se a aplicação nunca deve comunicar fora do túnel, um acionador de arranque não é uma regra de bloqueio e não pode tornar-se numa adicionando um atraso. Configure uma política suportada de sempre ativo ou por aplicação para o comportamento de bloqueio, e guarde o acionador apenas para conveniência.

O comportamento de bloqueio vive noutro sítio por completo. adb shell settings get global always_on_vpn_app nomeia o pacote fixado como sempre ativo, e adb shell dumpsys connectivity | grep -i vpn mostra as redes VPN que o sistema segue neste momento. Nenhum dos dois é algo que um acionador de arranque possa substituir.

O mesmo raciocínio aplica-se no outro extremo da sessão. Baixar o túnel porque uma janela perdeu o foco quebra o trabalho em segundo plano, os assistentes de autenticação e qualquer outra aplicação que contasse com a ligação. Defina um fim de sessão deliberado em vez de uma mudança de foco, e evite sequências rápidas de UP e DOWN quando a automatização muda de contexto.

Verificar o resultado, não o envio

Um broadcast que regressa sem erro foi aceite pelo Android e nada mais. Leia o estado do túnel na aplicação, e leia a prontidão do fluxo de trabalho naquilo de que o passo seguinte precisa de facto. São duas verificações diferentes, e passar a primeira não implica a segunda.

Leia também o estado da interface diretamente: adb shell ip -brief addr show tun0 imprime a interface do túnel e o seu endereço, e uma interface que existe sem endereço está levantada sem ser utilizável. Depois verifique o próprio serviço privado, porque um túnel levantado sem handshake ou sem rota continua a falhar na tarefa que importava. Uma automatização que controla uma ligação com nome dentro dos limites reais da sua permissão não precisa de tocar na interface, executar um comando root nem enfraquecer as proteções de rede do Android.