OpenVPN op 'n VPS: geen /dev/net/tun-toestel om oop te maak nie

Die eerste begin misluk met 'n boodskap oor /dev/net/tun of 'n TUN/TAP-toestel wat nie oopgemaak kan word nie. Sertifikate is nog nie gelees nie, dus is niks in die profiel ter sprake nie. Die daemon vra die kern om 'n objek wat hierdie gas nie het nie.

Daardie objek is 'n karaktertoestel wat deur die tun-module gerugsteun word. Of jy dit kan skep, hang daarvan af wie die kern besit.

Wat die daemon by die kern aanvra

OpenVPN maak /dev/net/tun oop en vra die drywer om 'n koppelvlak. Die drywer is die tun-module, en die toestelknoop is die handvatsel wat gebruikersruimte gebruik om dit te bereik. As die module nie gelaai is nie, kan die knoop ontbreek of die oopmaak kan misluk. Nie een van dié toestande word deur die wysiging van server.conf reggemaak nie.

Lees die fout eerste as 'n platformvraag. 'n Konfigurasiefout verskyn nadat die toestel oopgemaak is, nie voor dit nie.

VM of gas met gedeelde kern

Op KVM, Xen of 'n ander volle virtuele masjien beheer jy die kern. Jy kan modules laai en die knoop skep. Op OpenVZ, Virtuozzo of 'n LXC-tipe houer deel die gas die gasheerkern, so root daarbinne kan nie 'n module laai wat die gasheer nie gelaai het nie.

Dieselfde mislukking het dus twee baie verskillende eienaars. In die eerste geval kan jy dit van binne die instansie regmaak. In die tweede vra jy die gasheer, of die verskaffer, om iets bloot te stel.

Voer ls -l /dev/net/tun, lsmod | grep tun en ip -brief link show uit voordat jy besluit in watter geval jy is.

Op 'n VM, laai die module by die opstart

Op 'n virtuele masjien skep modprobe tun gewoonlik die toestelknoop. Kyk of dit verskyn en maak die lading dan blywend deur die verspreiding se modules-konfigurasie eerder as om op 'n opdrag te vertrou wat een keer getik is. 'n Knoop wat na 'n herbegin verdwyn, word volgende maand dieselfde kaartjie.

Kyk ook of die kern wat jy geboot het die module hoegenaamd het. 'n Afgeslankte verskafferkern kan dit ontbeer.

As die knoop bestaan maar die oopmaak steeds misluk, is regte en die toestel se major/minor-getalle die volgende verdagtes. Dit is plaaslike regstellings, nie versoeke aan die verskaffer nie.

In 'n houer besit die gasheer die toestel

In 'n houer is die toestel en die vermoë twee afsonderlike vereistes. Die runtime moet /dev/net/tun deurgee, en die houer het die netwerkvermoë nodig om 'n koppelvlak te skep. 'n Rootlose runtime wat nie een van die twee gee nie, sal dieselfde oopmaakfout bly lewer maak nie saak hoe die profiel geskryf is nie. Baie OpenVZ-gashere bied 'n TUN/TAP-skakelaar in die klantepaneel, en om dit te aktiveer plus 'n herbegin is dikwels die hele oplossing.

Vra die verskaffer twee presiese vrae: is die tun-module op die gasheer gelaai, en is die toestel binne hierdie instansie beskikbaar? 'n Vae kaartjie kry 'n vae antwoord.

Waarom die herbou van die module selde help

'n Module binne die gas bou help selde. Samestelling benodig die konfigurasie van die presiese lopende kern, en /proc/config.gz is opsioneel en dikwels afwesig op minimale beelde. Selfs 'n werkende module kan nie in 'n kern ingevoeg word wat die houer nie besit nie.

Nadat die toestel verskyn het, herbegin die diens en bevestig die koppelvlak voordat jy verkeer toets. Om tun0 te sien wys dat die daemon die toestel oopgemaak het. Dit sê nog niks oor aanstuur, firewall-reëls of die roetes wat kliënte ontvang nie.

Dit is afsonderlike vrae met afsonderlike bewyse. 'n Ontbrekende toestel is 'n voorvereiste-mislukking; 'n tonnel wat bestaan maar niks dra nie, is 'n beleidsmislukking.