OpenVPN на VPS: немає пристрою /dev/net/tun, який можна відкрити

Перший запуск завершується помилкою з повідомленням про /dev/net/tun або пристрій TUN/TAP, який не вдається відкрити. Сертифікати ще не прочитано, тому в профілі немає винних. Демон просить у ядра об'єкт, якого цей гість не має.

Цей об'єкт — символьний пристрій, який надає модуль tun. Чи зможете ви його створити, залежить від того, кому належить ядро.

Що демон просить у ядра

OpenVPN відкриває /dev/net/tun і просить у драйвера інтерфейс. Драйвер — це модуль tun, а вузол пристрою — дескриптор, через який простір користувача звертається до нього. Якщо модуль не завантажено, вузол може бути відсутнім або відкриття може не вдатися. Жоден зі станів не виправляється редагуванням server.conf.

Спершу читайте цю помилку як питання про платформу. Помилка конфігурації з'являється після відкриття пристрою, а не до нього.

Віртуальна машина чи гість зі спільним ядром

На KVM, Xen або іншій повноцінній віртуальній машині ядро під вашим контролем. Ви можете завантажувати модулі й створювати вузол. На OpenVZ, Virtuozzo або в контейнері у стилі LXC гість ділить ядро хоста, тому root усередині не може завантажити модуль, який хост не завантажив.

Тож та сама помилка має двох геть різних власників. У першому випадку ви можете виправити її зсередини інстансу. У другому ви просите хост або провайдера щось відкрити.

Перш ніж вирішувати, який це випадок, виконайте ls -l /dev/net/tun, lsmod | grep tun і ip -brief link show.

На віртуальній машині завантажуйте модуль під час старту

На віртуальній машині modprobe tun зазвичай створює вузол пристрою. Переконайтеся, що він з'явився, а потім зробіть завантаження постійним через конфігурацію модулів дистрибутива, а не покладайтеся на команду, введену один раз. Вузол, який зникає після перезавантаження, наступного місяця стане тим самим тикетом.

Перевірте також, чи в завантаженому ядрі цей модуль узагалі є. Урізане ядро від вендора може його не містити.

Якщо вузол є, але відкриття досі не вдається, наступні підозрювані — права доступу та номери major/minor пристрою. Це локальні виправлення, а не запити до провайдера.

У контейнері пристрій належить хосту

У контейнері пристрій і можливість — дві окремі вимоги. Середовище виконання має пропустити /dev/net/tun, а контейнеру потрібна мережева можливість, щоб створити інтерфейс. Rootless-середовище, яке не дає ні того, ні іншого, видаватиме ту саму помилку відкриття, хоч би як було написано профіль. Багато хостів OpenVZ пропонують перемикач TUN/TAP у панелі клієнта, і його ввімкнення разом із перезапуском часто і є всім рішенням.

Поставте провайдеру два точні питання: чи завантажено модуль tun на хості й чи доступний пристрій усередині цього інстансу? Розпливчастий тикет отримує розпливчасту відповідь.

Чому перезбирання модуля рідко допомагає

Збирання модуля всередині гостя рідко допомагає. Компіляції потрібна конфігурація саме того ядра, що працює, а /proc/config.gz необов'язковий і часто відсутній на мінімальних образах. Навіть робочий модуль не можна вставити в ядро, яким контейнер не володіє.

Коли пристрій з'явиться, перезапустіть службу й підтвердіть інтерфейс, перш ніж перевіряти трафік. Вигляд tun0 показує, що демон відкрив пристрій. Про переспрямування, правила фаєрвола чи маршрути, які отримують клієнти, це поки нічого не каже.

Це окремі питання з окремими доказами. Відсутній пристрій — збій передумови; тунель, який існує, але нічого не переносить, — збій політики.