Клиентский хук или серверный хук? Где выполняется скрипт OpenVPN

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

Две машины, два вопроса, на которые нужно ответить сначала

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

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

Перед обоими стоит задать третий вопрос: а платформа вообще предоставляет нужный хук? Устройство, которое само генерирует конфигурацию, может не предлагать те же имена событий, а настольный клиент, импортирующий файл .ovpn, не обязательно тот самый клиент, для которого файл написан. Если сначала убедиться в платформе, вы не будете проектировать вокруг хука, которого там нет. Это также подскажет, какая документация действительно относится к машине перед вами.

Серверный вариант: событие на каждое подключение

Скрипт client-connect выполняется в контексте процесса сервера, когда подключается аутентифицированный клиент, и получает документированные сведения о соединении, например common name и выделенный адрес. Это правильное место, чтобы записать фрагмент конфигурации для клиента, применить политическое решение или зафиксировать состояние, которым владеет сервер.

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

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

Клиентский вариант: работа, которая должна выполняться локально

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

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

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

Почему проталкивание исполняемого кода не входит в список опций

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

Включение выполнения скриптов локально этого не меняет. Ваша настройка script-security разрешает локальные скрипты, которые выбрали вы; она не даёт серверу права поставлять новые.

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

Что проверить, прежде чем доверять любому из хуков

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

Проверяйте под той учётной записью, которая действительно его выполнит, и в тот момент, когда он действительно будет выполняться. Руководство openvpn(8) описывает оба семейства хуков и ограничения push; платформа, на которой вы развёртываете, описывает, предоставляет ли она их вообще. Скрипт, успешный в интерактивном терминале администратора, — это гипотеза, а не проверка.