OpenVPN Connect och Tasker: profil-ID, inte namnet

En automatisering som anslöt pålitligt i månader slutar fungera efter en klientuppdatering, medan samma profil fortfarande ansluter för hand. Det mönstret pekar på styrningskontraktet och inte på VPN-servern. Någon har ändrat vilken åtgärd appen accepterar, eller vilken identifierare den förväntar sig, och uppgiften skickar fortfarande den gamla. Det tar kortare tid att bygga om bindningen än att kontrollera servern igen.

Kontraktet tillhör en app och ett versionsintervall

OpenVPN Connect och OpenVPN for Android är olika program, och ett intent som namnger det ena paketet gör ingenting i det andra. Innan du rör uppgiften ska du bekräfta vilken klient som är installerad och vilken version som gav det beteende du jämför med. För Connect på Android 3.3.2 eller senare förväntar sig den dokumenterade Tasker-integrationen ett profil-ID. Äldre instruktioner som sätter AS eller PC framför ett visningsnamn beskriver ett tidigare kontrakt, och att kopiera dem till en aktuell uppgift är det vanliga skälet till att ingenting händer.

Den versionsgränsen förklarar de flesta rapporter om att det fungerade förut. Appen bröt inte funktionen; den ändrade vad funktionen accepterar. Behandla versionsintervallet som en del av det kontrakt du skriver mot.

Var identifieraren kommer ifrån

Öppna den avsedda profilen i Connect och kopiera dess profil-ID från profilens egna detaljer. Använd det värdet i stället för ett namn du känner igen från listan, eftersom namnet är en etikett och identifieraren är det appen matchar mot. Anslutningsfälten i Taskers Send Intent-åtgärd ser ut som blocket nedan, där bara identifieraren är utbytt. Håll också appinstansen för den personliga profilen eller arbetsprofilen konsekvent.

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 kopia i arbetsprofilen med samma paketnamn och en annan lagrad profil accepterar intentet och hittar ingen matchande profil, vilket ser ut som en trasig uppgift och inte som ett omfångsfel. Om profilen importeras om eller ersätts ska du betrakta identifieraren som misstänkt och kontrollera den igen. En ny import ger ofta en ny profilpost även när visningsnamnet är oförändrat. Kontrollera identifieraren innan du ändrar något annat.

Lämna orelaterade fält tomma enligt dokumentationen. Fält för kategori, MIME-typ och data som guiden inte ber om kan ändra hur Android löser intentet, och ett intent som löses annorlunda kan starta appen utan att starta din profil.

Vad åtgärden gör och vad den lämnar till dig

Att skicka anslutningsintentet ber appen att starta en profil. Det kringgår inte den auktorisering som profilen kräver. Connect kan fortfarande visa en fråga, och därför förutsätter det dokumenterade autonoma fallet ingen ytterligare auktorisering och inga sparade anslutningsuppgifter. Frestelsen är att ta bort den gränsen genom att bädda in lösenord eller hemligheter för den privata nyckeln i en delad Tasker-export.

Gör inte det. En uppgiftsexport är en textfil som folk kopierar in i chattrådar, och hemligheter som placeras där avslöjas i samma stund som den delas. Använd appens egna sparade anslutningsuppgifter om profilen behöver dem, och låt MFA-frågor förbli frågor. Allt som undviker frågan genom att spara svaret har flyttat hemligheten i stället för att lösa problemet.

Frånkopplingssidan har sin egen dokumenterade åtgärd, och det är inte ett trick mot klienten:

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

Att ansluta till en medvetet obefintlig profil för att tvinga fram en frånkoppling är den sorts kringgående som dyker upp i gamla trådar och sedan misslyckas tyst efter en uppdatering. Använd den uttryckliga åtgärden.

Kontrollera läget innan nästa steg körs

En lyckad intent-start bevisar att begäran levererades, inte att det finns en tunnel. Om uppgiften sedan öppnar ett internt program,behöver det steget ett beredskapsvillkor med en avgränsad tidsgräns. En omedelbar åtgärd efter sändningen kommer förr eller senare att slå mot en fråga.

$ 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-frågan bekräftar att paketet och aktiviteten du siktar på finns på den enheten, vilket utesluter ett skrivfel i klassfältet. Aktivitetsdumpen visar vad som faktiskt ligger i förgrunden efter att din uppgift har körts, och det är det billigaste sättet att se om appen öppnade en fråga i stället för att ansluta. Kör båda efter en misslyckad uppgift i stället för att gissa vilket fält som är fel. En avvikelse i klassnamnet ger ett omedelbart fel, medan en saknad profil inte ger något synligt fel alls.

Bestäm ägarskapet för frånkopplingen innan du levererar uppgiften. En genväg som river ner en tunnel som en annan arbetsuppgift är beroende av skapar ett supportärende som inte alls liknar sin orsak. Att behålla två automatiseringar som båda styr samma klient skapar en kapplöpning du inte kan felsöka ur loggarna, så ta bort den föråldrade åtgärden när den nya fungerar.