Старое обходное решение перенесло исполняемый файл OpenVPN в другое место и оставило shell-обёртку по исходному пути. Спустя месяцы приходит обновление, и откат решения превращается в угадывание, какой файл на самом деле является клиентом. Имя команды, исполняемый файл, настроенный в службе, и собственный список файлов пакета могут указывать на разные объекты, а починка одного из них без остальных даёт хост, который выглядит исправленным и ведёт себя хуже.

Начните с пути, который запускает служба

Терминал и юнит systemd разрешают исполняемые файлы по-разному. Оболочка ищет в PATH; юнит называет путь, и drop-in-переопределения могут заменить его, не трогая читаемый вами файл. Именно это различие объясняет большую часть путаницы в этой задаче. Оно же определяет, на какой файл должна быть направлена ваша починка.

Спросите юнит, что он запускает, включая drop-in-файлы, которые его меняют, и читайте получившуюся строку ExecStart, а не фрагмент, который вы считаете главным. Затем проследите этот путь через любую символическую ссылку до конечного файла. Обёртка, заканчивающаяся exec в скрытый каталог, — обычная конструкция из этих старых исправлений.

Запишите разрешённый путь, прежде чем что-либо менять.

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

Сравните имя команды с путём службы

Два ответа часто различаются, и это различие не обязательно является неисправностью. Плагин NetworkManager может запускать свой путь, а контейнер может смонтировать ещё один.

Важно знать, какой владелец запускает процесс, обслуживающий трафик. Если юнит запускает /usr/local/sbin/openvpn-wrapper, а ваша оболочка разрешает /usr/sbin/openvpn, починка второго файла ничего не меняет в службе.

Спросите, какому пакету принадлежит каждый кандидат, затем решите, управляется ли файл пакетом или размещён локально. Файл без владеющего пакета — это файл, который кто-то намеренно положил туда, и он заслуживает имени, владельца и причины, прежде чем его удалят. Обратная ошибка тоже распространена: перезапись файла пакета старым сохранённым двоичным файлом, потому что в сообщении на форуме использовался тот же каталог.

Пусть база данных пакетов говорит о файлах пакета

Если программное обеспечение пришло из пакета Debian, база данных пакетов может сказать, соответствуют ли его файлы установленному. Это узкий вопрос целостности, а не приговор безопасности, и разница важна, когда вы решаете, что чинить. Несовпадение означает, что файл изменился после установки, и это могло быть вашим старым обходным решением или законным локальным изменением. Вывод не решает, что именно, поэтому читайте его как указание, а не как вывод.

Запустите проверку и прочитайте вывод, а не считайте пустой результат доказательством чего-либо.

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

Руководство dpkg документирует, что проверка сравнивает установленные файлы с локально записанными метаданными, используя сохранённые контрольные суммы там, где они есть. Она замечает изменённый файл пакета и не может сказать, запускается ли вместо него другой двоичный файл.

Запишите состояние до починки

Соберите разрешённый путь запуска, связь файла с пакетом, расположение обёртки и запись изменения, которая её ввела. Скопируйте обёртку в защищённое место, если в ней есть интеграционная работа, которая понадобится позже.

Не вставляйте содержимое обёртки в тему поддержки, не прочитав его, потому что эти скрипты иногда несут учётные данные или сведения о шлюзе.

Запишите, какие профили использует служба и кто подключён, пока вы работаете, потому что перезапуск туннеля может прервать сеанс, через который вы администрируете хост.

Проверьте запуск, затем уберите обёртку

После починки запустите службу и убедитесь, что процесс работает по нужному пути. Запрос версии, выполненный вручную, доказывает, что файл работает; он не доказывает, что юнит использует его.

Затем снова подключите клиент и проверьте, проходит ли профиль аутентификацию, потому что замена двоичного файла, игнорирующая исходные параметры, закончится отказом, похожим на проблему с сертификатом.

Уберите вытесненную обёртку через ту же запись изменения, которая её ввела. Завершённая починка указывает, какой исполняемый файл работает, почему и какой файл был удалён; восстановить имя файла и надеяться — это не то же самое.

Похожие статьи