OpenVPN auf einem VPS: kein Gerät /dev/net/tun zum Öffnen

Der erste Start scheitert mit einer Meldung über /dev/net/tun oder ein TUN/TAP-Gerät, das sich nicht öffnen lässt. Zertifikate wurden noch nicht gelesen, also ist nichts im Profil verdächtig. Der Daemon bittet den Kernel um ein Objekt, das dieser Gast nicht hat.

Dieses Objekt ist ein Zeichengerät, das vom tun-Modul bereitgestellt wird. Ob Sie es anlegen können, hängt davon ab, wem der Kernel gehört.

Was der Daemon vom Kernel verlangt

OpenVPN öffnet /dev/net/tun und bittet den Treiber um eine Schnittstelle. Der Treiber ist das tun-Modul, und der Geräteknoten ist das Handle, über das der Userspace es erreicht. Ist das Modul nicht geladen, kann der Knoten fehlen oder das Öffnen fehlschlagen. Keiner der beiden Zustände wird durch Bearbeiten von server.conf behoben.

Lesen Sie den Fehler zuerst als Plattformfrage. Ein Konfigurationsfehler erscheint, nachdem das Gerät geöffnet wurde, nicht davor.

VM oder Gast mit geteiltem Kernel

Auf KVM, Xen oder einer anderen vollständigen virtuellen Maschine kontrollieren Sie den Kernel. Sie können Module laden und den Knoten anlegen. Auf OpenVZ, Virtuozzo oder einem Container im LXC-Stil teilt sich der Gast den Kernel des Hosts, sodass root darin kein Modul laden kann, das der Host nicht geladen hat.

Derselbe Fehler hat daher zwei sehr verschiedene Verantwortliche. Im ersten Fall können Sie ihn innerhalb der Instanz beheben. Im zweiten bitten Sie den Host oder den Anbieter, etwas freizugeben.

Führen Sie ls -l /dev/net/tun, lsmod | grep tun und ip -brief link show aus, bevor Sie entscheiden, in welchem Fall Sie sich befinden.

Auf einer VM das Modul beim Booten laden

Auf einer virtuellen Maschine erzeugt modprobe tun normalerweise den Geräteknoten. Prüfen Sie, ob er erscheint, und machen Sie das Laden dann über die Modulkonfiguration der Distribution dauerhaft, statt sich auf einen einmal getippten Befehl zu verlassen. Ein Knoten, der nach einem Neustart verschwindet, wird nächsten Monat zum selben Ticket.

Prüfen Sie auch, ob der gestartete Kernel das Modul überhaupt enthält. Ein abgespeckter Anbieter-Kernel kann es entbehren.

Existiert der Knoten, schlägt das Öffnen aber weiterhin fehl, sind Berechtigungen und die Major-/Minor-Nummern des Geräts die nächsten Verdächtigen. Das sind lokale Korrekturen, keine Anfragen an den Anbieter.

Im Container gehört das Gerät dem Host

In einem Container sind Gerät und Fähigkeit zwei getrennte Anforderungen. Die Runtime muss /dev/net/tun durchreichen, und der Container braucht die Netzwerkfähigkeit, um eine Schnittstelle anzulegen. Eine rootlose Runtime, die beides nicht gewährt, erzeugt weiterhin denselben Öffnungsfehler, egal wie das Profil geschrieben ist. Viele OpenVZ-Hosts bieten im Kundenpanel einen TUN/TAP-Schalter an, und ihn zu aktivieren plus ein Neustart ist oft die ganze Lösung.

Stellen Sie dem Anbieter zwei präzise Fragen: Ist das tun-Modul auf dem Host geladen, und ist das Gerät innerhalb dieser Instanz verfügbar? Ein vages Ticket bekommt eine vage Antwort.

Warum das Neubauen des Moduls selten hilft

Ein Modul im Gast zu bauen hilft selten. Das Kompilieren braucht die Konfiguration des genau laufenden Kernels, und /proc/config.gz ist optional und fehlt auf minimalen Images oft. Selbst ein funktionierendes Modul lässt sich nicht in einen Kernel einfügen, der dem Container nicht gehört.

Nachdem das Gerät erscheint, starten Sie den Dienst neu und bestätigen Sie die Schnittstelle, bevor Sie Verkehr testen. tun0 zu sehen zeigt, dass der Daemon das Gerät geöffnet hat. Über Weiterleitung, Firewall-Regeln oder die Routen, die Clients erhalten, sagt das noch nichts.

Das sind getrennte Fragen mit getrennten Belegen. Ein fehlendes Gerät ist ein fehlgeschlagener Voraussetzungstest; ein Tunnel, der existiert, aber nichts transportiert, ist ein Politikfehler.