Движок OpenVPN или Tunnelblick: кому принадлежит сеанс VPN на Mac?

Homebrew устанавливает программу OpenVPN; Tunnelblick устанавливает менеджер, который запускает один или несколько движков. Это разные уровни, и полезный вопрос не в том, нравится ли вам пользоваться терминалом. А в том, кому принадлежат конфигурация, изменения DNS, запрос учётных данных и очистка по окончании сеанса. Единый владелец этих уровней делает настройку предсказуемой.

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

Проверка первая: какой бинарный файл OpenVPN действительно работает

Выполните pgrep -fl openvpn, пока соединение активно, и прочитайте всю командную строку. Первый путь — это движок, который действительно работает. На Apple Silicon установка Homebrew обычно находится в /opt/homebrew, Mac на Intel используют /usr/local, а Tunnelblick запускает движок изнутри собственного пакета приложения.

Tunnelblick включает движки и позволяет конфигурации выбрать один из них. Обновление формулы Homebrew меняет отдельный бинарный файл, а не движок, который запускает профиль Tunnelblick. Если вы сравниваете версии, чтобы объяснить разницу в поведении, сравнивайте движок в списке процессов, а не тот, что в менеджере пакетов. Одна только строка версии не скажет, какой профиль загрузил этот движок.

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

Проверка вторая: кто меняет DNS и маршруты

Движок может выполнять собственные директивы up и down OpenVPN, но менеджер может владеть тем же жизненным циклом. Настройки сервера имён Tunnelblick управляют его стандартными скриптами подключения и отключения, и когда эта интеграция включена, конкурирующие директивы в профиле могут игнорироваться.

Это важно, потому что DNS — место, где работающий туннель чаще всего выглядит сломанным. Проверьте scutil --dns, пока соединение активно, отметьте, какой резолвер первый, и убедитесь, что он возвращается после отключения. Если профиль рассчитывает задать DNS сам, а менеджер тоже им управляет, один из двух проиграет.

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

Проверка третья: откуда берутся учётные данные

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

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

Проверка четвёртая: кто запускает, контролирует и останавливает процесс

Автономному развёртыванию нужен супервизор, если оно должно оставаться запущенным. Launchd может запускать движок при входе или по запросу, перезапускать после сбоя и аккуратно останавливать, но кто-то должен написать это задание и владеть им. Запуск команды в терминале подходит для теста и не подходит для пользователя, который закрывает окно.

Если Tunnelblick остаётся владельцем, используйте его поддерживаемые элементы управления вместо запуска второго движка. Бинарный файл Homebrew, получив скопированный профиль, открывает независимое соединение со своей конфигурацией и контекстом интеграции, а не командует существующим сеансом Tunnelblick.

Какого бы владельца вы ни выбрали, определите, что происходит при сне, смене сети и выходе из системы. Менеджер обычно обрабатывает эти события; голый процесс обычно нет, и возникший устаревший маршрут или резолвер легко принять за сбой сервера.

Проверка пятая: как проверяется передача

Проверьте нового владельца при отключённом старом, а затем снова проверьте старый, если планируете его оставить. Частный ресурс, который отвечает в одном сценарии и не отвечает в другом, — доказательство о недостающей интеграции, а не о сервере.

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

Для передачи Tunnelblick выберите движок для конфигурации, включите нужную интеграцию DNS и удалите директивы профиля, которые ей противоречат. Затем повторите те же три проверки. Соединение, которое работает, но оставляет резолвер изменённым, — это неудачная передача, даже если туннель поднялся.

Упаковка не решает совместимость с сервером. Проверьте собственные требования сервиса к клиенту и выбирайте движок отдельно только тогда, когда собираетесь обеспечить его управление.