OpenVPN на VPS: няма устройство /dev/net/tun за отваряне

Първото стартиране се проваля със съобщение за /dev/net/tun или TUN/TAP устройство, което не може да бъде отворено. Сертификатите още не са прочетени, така че нищо в профила не е заподозряно. Демонът иска от ядрото обект, който този гост няма.

Този обект е символно устройство, поддържано от модула tun. Дали можете да го създадете, зависи от това кой притежава ядрото.

Какво иска демонът от ядрото

OpenVPN отваря /dev/net/tun и иска от драйвера интерфейс. Драйверът е модулът tun, а възелът на устройството е дръжката, чрез която потребителското пространство го достига. Ако модулът не е зареден, възелът може да липсва или отварянето да се провали. Нито едно от двете условия не се поправя с редактиране на server.conf.

Прочетете грешката първо като въпрос за платформата. Грешка в конфигурацията се появява след отварянето на устройството, не преди.

VM или гост с общо ядро

На KVM, Xen или друга пълна виртуална машина вие контролирате ядрото. Можете да зареждате модули и да създадете възела. На OpenVZ, Virtuozzo или контейнер в стил LXC гостът споделя ядрото на хоста, така че root вътре не може да зареди модул, който хостът не е заредил.

Затова един и същ провал има два много различни собственика. В първия случай можете да го поправите отвътре в инстанцията. Във втория искате от хоста или от доставчика да изложи нещо.

Изпълнете ls -l /dev/net/tun, lsmod | grep tun и ip -brief link show, преди да решите в кой случай сте.

На VM зареждайте модула при стартиране

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

Проверете също дали ядрото, което сте стартирали, изобщо разполага с модула. Орязано ядро от доставчик може да го няма.

Ако възелът съществува, но отварянето все още се проваля, следващите заподозрени са правата и номерата major/minor на устройството. Това са локални поправки, не заявки към доставчика.

В контейнер хостът притежава устройството

В контейнер устройството и способността са две отделни изисквания. Runtime трябва да пропусне /dev/net/tun, а контейнерът се нуждае от мрежовата способност, за да създаде интерфейс. Rootless runtime, който не дава нито едното, ще продължи да произвежда същата грешка при отваряне, както и да е написан профилът. Много OpenVZ хостове показват превключвател TUN/TAP в клиентския панел и включването му плюс рестарт често е цялото решение.

Попитайте доставчика два точни въпроса: зареден ли е модулът tun на хоста и достъпно ли е устройството вътре в тази инстанция? Неясен тикет получава неясен отговор.

Защо прекомпилирането на модула рядко помага

Изграждането на модул вътре в госта рядко помага. Компилирането изисква конфигурацията на точно работещото ядро, а /proc/config.gz е незадължителен и често липсва на минимални образи. Дори работещ модул не може да бъде вмъкнат в ядро, което контейнерът не притежава.

След като устройството се появи, рестартирайте услугата и потвърдете интерфейса, преди да тествате трафик. Виждането на tun0 показва, че демонът е отворил устройството. Това все още не казва нищо за препращането, правилата на firewall или маршрутите, които клиентите получават.

Това са отделни въпроси с отделни доказателства. Липсващото устройство е неизпълнено предварително условие; тунел, който съществува, но не носи нищо, е провал на политиката.