Заздалегідь створений 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. Повна зупинка — це місце, де зовнішній менеджер себе викриває: якщо ланка або її адреси переживають зупинку, ними володіє хтось інший, і це або стан, який ви задокументували, або помилка, яку ви щойно знайшли. Запишіть обидва спостереження поруч із профілем, щоб наступна зміна починалася з доказів, а не з діаграми.