OpenVPN Connect y Tasker: el ID del perfil, no el nombre

Una automatización que se conectaba sin fallos durante meses deja de funcionar tras una actualización del cliente, mientras el mismo perfil sigue conectando a mano. Ese patrón apunta al contrato de control y no al servidor VPN. Alguien cambió qué acción acepta la aplicación, o qué identificador espera, y la tarea sigue enviando el anterior. Reconstruir el vínculo lleva menos tiempo que volver a revisar el servidor.

El contrato pertenece a una aplicación y a un rango de versiones

OpenVPN Connect y OpenVPN for Android son aplicaciones distintas, y un intent que nombra un paquete no hace nada en la otra. Antes de tocar la tarea, confirma qué cliente está instalado y qué versión produjo el comportamiento con el que comparas. Para Connect en Android 3.3.2 o posterior, la integración documentada con Tasker espera un ID de perfil. Las instrucciones antiguas que anteponen AS o PC a un nombre visible describen un contrato anterior, y copiarlas en una tarea actual es la razón habitual de que no ocurra nada.

Ese límite de versión explica la mayoría de los informes de que antes funcionaba. La aplicación no rompió la función; cambió lo que la función acepta. Trata el rango de versiones como parte del contrato contra el que escribes.

De dónde sale el identificador

Abre el perfil deseado dentro de Connect y copia su Profile ID desde los detalles del propio perfil. Usa ese valor en lugar de un nombre que reconozcas de la lista, porque el nombre es una etiqueta y el identificador es lo que la aplicación compara. Los campos de conexión de la acción Send Intent de Tasker se parecen al bloque de abajo, con solo el identificador sustituido. Mantén también coherente la instancia de la aplicación personal o de perfil de trabajo.

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

Una copia en el perfil de trabajo con el mismo nombre de paquete y otro perfil guardado aceptará el intent y no encontrará ningún perfil coincidente, lo que parece una tarea rota y no un error de ámbito. Si el perfil se reimporta o se sustituye, considera el identificador sospechoso y vuelve a comprobarlo. Reimportar suele crear una entrada de perfil nueva aunque el nombre visible no cambie. Comprueba el identificador antes de cambiar cualquier otra cosa.

Deja vacíos los campos no relacionados tal como indica la documentación. Los campos de categoría, tipo MIME y datos que la guía no pide pueden cambiar cómo resuelve Android el intent, y un intent que se resuelve de otra forma puede abrir la aplicación sin iniciar tu perfil.

Qué hace la acción y qué te deja a ti

Enviar el intent de conexión pide a la aplicación que inicie un perfil. No omite la autorización que ese perfil requiera. Connect puede seguir mostrando un aviso, y por eso el caso autónomo documentado supone que no hay autorización adicional ni credenciales de conectividad guardadas. La tentación es eliminar ese límite incrustando contraseñas o secretos de clave privada en una exportación de Tasker compartida.

No lo hagas. Una exportación de tarea es un archivo de texto que la gente copia en hilos de chat, y los secretos que se colocan ahí quedan expuestos en el momento en que se comparte. Usa las credenciales de conectividad guardadas de la propia aplicación si el perfil las necesita, y deja que los avisos de MFA sigan siendo avisos. Cualquier cosa que evite el aviso guardando la respuesta ha movido el secreto en lugar de resolver el problema.

El lado de la desconexión tiene su propia acción documentada, y no es un truco contra el 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 una desconexión es el tipo de rodeo que aparece en hilos antiguos y luego falla en silencio tras una actualización. Usa la acción explícita.

Comprueba el estado antes de que se ejecute el paso siguiente

Un lanzamiento correcto del intent demuestra que la petición se entregó, no que exista un túnel. Si la tarea abre después una aplicación interna,ese paso necesita una condición de preparación con un tiempo de espera acotado. Una acción inmediata tras el 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

La consulta resolve confirma que el paquete y la actividad a los que apuntas existen en ese dispositivo, lo que descarta una errata en el campo de clase. El volcado de actividad muestra qué hay realmente en primer plano después de que se ejecute tu tarea, y es la forma más barata de ver si la aplicación abrió un aviso en lugar de conectarse. Ejecuta ambas cosas después de una tarea fallida en lugar de adivinar qué campo está mal. Un desajuste en el nombre de la clase produce un error inmediato, mientras que un perfil ausente no produce ningún error visible.

Decide la propiedad de la desconexión antes de publicar la tarea. Un atajo que derriba un túnel del que depende otra tarea de trabajo generará un ticket de soporte que no se parece en nada a su causa. Mantener dos automatizaciones que controlan el mismo cliente produce una carrera que no puedes depurar desde los registros, así que borra la acción obsoleta cuando la nueva funcione.