OpenVPN VPS-en: nincs /dev/net/tun eszköz megnyitásra

Az első indítás egy /dev/net/tun-ról vagy egy nem megnyitható TUN/TAP eszközről szóló üzenettel hiúsul meg. A tanúsítványokat még nem olvasta be, így semmi sem gyanús a profilban. A démon olyan objektumot kér a kerneltől, amellyel ez a vendég nem rendelkezik.

Ez az objektum a tun modul által támogatott karakteres eszköz. Hogy létre tudja-e hozni, attól függ, kié a kernel.

Mit kér a démon a kerneltől

OpenVPN megnyitja a /dev/net/tun eszközt, és interfészt kér az illesztőprogramtól. Az illesztőprogram a tun modul, az eszközcsomópont pedig az a fogantyú, amellyel a felhasználói tér eléri. Ha a modul nincs betöltve, a csomópont hiányozhat, vagy a megnyitás meghiúsulhat. Egyik állapotot sem javítja a server.conf szerkesztése.

A hibát először platformkérdésként olvassa. A konfigurációs hiba az eszköz megnyitása után jelenik meg, nem előtte.

VM vagy közös kernelű vendég

KVM-en, Xenen vagy más teljes virtuális gépen Ön irányítja a kernelt. Betölthet modulokat, és létrehozhatja a csomópontot. OpenVZ-n, Virtuozzón vagy LXC-stílusú konténerben a vendég megosztja a gazdagép kernelét, ezért a belsejében lévő root nem tölthet be olyan modult, amelyet a gazdagép nem töltött be.

Ugyanannak a hibának tehát két nagyon különböző tulajdonosa van. Az első esetben belülről javíthatja a példányon. A másodikban a gazdagéptől vagy a szolgáltatótól kér valaminek a megnyitását.

Mielőtt eldöntené, melyik esetben van, futtassa a ls -l /dev/net/tun, lsmod | grep tun és ip -brief link show parancsot.

VM-en töltse be a modult indításkor

Virtuális gépen a modprobe tun általában létrehozza az eszközcsomópontot. Ellenőrizze, hogy megjelenik-e, majd tegye tartóssá a betöltést a disztribúció modulkonfigurációján keresztül, ahelyett hogy egy egyszer beírt parancsra támaszkodna. Egy újraindítás után eltűnő csomópont a következő hónapban ugyanaz a jegy lesz.

Azt is ellenőrizze, hogy az indított kernel egyáltalán tartalmazza-e a modult. Egy lecsupaszított szállítói kernel hiányolhatja.

Ha a csomópont létezik, de a megnyitás továbbra is meghiúsul, a következő gyanúsítottak az engedélyek és az eszköz major/minor számai. Ezek helyi javítások, nem szolgáltatói kérések.

Konténerben az eszköz a gazdagépé

Konténerben az eszköz és a képesség két külön követelmény. A runtime-nak át kell engednie a /dev/net/tun eszközt, a konténernek pedig hálózati képességre van szüksége az interfész létrehozásához. Egy root nélküli runtime, amely egyiket sem adja, továbbra is ugyanazt a megnyitási hibát produkálja, bárhogy is írják a profilt. Sok OpenVZ-gazdagép TUN/TAP kapcsolót kínál az ügyfélpanelen, és ennek bekapcsolása plusz egy újraindítás gyakran a teljes megoldás.

Kérdezze meg a szolgáltatótól két pontos kérdést: be van-e töltve a tun modul a gazdagépen, és elérhető-e az eszköz ezen a példányon belül? A homályos jegy homályos választ kap.

Miért ritkán segít a modul újraépítése

A modul vendégen belüli építése ritkán segít. A fordításhoz a pontosan futó kernel konfigurációja kell, a /proc/config.gz pedig opcionális, és minimális lemezképeken gyakran hiányzik. Még egy működő modult sem lehet olyan kernelbe illeszteni, amely nem a konténeré.

Miután az eszköz megjelenik, indítsa újra a szolgáltatást, és ellenőrizze az interfészt a forgalom tesztelése előtt. A tun0 látványa azt mutatja, hogy a démon megnyitotta az eszközt. Ez még semmit sem mond a továbbításról, a tűzfal szabályairól vagy az ügyfelek által kapott útvonalakról.

Ezek külön kérdések külön bizonyítékokkal. A hiányzó eszköz előfeltételi hiba; az a tunel, amely létezik, de semmit sem szállít, szabályzati hiba.