Заранее созданный tun в OpenVPN: сравнение двух моделей владения

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

Имя — это не подключение

dev tun1 запрашивает у OpenVPN именно этот именованный интерфейс, и традиционные сборки в пользовательском пространстве попытаются его открыть. Если имя не следует обычному шаблону tun или tap, профилю нужен и соответствующий dev-type, потому что тип никогда не выводится из строки. Устройство TAP — это не устройство TUN с другой меткой: подключение не того либо сразу не удаётся, либо создаёт звено, несущее кадры, которых никто не ждёт. Проверьте тип прежде всего остального, поскольку каждая последующая проверка предполагает, что обе стороны с ним согласны. Затем убедитесь, что процесс действительно может открыть устройство, а не просто увидеть его.

dev tun1
dev-type tun

Сетевой интерфейс и /dev/net/tun — разные объекты: один является звеном внутри пространства имён, другой — символьным устройством, которое программа в пользовательском пространстве использует для подключения. Документация Linux TUN/TAP описывает этот путь подключения и правила владения постоянными устройствами. Root-оболочка, способная запустить ip link, доказывает лишь то, что у оболочки есть привилегии, а не то, что они есть у демона. Владение узлом устройства, набор возможностей службы и пользователь, от имени которого она работает — всё должно совпасть, прежде чем открытие удастся.

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

Кто настраивает звено: две модели владения

В первой модели OpenVPN настраивает адреса и маршруты в рамках поднятия соединения. Это поведение по умолчанию и самое простое для осмысления, потому что один компонент создаёт состояние и затем его удаляет. Во второй модели интерфейсом владеет внешний менеджер, а ifconfig-noexec не даёт OpenVPN выполнять его команды настройки адресов и передаёт параметры скриптам. Тогда менеджер должен сам применить правильную локальную конфигурацию и конфигурацию партнёра, что требует больше работы, чем подразумевает название опции. Выбор между ними — это вопрос о том, кто может менять звено, пока оно поднято.

ifconfig-noexec охватывает только адреса: таблица маршрутизации остаётся нетронутой, а настройка маршрутов относится к route-noexec. Рассматривайте две директивы как отдельные средства управления с отдельными владельцами, потому что установка одной и предположение другой — обычный источник наполовину настроенных звеньев. Выберите ровно одного владельца на слой, адреса в одном месте и маршруты в одном месте. Сетевой менеджер и помощник VPN, оба пишущие адреса, — вот как отключение стирает состояние, от которого другая сторона всё ещё зависит.

Осматривайте устройство из того пространства имён, которое важно

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

ip -details link show dev tun1
ip tuntap show

Первая команда печатает звено так, как его видит ядро, включая флаги и тип интерфейса, и именно так вы подтверждаете, что это то самое устройство. Вторая перечисляет постоянные записи tun/tap, которые существуют без того, чтобы их удерживал какой-либо процесс. Интерфейс, ожидающий назначенного владельца, — это другая ситуация, чем живой туннель, подключённый к другой VPN, и только вторая объясняет, почему ваше собственное подключение не удаётся. Найдите процесс, удерживающий устройство, прежде чем что-то менять, потому что у постоянной записи и занятого интерфейса разные решения.

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

Два вида постоянства

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

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

Что ломается, когда проверяют только запуск

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

systemctl status openvpn-client@lab
ip -details link show dev tun1

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

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

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