Служба OpenVPN не запускается с профилем, который открывает GUI: пять проверок
Тот же профиль, другой запускающий. Проверьте рабочий каталог, учётную запись службы, атрибут зашифрованного файла, владельца, а затем обёртку.
Два средства запуска открывают один и тот же профиль на одной машине, и подключается только GUI. Файл цел, установщик, вероятно, в порядке; различается контекст, который каждое средство запуска передаёт openvpn.exe. Рабочий каталог, идентичность учётной записи и атрибуты файла — всё это идёт вместе с тем контекстом. Проверяйте их в этом порядке и остановитесь на первом, который объясняет ошибку.
Убедитесь, какое средство запуска даёт сбой
Начните с доказательства разделения. Если GUI подключается, а служба нет, при том же пути к профилю, значит файл кому-то доступен на чтение, и вопрос становится в том, кто его читает и откуда. Если не работают оба, профиль повреждён, и ничего из этого не применимо. Запишите имя службы и точный профиль, который ей было велено загрузить.
Служба, указанная на собственный каталог автозапуска, может не загружать файл, открытый у вас в редакторе. Сравните путь в конфигурации службы с путём в GUI, символ за символом, потому что лишнее имя папки в конце или другая буква диска уже уведут вас не в ту ветку.
Где разрешаются относительные пути
Профиль, который ссылается на ca.crt или на вспомогательный скрипт только по имени, требует поиска относительно места, где находится процесс. GUI стартует в каталоге конфигурации, поэтому эти имена разрешаются. У службы, запущенной диспетчером служб, такой начальной точки нет, и поиск завершается ошибкой ещё до чтения любого сертификата. Поэтому один и тот же профиль работает в одном средстве запуска и не работает в другом.
Дайте обёртке каталог для запуска или сделайте каждую ссылку абсолютной. Воспроизведение контекста GUI в командной строке выглядит так:
openvpn --cd "C:\VPN\profiles\office" --config "C:\VPN\profiles\office\office.ovpn"
Повышение подробности у этой команды показывает точный путь, который был испробован. Сделайте это до изменения разрешений, потому что отсутствующий файл и отказ в чтении требуют разных исправлений. Журнал по умолчанию их не различает. Один дополнительный флаг экономит час догадок.
Когда идентичность службы не может читать
Служба работает под системной идентичностью, а не под вашей. ACL, который даёт вашему пользователю полный контроль и никому больше, там отказывает, хотя в вашем сеансе работает безупречно. Профиль, хранящийся на подключённом диске или на аутентифицированном ресурсе, отказывает по той же причине. Подтвердите разрешения файла, прежде чем смотреть на что-либо ещё.
Проверка — это чтение действующих разрешений плюс чтение, испробованное как идентичность службы. Выполните первую часть из командной строки с повышенными правами:
icacls "C:\VPN\profiles\office\office.ovpn"
Затем попробуйте то же чтение как идентичность службы, например с psexec -s -i от Sysinternals, и посмотрите, открывается ли файл. Если нет, никакое исправление пути не поможет. Исправьте ACL или перенесите профиль туда, откуда идентичность службы может читать.
Шифрование на уровне файла — второй, более редкий случай. Профиль с атрибутом Encrypting File System прозрачно расшифровывается для пользователя, зашифровавшего его, и остаётся нечитаемым для учётной записи службы. Поэтому один и тот же файл открывается в вашем редакторе и не открывается под службой.
Атрибут виден из командной строки с повышенными правами, и его проверка не открывает профиль. Выполните обе команды и прочитайте вывод:
cipher /s:"C:\VPN\profiles\office"
attrib "C:\VPN\profiles\office\office.ovpn"
Снятие атрибута делает файл читаемым, а также снимает защиту, которую он нёс. Если профиль должен оставаться защищённым, положите секретный материал туда, где у идентичности службы есть явное разрешение, вместо того чтобы полагаться на шифрование по пользователю. Такое устройство переживает смену пароля и делает доступ проверяемым для кого-то другого, а не для того, кто зашифровал файл.
Решение, кому принадлежит туннель
GUI может запросить пароль и прочитать сертификат из вашего хранилища пользователя. Служба не может ни того, ни другого, поэтому профиль, зависящий от интерактивного секрета, никогда не запустится без надзора, как бы ни исправлялись пути. Этот предел — проектное решение, а не дефект, который нужно обходить. Выберите одного владельца, прежде чем менять что-либо ещё.
Если туннель должен быть поднят до входа в систему, дайте службе источник учётных данных без надзора и собственную копию профиля. Если он нужен только пока вы за столом, оставьте его в GUI и удалите копию службы. Оба сразу — это конфигурация, порождающая конфликты адаптеров и дублирующиеся маршруты.
Такой конфликт обычно диагностируют как ошибку конфигурации, а не как двух владельцев, борющихся за один адаптер. Журнал событий покажет процесс, которому не удаётся открыть устройство TAP, что выглядит как проблема разрешений, но ею не является. Сначала посчитайте владельцев.
Что на самом деле запускает обёртка службы
Точка входа службы — небольшая обёртка, которая читает свои сохранённые параметры и затем запускает openvpn.exe. Когда командная строка в журнале событий не совпадает с вашим ожиданием, именно эти значения и нужно изучать. Переустановка возвращает их к значениям по умолчанию и уничтожает доказательства. Прочитайте их первыми.
Значения живут в реестре под собственным ключом службы, а sc qc показывает путь к двоичному файлу, который запустит диспетчер служб. Сравните этот путь с сохранённой конфигурацией обёртки, прежде чем редактировать любой из них.
Замена обёртки скриптом, который вы контролируете, более инвазивна, но сворачивает действующую командную строку в один читаемый файл. Закончите перезапуском, затем читайте журнал по профилю, пока не появится первая успешная строка запуска. Состояние службы «работает» означает лишь, что обёртка не завершилась, что верно и тогда, когда её дочерний процесс умер сразу.