Автоматизация, която месеци наред се свързваше надеждно, спира да работи след актуализация на клиента, докато същият профил продължава да се свързва ръчно. Този модел сочи към договора за управление, а не към VPN сървъра. Някой е променил кое действие приема приложението или кой идентификатор очаква, а задачата продължава да изпраща стария. Повторното изграждане на връзката отнема по-малко време от повторната проверка на сървъра.

Договорът принадлежи на едно приложение и един диапазон от версии

OpenVPN Connect и OpenVPN for Android са различни приложения и intent, който именува един пакет, не прави нищо в другия. Преди да пипате задачата, потвърдете кой клиент е инсталиран и коя версия е създала поведението, с което сравнявате. За Connect на Android 3.3.2 или по-нова документираната интеграция с Tasker очаква ID на профил. По-старите инструкции, които поставят AS или PC пред показваното име, описват предишен договор и копирането им в текуща задача е обичайната причина да не се случва нищо.

Тази граница на версиите обяснява повечето съобщения, че преди е работело. Приложението не счупи функцията; промени какво приема функцията. Отнасяйте се към диапазона от версии като част от договора, срещу който пишете.

Откъде идва идентификаторът

Отворете желания профил в Connect и копирайте неговия ID на профил от данните на самия профил. Използвайте тази стойност вместо име, което разпознавате от списъка, защото името е етикет, а идентификаторът е това, с което приложението сравнява. Полетата за връзка в действието Send Intent в Tasker изглеждат като блока по-долу, като е заменен само идентификаторът. Поддържайте последователност и на инстанцията на приложението за личния или работния профил.

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

Копие в работния профил със същото име на пакет и друг запазен профил ще приеме intent и няма да намери съвпадащ профил, което изглежда като счупена задача, а не като грешка в обхвата. Ако профилът бъде внесен отново или заменен, считайте идентификатора за подозрителен и го проверете отново. Повторният внос често създава нов запис за профил, дори когато показваното име не се променя. Проверете идентификатора, преди да промените нещо друго.

Оставете несвързаните полета празни, както е документирано. Полетата за категория, MIME тип и данни, които ръководството не изисква, могат да променят как Android решава intent, а intent, решен по друг начин, може да стартира приложението, без да стартира вашия профил.

Какво прави действието и какво оставя на вас

Изпращането на intent за свързване иска от приложението да стартира профил. То не заобикаля оторизацията, която изисква този профил. Connect може да покаже подкана, поради което документираният автономен случай предполага липса на допълнителна оторизация и запазени данни за свързване. Изкушението е да премахнете тази граница, като вградите пароли или тайни на частния ключ в споделен експорт на Tasker.

Не правете това. Експортът на задача е текстов файл, който хората копират в чат нишки, и тайните, поставени там, се разкриват в момента, в който бъде споделен. Използвайте собствените запазени данни за свързване на приложението, ако профилът се нуждае от тях, и оставете подканите за MFA да си останат подкани. Всичко, което избягва подканата чрез запазване на отговора, е преместило тайната, вместо да реши проблема.

Страната на прекъсването има свое документирано действие и то не е трик срещу клиента:

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

Свързването с умишлено несъществуващ профил, за да се предизвика прекъсване, е вид заобиколно решение, което се появява в стари нишки и след това тихо се проваля след актуализация. Използвайте явното действие.

Проверете състоянието, преди следващата стъпка да се изпълни

Успешното стартиране на intent доказва, че заявката е доставена, а не че съществува тунел. Ако задачата след това отвори вътрешно приложение,тази стъпка се нуждае от условие за готовност с ограничен таймаут. Непосредствено действие след изпращането рано или късно ще се сблъска с подкана.

$ 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 потвърждава, че пакетът и активността, към които се целите, съществуват на това устройство, което изключва печатна грешка в полето за клас. Изхвърлянето на активността показва какво действително е на преден план след изпълнението на задачата и това е най-евтиният начин да видите дали приложението е отворило подкана, вместо да се свърже. Изпълнете и двете след неуспешна задача, вместо да гадаете кое поле е грешно. Несъответствие в името на класа дава незабавна грешка, докато липсващ профил не дава никаква видима грешка.

Решете собствеността на прекъсването, преди да предадете задачата. Пряк път, който събаря тунел, от който зависи друга работна задача, ще генерира заявка до поддръжката, която в нищо не прилича на причината си. Поддържането на две автоматизации, които и двете управляват един и същ клиент, създава състезание, което не можете да отстраните от журналите, затова изтрийте остарялото действие, щом новото заработи.

Подобни статии