OpenVPN Connect e Tasker: l’ID del profilo, non il nome

Un’automazione che si connetteva in modo affidabile per mesi smette di funzionare dopo un aggiornamento del client, mentre lo stesso profilo continua a connettersi a mano. Questo schema indica il contratto di controllo, non il server VPN. Qualcuno ha cambiato quale azione accetta l’app, o quale identificatore si aspetta, e l’attività continua a inviare quello vecchio. Ricostruire il collegamento richiede meno tempo che ricontrollare il server.

Il contratto appartiene a un’app e a un intervallo di versioni

OpenVPN Connect e OpenVPN for Android sono applicazioni diverse, e un intent che nomina un pacchetto non fa nulla nell’altra. Prima di toccare l’attività, verifica quale client è installato e quale versione ha prodotto il comportamento che stai confrontando. Per Connect su Android 3.3.2 o successivo, l’integrazione documentata con Tasker si aspetta un ID di profilo. Le istruzioni più vecchie che antepongono AS o PC a un nome visualizzato descrivono un contratto precedente, e copiarle in un’attività attuale è il motivo abituale per cui non succede nulla.

Questo confine di versione spiega la maggior parte delle segnalazioni «prima funzionava». L’app non ha rotto la funzione; ha cambiato ciò che la funzione accetta. Tratta l’intervallo di versioni come parte del contratto per cui scrivi.

Da dove viene l’identificatore

Apri il profilo desiderato dentro Connect e copia il suo Profile ID dai dettagli del profilo stesso. Usa quel valore invece di un nome che riconosci dall’elenco, perché il nome è un’etichetta e l’identificatore è ciò con cui l’app confronta. I campi di connessione dell’azione Send Intent di Tasker assomigliano al blocco qui sotto, con solo l’identificatore sostituito. Mantieni coerente anche l’istanza dell’app personale o del profilo di lavoro.

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 nel profilo di lavoro con lo stesso nome di pacchetto e un profilo salvato diverso accetterà l’intent e non troverà alcun profilo corrispondente, il che sembra un’attività rotta e non un errore di ambito. Se il profilo viene reimportato o sostituito, considera l’identificatore sospetto e controllalo di nuovo. Reimportare produce di solito una nuova voce di profilo anche quando il nome visualizzato non cambia. Controlla l’identificatore prima di cambiare qualsiasi altra cosa.

Lascia vuoti i campi non correlati come documentato. I campi categoria, tipo MIME e dati che la guida non richiede possono cambiare il modo in cui Android risolve l’intent, e un intent che si risolve diversamente può avviare l’app senza avviare il tuo profilo.

Che cosa fa l’azione e che cosa lascia a te

Inviare l’intent di connessione chiede all’app di avviare un profilo. Non aggira l’autorizzazione richiesta da quel profilo. Connect può comunque mostrare una richiesta, ed è per questo che il caso autonomo documentato presuppone nessuna autorizzazione ulteriore e nessuna credenziale di connettività salvata. La tentazione è rimuovere quel confine incorporando password o segreti di chiave privata in un’esportazione di Tasker condivisa.

Non farlo. Un’esportazione di attività è un file di testo che le persone copiano nelle chat, e i segreti inseriti lì sono divulgati nel momento in cui viene condiviso. Usa le credenziali di connettività salvate dall’app se il profilo ne ha bisogno, e lascia che le richieste MFA restino richieste. Qualsiasi cosa eviti la richiesta memorizzando la risposta ha spostato il segreto invece di risolvere il problema.

Il lato della disconnessione ha la sua azione documentata, e non è un trucco giocato al client:

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

Connettersi a un profilo deliberatamente inesistente per forzare una disconnessione è il tipo di espediente che compare in vecchi thread e poi fallisce in silenzio dopo un aggiornamento. Usa l’azione esplicita.

Controlla lo stato prima che parta il passo successivo

Un avvio riuscito dell’intent prova che la richiesta è stata consegnata, non che esista un tunnel. Se l’attività apre poi un’applicazione interna,quel passo richiede una condizione di prontezza con un timeout limitato. Un’azione immediata dopo l’invio finirà per scattare contro una richiesta.

$ 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 query resolve conferma che il pacchetto e l’attività a cui miri esistono su quel dispositivo, il che esclude un refuso nel campo classe. Il dump delle attività mostra che cosa c’è davvero in primo piano dopo l’esecuzione dell’attività, ed è il modo più economico per vedere se l’app ha aperto una richiesta invece di connettersi. Esegui entrambi dopo un’attività fallita invece di indovinare quale campo è sbagliato. Una discrepanza nel nome della classe produce un errore immediato, mentre un profilo mancante non produce alcun errore visibile.

Decidi la proprietà della disconnessione prima di rilasciare l’attività. Una scorciatoia che abbatte un tunnel da cui dipende un’altra attività di lavoro genererà un ticket di supporto che non somiglia affatto alla sua causa. Tenere due automazioni che controllano lo stesso client crea una corsa che non puoi diagnosticare dai log, quindi elimina l’azione obsoleta quando la nuova funziona.