OpenVPN Connect kaj Tasker: la profila ID, ne la nomo

Aŭtomatigo, kiu fideble konektiĝis dum monatoj, ĉesas funkcii post klienta ĝisdatigo, dum la sama profilo ankoraŭ konektiĝas permane. Tiu ŝablono indikas la regan kontrakton, ne la VPN-servilon. Iu ŝanĝis, kiun agon la apo akceptas, aŭ kiun identigilon ĝi atendas, kaj la tasko ankoraŭ sendas la malnovan. Rekonstrui la ligon postulas malpli da tempo ol rekontroli la servilon.

La kontrakto apartenas al unu apo kaj al unu versia gamo

OpenVPN Connect kaj OpenVPN for Android estas malsamaj aplikoj, kaj intenco, kiu nomas unu pakaĵon, faras nenion en la alia. Antaŭ ol tuŝi la taskon, konfirmu, kiu kliento estas instalita kaj kiu versio produktis la konduton, kun kiu vi komparas. Por Connect sur Android 3.3.2 aŭ pli nova, la dokumentita Tasker-integriĝo atendas profilan ID. Pli malnovaj instrukcioj, kiuj antaŭmetas AS aŭ PC antaŭ vidigeblan nomon, priskribas antaŭan kontrakton, kaj kopii ilin en aktualan taskon estas la kutima kaŭzo, ke nenio okazas.

Tiu versia limo klarigas la plej multajn raportojn, ke ĝi antaŭe funkciis. La apo ne rompis la funkcion; ĝi ŝanĝis, kion la funkcio akceptas. Traktu la versian gamon kiel parton de la kontrakto, kontraŭ kiu vi skribas.

De kie venas la identigilo

Malfermu la celatan profilon en Connect kaj kopiu ĝian profilan ID el la detaloj de la profilo mem. Uzu tiun valoron anstataŭ nomon, kiun vi rekonas el la listo, ĉar la nomo estas etikedo kaj la identigilo estas tio, kun kio la apo komparas. La konektaj kampoj de la ago Send Intent en Tasker aspektas kiel la bloko sube, kun nur la identigilo anstataŭigita. Tenu ankaŭ la apan instance de la persona aŭ labora profilo konsekvenca.

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

Kopio en la labora profilo kun la sama pakaĵnomo kaj alia konservita profilo akceptos la intencon kaj trovos neniun kongruan profilon, kio aspektas kiel rompita tasko kaj ne kiel ampleksa eraro. Se la profilo estas reimportita aŭ anstataŭigita, traktu la identigilon kiel suspektan kaj kontrolu ĝin denove. Reimporto ofte produktas novan profilan eron eĉ kiam la vidigebla nomo restas senŝanĝa. Kontrolu la identigilon antaŭ ol ŝanĝi ion ajn alian.

Lasu nerilatajn kampojn malplenaj, kiel dokumentite. Kampoj por kategorio, MIME-tipo kaj datumoj, kiujn la gvidilo ne petas, povas ŝanĝi, kiel Android solvas la intencon, kaj intenco, kiu solviĝas alie, povas lanĉi la apon sen lanĉi vian profilon.

Kion faras la ago, kaj kion ĝi lasas al vi

Sendi la konektan intencon petas la apon lanĉi profilon. Ĝi ne ĉirkaŭiras la rajtigon, kiun tiu profilo postulas. Connect ankoraŭ povas montri demandon, kaj tial la dokumentita aŭtonoma kazo supozas neniun plian rajtigon kaj neniujn konservitajn konektajn akreditaĵojn. La tento estas forigi tiun limon per enigo de pasvortoj aŭ sekretoj de la privata ŝlosilo en dividitan Tasker-eksporton.

Ne faru tion. Tasko-eksporto estas tekstdosiero, kiun homoj kopias en babilejojn, kaj sekretoj metitaj tien estas malkaŝitaj en la momento, kiam ĝi estas dividita. Uzu la proprajn konservitajn konektajn akreditaĵojn de la apo, se la profilo bezonas ilin, kaj lasu MFA-demandojn resti demandoj. Io ajn, kio evitas la demandon per konservado de la respondo, movis la sekreton anstataŭ solvi la problemon.

La malkonekta flanko havas sian propran dokumentitan agon, kaj ĝi ne estas ruzo kontraŭ la kliento:

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

Konektiĝi al intence neekzistanta profilo por devigi malkonekton estas la speco de solvo, kiu aperas en malnovaj fadenoj kaj poste malsukcesas silente post ĝisdatigo. Uzu la eksplicitan agon.

Kontrolu la staton antaŭ ol la sekva paŝo ruliĝas

Sukcesa intenca lanĉo pruvas, ke la peto estis liverita, ne ke tunelo ekzistas. Se la tasko poste malfermas internan aplikon,tiu paŝo bezonas pretecan kondiĉon kun limigita tempolimo. Tuja ago post la sendo finfine pafos kontraŭ demando.

$ 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 resolve-demando konfirmas, ke la pakaĵo kaj agado, kiujn vi celas, ekzistas sur tiu aparato, kio ekskludas tajperaron en la klasa kampo. La agada elĵeto montras, kio efektive estas en la malfono post kiam via tasko ruliĝas, kaj ĝi estas la plej malmultekosta maniero vidi, ĉu la apo malfermis demandon anstataŭ konektiĝi. Rulu ambaŭ post malsukcesa tasko anstataŭ diveni, kiu kampo estas malĝusta. Miskongruo en la klasa nomo produktas tujan eraron, dum mankanta profilo produktas tute neniun videblan eraron.

Decidu la posedon de la malkonekto antaŭ ol liveri la taskon. Fuĝvojo, kiu faligas tunnelon, de kiu dependas alia labora tasko, generos subtenan bileton, kiu tute ne similas sian kaŭzon. Teni du aŭtomatigojn, kiuj ambaŭ regas la saman klienton, kreas vetkuron, kiun vi ne povas sencimigi el la protokoloj, do forigu la malnoviĝintan agon, kiam la nova funkcias.