OpenVPN в Windows: автозапуск туннеля и сохранение маршрутов

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

Шаг первый: положите профиль туда, где его ищет служба

Служба Windows читает профили из фиксированного каталога, и графический интерфейс читает оттуда же, поэтому профиль, который работает при импорте, может оставаться невидимым при загрузке. Положите файлы .ovpn в каталог config установки, который обычно находится внутри Program Files. Профиль, оставленный в папке Downloads пользователя, вообще не входит в область действия службы.

Более старые руководства указывают на папку config-auto, которую уважали некоторые сборки эпохи 2.5, а поздние выпуски — нет. Поэтому обновление может превратить работающий автозапуск в тишину, и в журнале не будет ничего про учётные данные. Прежде чем перемещать файлы, подтвердите, какой каталог на самом деле читает установленная сборка.

Если на одной машине несколько профилей, дайте каждому именованный адаптер через dev-node. Иначе они конкурируют за один и тот же интерфейс, и второй отказывает так, что это выглядит как проблема с учётными данными.

Шаг второй: запустите службу, а не значок в области уведомлений

Перевод службы OpenVPN в режим Automatic заставляет её запускаться при загрузке без входа в систему. Это и есть механизм, а значок в области уведомлений в него не входит. Когда соединением владеет служба, графический интерфейс может не показывать ни значка, ни состояния, и это ожидаемо, а не неисправность.

Следствие: отключение означает остановку службы, а не нажатие Disconnect. Скажите об этом тому, кто обслуживает машину, иначе первый звонок в поддержку будет про пропавший значок.

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

Шаг третий: привяжите маршрут к туннелю

Постоянная запись здесь — неподходящий инструмент. Добавление маршрута с -P заставляет его переживать перезагрузки и, что хуже, переживать закрытие туннеля. Когда VPN выключен, префикс по-прежнему указывает на шлюз, которого больше нет, поэтому узел не достигнет этого назначения, пока кто-нибудь не удалит запись.

Три альтернативы ведут себя правильно. Протолкните маршрут с сервера: он добавляется при подключении и удаляется при отключении. Добавьте его в скрипт route-up, который читает route_vpn_gateway, чтобы следующий переход пришёл из согласованного туннеля. Или используйте Add-VpnConnectionRoute с собственным профилем VPN Windows, который привязывает префикс к этому соединению.

Когда сервер предлагает больше, чем нужно этой площадке, route-nopull отвергает протолкнутые маршруты и оставляет таблицу полностью локальной. Это подходит общему профилю, пользователи которого не должны получать корпоративный маршрут по умолчанию.

Шаг четвёртый: переживите холодную загрузку

Запуск службы до появления сетевого стека даёт одну неудачную попытку и никакого повтора. Перевод в Automatic (Delayed Start) или добавление зависимости от сетевой службы убирает эту гонку. Затем повторите тест загрузки и убедитесь, что вторая попытка больше не нужна.

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

Проверяйте ту последовательность, которую действительно разворачиваете, а не ту, которую можно запустить вручную. Холодная загрузка — единственный тест, который проверяет порядок.

Шаг пятый: проверьте без графического интерфейса

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

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