OpenVPN Connect и Tasker: ID профиля, а не имя

Автоматизация, которая месяцами надёжно подключалась, перестаёт работать после обновления клиента, хотя тот же профиль по-прежнему подключается вручную. Этот шаблон указывает на контракт управления, а не на сервер 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 подтверждает, что пакет и активность, на которые вы нацелены, существуют на этом устройстве, что исключает опечатку в поле класса. Дамп активности показывает, что на самом деле находится на переднем плане после запуска задачи, и это самый дешёвый способ увидеть, открыло ли приложение запрос вместо подключения. Запустите оба после неудачной задачи, вместо того чтобы гадать, какое поле неверно. Расхождение в имени класса даёт немедленную ошибку, тогда как отсутствующий профиль не даёт никакой видимой ошибки.

Решите, кому принадлежит отключение, прежде чем отправлять задачу. Ярлык, который обрывает туннель, от которого зависит другая рабочая задача, создаст обращение в поддержку, ничуть не похожее на свою причину. Держать две автоматизации, которые обе управляют одним клиентом, создаёт гонку, которую вы не сможете отладить по журналам, поэтому удалите устаревшее действие, как только новое заработает.