OpenVPN op een VPS: geen /dev/net/tun-apparaat om te openen

De eerste start mislukt met een melding over /dev/net/tun of een TUN/TAP-apparaat dat niet kan worden geopend. De certificaten zijn nog niet gelezen, dus niets in het profiel is de schuld. De daemon vraagt de kernel om een object dat deze gast niet heeft.

Dat object is een tekenapparaat dat door de tun-module wordt ondersteund. Of je het kunt aanmaken hangt ervan af wie de kernel bezit.

Wat de daemon de kernel vraagt

OpenVPN opent /dev/net/tun en vraagt de driver om een interface. De driver is de tun-module en het apparaatknooppunt is het handvat waarmee de gebruikersruimte het bereikt. Als de module niet is geladen, kan het knooppunt ontbreken of kan het openen mislukken. Geen van beide toestanden wordt verholpen door server.conf te bewerken.

Lees de fout eerst als een vraag over het platform. Een configuratiefout verschijnt nadat het apparaat is geopend, niet ervoor.

VM of gast met gedeelde kernel

Op KVM, Xen of een andere volledige virtuele machine beheer je de kernel zelf. Je kunt modules laden en het knooppunt aanmaken. Op OpenVZ, Virtuozzo of een container in LXC-stijl deelt de gast de kernel van de host, dus root erbinnen kan geen module laden die de host niet heeft geladen.

Dezelfde fout heeft dus twee heel verschillende eigenaren. In het eerste geval kun je hem van binnenuit de instantie repareren. In het tweede vraag je de host, of de provider, iets bloot te leggen.

Voer ls -l /dev/net/tun, lsmod | grep tun en ip -brief link show uit voordat je bepaalt in welk geval je zit.

Op een VM de module bij het opstarten laden

Op een virtuele machine maakt modprobe tun meestal het apparaatknooppunt aan. Controleer of het verschijnt en maak het laden daarna permanent via de moduleconfiguratie van de distributie in plaats van te vertrouwen op een commando dat één keer is getypt. Een knooppunt dat na een herstart verdwijnt, wordt volgende maand dezelfde melding.

Controleer ook of de kernel die je hebt opgestart de module helemaal heeft. Een uitgedunde kernel van de leverancier kan hem missen.

Als het knooppunt bestaat maar het openen nog steeds mislukt, zijn machtigingen en de major/minor-nummers van het apparaat de volgende verdachten. Dat zijn lokale reparaties, geen verzoeken aan de provider.

In een container bezit de host het apparaat

In een container zijn het apparaat en de capability twee aparte vereisten. De runtime moet /dev/net/tun doorgeven, en de container heeft de netwerkmogelijkheid nodig om een interface te maken. Een rootless runtime die geen van beide geeft, blijft dezelfde openfout produceren hoe het profiel ook is geschreven. Veel OpenVZ-hosts bieden een TUN/TAP-schakelaar in het klantenpaneel, en die aanzetten plus een herstart is vaak de hele oplossing.

Stel de provider twee precieze vragen: is de tun-module op de host geladen, en is het apparaat binnen deze instantie beschikbaar? Een vage melding krijgt een vaag antwoord.

Waarom de module opnieuw bouwen zelden helpt

Een module in de gast bouwen helpt zelden. Compileren vereist de configuratie van precies de draaiende kernel, en /proc/config.gz is optioneel en ontbreekt vaak op minimale images. Zelfs een werkende module kan niet in een kernel worden ingevoegd die de container niet bezit.

Start de dienst opnieuw zodra het apparaat verschijnt en bevestig de interface voordat je verkeer test. tun0 zien toont dat de daemon het apparaat heeft geopend. Het zegt nog niets over doorsturen, firewallregels of de routes die clients krijgen.

Dat zijn aparte vragen met apart bewijs. Een ontbrekend apparaat is een voorwaardefout; een tunnel die bestaat maar niets vervoert is een beleidsfout.