OpenVPN Connect e Tasker: o ID do perfil, non o nome

Unha automatización que se conectaba sen fallos durante meses deixa de funcionar tras unha actualización do cliente, mentres o mesmo perfil segue conectando a man. Ese patrón apunta ao contrato de control e non ao servidor VPN. Alguén cambiou que acción acepta a aplicación, ou que identificador espera, e a tarefa segue enviando o anterior. Reconstruír o vínculo leva menos tempo que volver revisar o servidor.

O contrato pertence a unha aplicación e a un rango de versións

OpenVPN Connect e OpenVPN for Android son aplicacións distintas, e un intent que nomea un paquete non fai nada na outra. Antes de tocar a tarefa, confirma que cliente está instalado e que versión produciu o comportamento co que comparas. Para Connect en Android 3.3.2 ou posterior, a integración documentada con Tasker espera un ID de perfil. As instrucións antigas que antepoñen AS ou PC a un nome visible describen un contrato anterior, e copialas nunha tarefa actual é a razón habitual de que non ocorra nada.

Ese límite de versión explica a maioría dos informes de que antes funcionaba. A aplicación non rompeu a función; cambiou o que a función acepta. Trata o rango de versións como parte do contrato contra o que escribes.

De onde sae o identificador

Abre o perfil desexado dentro de Connect e copia o seu Profile ID desde os detalles do propio perfil. Usa ese valor en lugar dun nome que recoñezas da lista, porque o nome é unha etiqueta e o identificador é o que a aplicación compara. Os campos de conexión da acción Send Intent de Tasker parecen o bloque de abaixo, con só o identificador substituído. Mantén tamén coherente a instancia da aplicación persoal ou de perfil de traballo.

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

Unha copia no perfil de traballo co mesmo nome de paquete e outro perfil gardado aceptará o intent e non atopará ningún perfil coincidente, o que parece unha tarefa rota e non un erro de ámbito. Se o perfil se reimporta ou se substitúe, considera o identificador sospeitoso e volve comprobalo. Reimportar adoita crear unha entrada de perfil nova aínda que o nome visible non cambie. Comproba o identificador antes de cambiar calquera outra cousa.

Deixa baleiros os campos non relacionados tal como indica a documentación. Os campos de categoría, tipo MIME e datos que a guía non pide poden cambiar como resolve Android o intent, e un intent que se resolve doutro xeito pode abrir a aplicación sen iniciar o teu perfil.

Que fai a acción e que che deixa a ti

Enviar o intent de conexión pide á aplicación que inicie un perfil. Non omite a autorización que ese perfil requira. Connect pode seguir mostrando un aviso, e por iso o caso autónomo documentado supón que non hai autorización adicional nin credenciais de conectividade gardadas. A tentación é eliminar ese límite incrustando contrasinais ou segredos de chave privada nunha exportación de Tasker compartida.

Non o fagas. Unha exportación de tarefa é un ficheiro de texto que a xente copia en fíos de chat, e os segredos que se colocan alí quedan expostos no momento en que se comparte. Usa as credenciais de conectividade gardadas da propia aplicación se o perfil as necesita, e deixa que os avisos de MFA sigan sendo avisos. Calquera cousa que evite o aviso gardando a resposta moveu o segredo en lugar de resolver o problema.

O lado da desconexión ten a súa propia acción documentada, e non é un truco contra o cliente:

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

Conectarse a un perfil deliberadamente inexistente para forzar unha desconexión é o tipo de rodeo que aparece en fíos antigos e logo falla en silencio tras unha actualización. Usa a acción explícita.

Comproba o estado antes de que se execute o paso seguinte

Un lanzamento correcto do intent demostra que a petición se entregou, non que exista un túnel. Se a tarefa abre despois unha aplicación interna,ese paso necesita unha condición de preparación cun tempo de espera acoutado. Unha acción inmediata tras o envío acabará disparándose contra un 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 paquete e a actividade aos que apuntas existen nese dispositivo, o que descarta unha errata no campo de clase. O volcado de actividade mostra que hai realmente en primeiro plano despois de que se execute a túa tarefa, e é a forma máis barata de ver se a aplicación abriu un aviso en lugar de conectarse. Executa ambas as cousas despois dunha tarefa fallida en lugar de adiviñar que campo está mal. Un desaxuste no nome da clase produce un erro inmediato, mentres que un perfil ausente non produce ningún erro visible.

Decide a propiedade da desconexión antes de publicar a tarefa. Un atallo que derruba un túnel do que depende outra tarefa de traballo xerará un ticket de soporte que non se parece en nada á súa causa. Manter dúas automatizacións que controlan o mesmo cliente produce unha carreira que non podes depurar desde os rexistros, así que borra a acción obsoleta cando a nova funcione.