OpenVPN Connect og Tasker: profil-ID, ikke navnet

En automatisering som koblet til pålitelig i månedsvis slutter å virke etter en klientoppdatering, mens samme profil fortsatt kobler til manuelt. Det mønsteret peker på styringskontrakten og ikke på VPN-serveren. Noen har endret hvilken handling appen godtar, eller hvilken identifikator den forventer, og oppgaven sender fortsatt den gamle. Det tar kortere tid å bygge bindingen på nytt enn å kontrollere serveren igjen.

Kontrakten tilhører én app og ett versjonsintervall

OpenVPN Connect og OpenVPN for Android er forskjellige programmer, og et intent som navngir den ene pakken, gjør ingenting i den andre. Før du rører oppgaven, må du bekrefte hvilken klient som er installert og hvilken versjon som ga oppførselen du sammenligner med. For Connect på Android 3.3.2 eller nyere forventer den dokumenterte Tasker-integrasjonen et profil-ID. Eldre instruksjoner som setter AS eller PC foran et visningsnavn, beskriver en tidligere kontrakt, og å kopiere dem inn i en gjeldende oppgave er den vanlige grunnen til at ingenting skjer.

Den versjonsgrensen forklarer de fleste rapportene om at det virket før. Appen ødela ikke funksjonen; den endret hva funksjonen godtar. Behandle versjonsintervallet som en del av kontrakten du skriver mot.

Hvor identifikatoren kommer fra

Åpne den tiltenkte profilen i Connect og kopier profil-ID-en fra profilens egne detaljer. Bruk den verdien i stedet for et navn du kjenner igjen fra listen, fordi navnet er en etikett og identifikatoren er det appen matcher mot. Tilkoblingsfeltene i Taskers Send Intent-handling ser ut som blokken nedenfor, der bare identifikatoren er byttet ut. Hold også app-forekomsten for den personlige profilen eller arbeidsprofilen konsistent.

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

En kopi i arbeidsprofilen med samme pakkenavn og en annen lagret profil godtar intentet og finner ingen samsvarende profil, noe som ser ut som en ødelagt oppgave og ikke som en omfangsfeil. Hvis profilen importeres på nytt eller erstattes, bør du behandle identifikatoren som mistenkelig og kontrollere den igjen. Ny import gir ofte en ny profiloppføring selv når visningsnavnet er uendret. Kontroller identifikatoren før du endrer noe annet.

La ikke-relaterte felt stå tomme som dokumentert. Felt for kategori, MIME-type og data som veiledningen ikke ber om, kan endre hvordan Android løser intentet, og et intent som løses annerledes, kan starte appen uten å starte profilen din.

Hva handlingen gjør, og hva den overlater til deg

Å sende tilkoblingsintentet ber appen starte en profil. Det omgår ikke den autorisasjonen profilen krever. Connect kan fortsatt vise en forespørsel, og derfor forutsetter det dokumenterte autonome tilfellet ingen ytterligere autorisasjon og ingen lagrede tilkoblingsopplysninger. Fristelsen er å fjerne den grensen ved å bygge inn passord eller hemmeligheter for den private nøkkelen i en delt Tasker-eksport.

Ikke gjør det. En oppgaveeksport er en tekstfil som folk kopierer inn i chatttråder, og hemmeligheter som plasseres der, avsløres i det øyeblikket den deles. Bruk appens egne lagrede tilkoblingsopplysninger hvis profilen trenger dem, og la MFA-forespørsler forbli forespørsler. Alt som unngår forespørselen ved å lagre svaret, har flyttet hemmeligheten i stedet for å løse problemet.

Frakoblingssiden har sin egen dokumenterte handling, og det er ikke et triks mot klienten:

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

Å koble til en bevisst ikke-eksisterende profil for å tvinge fram en frakobling er den typen workaround som dukker opp i gamle tråder og deretter feiler stille etter en oppdatering. Bruk den eksplisitte handlingen.

Kontroller tilstanden før neste steg kjører

En vellykket intent-start beviser at forespørselen ble levert, ikke at det finnes en tunnel. Hvis oppgaven deretter åpner et internt program,trenger det steget en beredskapsbetingelse med en avgrenset tidsgrense. En umiddelbar handling etter sendingen vil før eller siden treffe en forespørsel.

$ 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

Resolve-spørringen bekrefter at pakken og aktiviteten du sikter på, finnes på den enheten, noe som utelukker en skrivefeil i klassefeltet. Aktivitetsdumpen viser hva som faktisk er i forgrunnen etter at oppgaven din kjører, og det er den billigste måten å se om appen åpnet en forespørsel i stedet for å koble til. Kjør begge etter en mislykket oppgave i stedet for å gjette hvilket felt som er feil. En avvik i klassenavnet gir en umiddelbar feil, mens en manglende profil ikke gir noen synlig feil i det hele tatt.

Bestem eierskapet til frakoblingen før du leverer oppgaven. En snarvei som river ned en tunnel som en annen arbeidsoppgave er avhengig av, gir en støttesak som slett ikke ligner årsaken sin. Å beholde to automatiseringer som begge styrer samme klient gir et kappløp du ikke kan feilsøke fra loggene, så slett den utdaterte handlingen når den nye virker.