OpenVPN na VPS: brak urządzenia /dev/net/tun do otwarcia

Pierwsze uruchomienie kończy się błędem z komunikatem o /dev/net/tun lub urządzeniu TUN/TAP, którego nie można otworzyć. Certyfikaty nie zostały jeszcze odczytane, więc nic w profilu nie jest winne. Demon prosi jądro o obiekt, którego ten gość nie ma.

Ten obiekt to urządzenie znakowe obsługiwane przez moduł tun. To, czy możesz je utworzyć, zależy od tego, kto jest właścicielem jądra.

O co demon prosi jądro

OpenVPN otwiera /dev/net/tun i prosi sterownik o interfejs. Sterownikiem jest moduł tun, a węzeł urządzenia to uchwyt, za pomocą którego przestrzeń użytkownika do niego dociera. Jeśli moduł nie jest załadowany, węzła może brakować albo otwarcie może się nie udać. Żadnego z tych stanów nie naprawia edycja server.conf.

Czytaj ten błąd najpierw jako pytanie o platformę. Błąd konfiguracji pojawia się po otwarciu urządzenia, a nie przed nim.

Maszyna wirtualna czy gość ze współdzielonym jądrem

Na KVM, Xen lub innej pełnej maszynie wirtualnej jądro kontrolujesz ty. Możesz ładować moduły i tworzyć węzeł. Na OpenVZ, Virtuozzo lub w kontenerze w stylu LXC gość dzieli jądro hosta, więc root w nim nie może załadować modułu, którego host nie załadował.

Ten sam błąd ma więc dwóch bardzo różnych właścicieli. W pierwszym przypadku możesz go naprawić od środka instancji. W drugim prosisz hosta lub dostawcę o wystawienie czegoś.

Uruchom ls -l /dev/net/tun, lsmod | grep tun i ip -brief link show, zanim zdecydujesz, w którym przypadku jesteś.

Na maszynie wirtualnej ładuj moduł podczas startu

Na maszynie wirtualnej modprobe tun zwykle tworzy węzeł urządzenia. Sprawdź, czy się pojawił, a następnie utrwal ładowanie przez konfigurację modułów dystrybucji, zamiast polegać na poleceniu wpisanym raz. Węzeł, który znika po restarcie, w przyszłym miesiącu staje się tym samym zgłoszeniem.

Sprawdź też, czy jądro, które uruchomiłeś, w ogóle ma ten moduł. Okrojone jądro dostawcy może go nie mieć.

Jeśli węzeł istnieje, ale otwarcie nadal się nie udaje, kolejnymi podejrzanymi są uprawnienia i numery major/minor urządzenia. To lokalne poprawki, a nie prośby do dostawcy.

W kontenerze urządzenie należy do hosta

W kontenerze urządzenie i uprawnienie to dwa osobne wymagania. Środowisko uruchomieniowe musi przepuścić /dev/net/tun, a kontener potrzebuje uprawnienia sieciowego, aby utworzyć interfejs. Środowisko rootless, które nie daje żadnego z nich, będzie nadal generować ten sam błąd otwarcia, niezależnie od tego, jak napisany jest profil. Wiele hostów OpenVZ udostępnia przełącznik TUN/TAP w panelu klienta, a jego włączenie wraz z restartem często jest całym rozwiązaniem.

Zadaj dostawcy dwa precyzyjne pytania: czy moduł tun jest załadowany na hoście i czy urządzenie jest dostępne wewnątrz tej instancji? Niejasne zgłoszenie dostaje niejasną odpowiedź.

Dlaczego przebudowa modułu rzadko pomaga

Budowanie modułu wewnątrz gościa rzadko pomaga. Kompilacja wymaga konfiguracji dokładnie działającego jądra, a /proc/config.gz jest opcjonalny i często go brakuje na minimalnych obrazach. Nawet działającego modułu nie można wstawić do jądra, do którego kontener nie należy.

Gdy urządzenie się pojawi, zrestartuj usługę i potwierdź interfejs, zanim przetestujesz ruch. Widok tun0 pokazuje, że demon otworzył urządzenie. Nie mówi jeszcze nic o przekazywaniu, regułach firewalla ani trasach, które otrzymują klienci.

To osobne pytania z osobnymi dowodami. Brakujące urządzenie to błąd warunku wstępnego; tunel, który istnieje, ale nic nie przenosi, to błąd polityki.