Ваш файл .ovpn может выполнять код, а не только маршрутизировать трафик

Большинство людей читают файл .ovpn так же, как страницу настроек роутера: адреса, маршруты, список шифров. Часть, которая выполняет код, находится ближе к концу, рядом с директивами, которые выглядят как сантехнические работы, и работает с теми правами, которые у клиента уже есть. Это та лазейка, которую использует небрежный или вредоносный профиль, и это же та лазейка, которая через три недели превращает полезный DNS-помощник в проблему поддержки. Директива события, уровень безопасности и владелец файла решают, что может произойти; содержимое скрипта решает, что происходит на самом деле. Прочитайте все четыре, прежде чем подключаться.

Профиль, запускающий помощник, — это программа, а не файл настроек

Директивы вроде route и dhcp-option описывают состояние, которое клиент должен установить, и клиент относится к ним как к данным. Скрипт up другой: клиент запускает его как процесс и передаёт окружение, полное деталей подключения, поэтому всё, что написал автор, выполняется с правами вашей учётной записи. На ноутбуке, где пользователь администратор, это широкая дверь для файла, пришедшего вложением или вставленного из темы форума. Различие не стилистическое, это разница между конфигурацией и кодом.

Миф, который пора отправить на покой, состоит в том, что профиль может только перенаправлять трафик. Помощник, выполняющий ip route add, и тот, что выполняет curl к удалённому хосту, — один и тот же механизм, и профиль снаружи выглядит одинаково. Ничто в облике файла не говорит, какой из них у вас, поэтому проверка должна дойти до самого скрипта.

Что на самом деле определяет выполнение и как выглядят разрешающие строки

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

script-security 2
up /etc/openvpn/update-resolv-conf.sh
down /etc/openvpn/update-resolv-conf.sh

Уровень 0 отказывает внешним программам, а уровень 1, заданный по умолчанию, разрешает только встроенные исполняемые файлы клиента, поэтому хуку нужно 2 или выше; уровень 3 существует в основном для передачи старых паролей и его лучше избегать. Профилю с хуком нужны и директива, и этот уровень, поэтому одна строка ближе к концу файла заслуживает такой же проверки, как блок сертификата. Руководство OpenVPN перечисляет уровни прав, и его формулировку стоит читать рядом с тем, что профиль действительно требует.

Владение, путь и чем кормят помощник

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

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

Сбои очистки проявляются после исчезновения туннеля

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

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

Проверка помощника и сохранение выхода

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

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