OpenVPN Connect e Tasker: o ID do perfil, não o nome

Uma automação que se conectava de forma confiável durante meses para de funcionar depois de uma atualização do cliente, enquanto o mesmo perfil continua conectando manualmente. Esse padrão aponta para o contrato de controle, e não para o servidor VPN. Alguém mudou qual ação o aplicativo aceita, ou qual identificador ele espera, e a tarefa continua enviando o antigo. Reconstruir a ligação leva menos tempo do que verificar o servidor novamente.

O contrato pertence a um aplicativo e a uma faixa de versões

OpenVPN Connect e OpenVPN for Android são aplicativos diferentes, e um intent que nomeia um pacote não faz nada no outro. Antes de mexer na tarefa, confirme qual cliente está instalado e qual versão produziu o comportamento com o qual você compara. Para o Connect no Android 3.3.2 ou mais recente, a integração documentada com o Tasker espera um ID de perfil. Instruções antigas que colocam AS ou PC antes de um nome de exibição descrevem um contrato anterior, e copiá-las para uma tarefa atual é o motivo habitual de nada acontecer.

Esse limite de versão explica a maioria dos relatos de que antes funcionava. O aplicativo não quebrou o recurso; mudou o que o recurso aceita. Trate a faixa de versões como parte do contrato para o qual você escreve.

De onde vem o identificador

Abra o perfil desejado dentro do Connect e copie o Profile ID dos detalhes do próprio perfil. Use esse valor em vez de um nome que você reconhece da lista, porque o nome é um rótulo e o identificador é o que o aplicativo compara. Os campos de conexão da ação Send Intent do Tasker se parecem com o bloco abaixo, com apenas o identificador substituído. Mantenha também consistente a instância do aplicativo pessoal ou de perfil de trabalho.

Action: net.openvpn.openvpn.CONNECT
Extra: net.openvpn.openvpn.AUTOSTART_PROFILE_ID:'PROFILE_ID'
Extra: net.openvpn.openvpn.AUTOCONNECT:true
Package: net.openvpn.openvpn
Class: net.openvpn.unified.MainActivity
Target: Activity

Uma cópia no perfil de trabalho com o mesmo nome de pacote e outro perfil armazenado aceitará o intent e não encontrará nenhum perfil correspondente, o que parece uma tarefa quebrada e não um erro de escopo. Se o perfil for reimportado ou substituído, trate o identificador como suspeito e verifique-o novamente. Reimportar costuma produzir uma nova entrada de perfil mesmo quando o nome de exibição não muda. Verifique o identificador antes de mudar qualquer outra coisa.

Deixe vazios os campos não relacionados, como documentado. Os campos de categoria, tipo MIME e dados que o guia não pede podem mudar como o Android resolve o intent, e um intent que resolve de outra forma pode abrir o aplicativo sem iniciar o seu perfil.

O que a ação faz e o que deixa para você

Enviar o intent de conexão pede ao aplicativo que inicie um perfil. Isso não contorna a autorização que esse perfil exigir. O Connect ainda pode mostrar um aviso, e é por isso que o caso autônomo documentado pressupõe que não há autorização adicional nem credenciais de conectividade salvas. A tentação é remover esse limite incorporando senhas ou segredos de chave privada em uma exportação do Tasker compartilhada.

Não faça isso. Uma exportação de tarefa é um arquivo de texto que as pessoas copiam em conversas, e os segredos colocados ali ficam expostos no momento em que é compartilhado. Use as credenciais de conectividade salvas do próprio aplicativo se o perfil precisar delas, e deixe os avisos de MFA continuarem sendo avisos. Qualquer coisa que evite o aviso guardando a resposta apenas moveu o segredo em vez de resolver o problema.

O lado da desconexão tem sua própria ação documentada, e não é um truque aplicado ao cliente:

Action: net.openvpn.openvpn.DISCONNECT
Extra: net.openvpn.openvpn.STOP:true
Package: net.openvpn.openvpn
Class: net.openvpn.unified.MainActivity
Target: Activity

Conectar-se a um perfil deliberadamente inexistente para forçar uma desconexão é o tipo de contorno que aparece em tópicos antigos e depois falha em silêncio após uma atualização. Use a ação explícita.

Verifique o estado antes de o próximo passo ser executado

Um lançamento bem-sucedido do intent prova que a solicitação foi entregue, não que exista um túnel. Se a tarefa então abrir um aplicativo interno,esse passo precisa de uma condição de prontidão com um tempo limite definido. Uma ação imediata após o envio vai acabar disparando contra um aviso.

$ adb shell cmd package resolve-activity --brief net.openvpn.openvpn
net.openvpn.openvpn/net.openvpn.unified.MainActivity
$ adb shell dumpsys activity activities | grep -i openvpn

A consulta resolve confirma que o pacote e a atividade que você tem como alvo existem naquele dispositivo, o que descarta um erro de digitação no campo de classe. O dump de atividades mostra o que está realmente em primeiro plano depois que sua tarefa roda, e é a forma mais barata de ver se o aplicativo abriu um aviso em vez de conectar. Execute os dois depois de uma tarefa que falhou em vez de adivinhar qual campo está errado. Uma divergência no nome da classe produz um erro imediato, enquanto um perfil ausente não produz erro visível nenhum.

Decida a propriedade da desconexão antes de entregar a tarefa. Um atalho que derruba um túnel do qual outra tarefa de trabalho depende vai gerar um chamado de suporte que não se parece nada com a sua causa. Manter duas automações que controlam o mesmo cliente cria uma corrida que você não consegue depurar pelos logs, então apague a ação obsoleta assim que a nova funcionar.