/dev/net/tun hiányzik, pedig a tun be van töltve: javítsd az eszközcsomópontot

OpenVPN leáll egy errno 2 panasszal a következőről: /dev/net/tun miközben lsmod gond nélkül listázza a tun modult. Mindkét tény egyszerre igaz. A modul illesztőprogramot ad, és az az útvonal, amelyet a kliens megnyit, egy eszközcsomópont, amelyet valami másnak kell létrehoznia. Ha ezeket egyetlen objektumnak tekintjük, az az oka annak, hogy a modul újratöltésének kézenfekvő javítása semmit sem változtat.

Két objektum, két különböző gazda

A kernelmodul és az eszközcsomópont független objektumok, független életciklusokkal. A modul betöltése regisztrál egy illesztőprogramot, és egy devtmpfs-szel rendelkező rendszeren a kernel kéri a megfelelő csomópont létrehozását. Devtmpfs nélküli rendszeren semmi sem hoz létre semmit, és az illesztőprogram ott ül egyetlen rá mutató útvonal nélkül. A modul ugyanabban a pillanatban lehet betöltött, egészséges és a fájlrendszeren keresztül teljesen elérhetetlen.

Ezért a hibaüzenet és a modullista nem mond ellent egymásnak. A kliens megnyit egy útvonalat, az útvonal nem létezik, és a kernel ENOENT-t ad vissza, mielőtt a tun illesztőprogramot egyáltalán megkérdeznék. A modul újratöltése nem tudja megjavítani a hiányzó útvonalat, és az útvonal létrehozása nem tudja megjavítani a hiányzó illesztőprogramot.

lsmod | grep -w tun
stat -c "%F %t:%T" /dev/net/tun
grep " /dev " /proc/mounts

devtmpfs szemben egy kifejezett mknod-dal

Ezt a csomópontot általában két mechanizmus hozza létre, és ha tudod, melyiknek kellene felelősnek lennie, megmondja, mit kell javítani. A devtmpfs a kernellel hozat létre eszközcsomópontokat egy felcsatolt példányban, a udev pedig tulajdonjogot és engedélyeket alkalmaz rájuk. Egy kifejezett mknod a kézi útvonal azokhoz a lemezképekhez és névterekhez, ahol egyik sem fut indításkor.

Az eredményeket hasonlítsd össze, ne a szándékokat. Ha a devtmpfs a /dev pontra van csatolva, és a csomópont mégis hiányzik, akkor az illesztőprogram nem az, amit feltételezsz, vagy valami eltávolította a csomópontot az indítás után. Ha a /dev egy egyszerű könyvtár egy kicsomagolt rootfs-ben, akkor nincs automatikus mechanizmus, és aki a lemezképet építi, annak létre kell hoznia a csomópontot.

stat -c "%F major=%t minor=%T" /dev/net/tun
# expect: character special file major=a minor=c8

Ahol egyik mechanizmus sem fut, a csomópontot kézzel kell elkészíteni, és a sorrend számít. Először hozd létre a szülőkönyvtárat, mert a mknod nem tudja kitalálni, aztán a karakteres eszközt, aztán egy olyan módot, amely csak a root számára hagyja írhatónak. Töltsd újra a modult, mielőtt létrehozod a csomópontot, és egy meglévő útvonalat csak azután távolíts el, hogy a ls megmutatta: könyvtár, nem eszköz.

sudo modprobe tun
sudo mkdir -p /dev/net
sudo mknod /dev/net/tun c 10 200
sudo chmod 600 /dev/net/tun
ls -l /dev/net/tun

A leggyorsabb megkülönböztető a stat által jelentett típus, és az az útvonalon lévő könyvtár a leggyakoribb meglepetés a minimális lemezképekben. Egy jó szándékú mkdir a Dockerfile-ban pontosan ezt hagyja hátra, és semmilyen mennyiségű modulbetöltés nem cserél egy könyvtárat karakteres eszközre. A Major 10 és a minor 200 a tun regisztrált párja, hexadecimálisan a és c8 formában kifejezve.

Négy nyom, négy ok

Négy ok magyarázza szinte az összes esetet, és mindegyik más nyomot hagy a naplókban. Kezdd az indítási környezettel. A lemez nélküli lemezképek, a beágyazott lapok és az initramfs szakaszok gyakran sem devtmpfs-t, sem udev által kezelt /devnem csatolnak, így egyetlen folyamat sem írja soha a csomópontot. Utána olvasd el a csatolási beállításokat azon, ami a /dev-t hosztolja, mert a nodev engedi, hogy az útvonal létezzen, miközben megtagadja a megnyitását, és a megerősített hosztról vett bind csatolás hordozza a jelzőt anélkül, hogy bejelentené magát. A csak olvasható csatolás korábban és hangosabban hibázik: a mknod ott EROFS-t ad vissza, míg az EPERM azt jelenti, hogy a folyamatnak nincs meg a képessége, nem azt, hogy a fájlrendszer védi magát. Végül egy saját /dev tmpfs-szel rendelkező konténer-runtime-nak a csomópontot a saját névterébe kell befecskendeznie, és az eszköz-cgroupjának engedélyeznie kell a major és minor párt.

A házirend-réteget nézd meg, mielőtt újra módosítod az engedélyeket. A SELinux és az AppArmor megtagadhat egy olyan megnyitást, amelyet minden fájljellemző engedélyez, és ez a megtagadás az auditnaplóban jelenik meg, nem a kliens kimenetében. Az az engedélymódosítás, amely soha nem jelenik meg megtagadásban, teljesen rossz rétegen eltöltött idő.

sudo journalctl -k -n 20 --no-pager
sudo ausearch -m AVC -ts recent | tail -5

Interfésszel bizonyítsd, ne listával

A sikeres lista azt bizonyítja, hogy létezik egy útvonal és semmi többet. Nyiss meg egy egészséges tun csomópontot olvasásra, és a hívás hibával tér vissza, mert az eszköznek nincs olvasási szemantikája, és nem szabályos fájl. Ez a hiba itt a siker jele, és ha felismered, nem fogod hibaként üldözni.

head -c 1 /dev/net/tun
head: error reading '/dev/net/tun': File descriptor in bad state

A döntő teszt interfészt hoz létre, mert egyetlen lépésben gyakorolja az illesztőprogramot, a csomópontot és a jogosultságaidat. Ha a hozzáadás sikerül és a kapcsolat megjelenik, mindhárom működik. Amikor elbukik, az errno szétválasztja az okokat: az ENOENT azt jelenti, hogy nincs használható csomópont, az EPERM a képességre, a csatolási jelzőkre vagy a házirendre mutat, az EBUSY pedig azt jelenti, hogy egy másik folyamat már birtokolja az interfészt.

sudo ip tuntap add dev tun7 mode tun
ip -brief link show tun7
sudo ip tuntap del dev tun7 mode tun

Futtasd ezt a tesztet abban a környezetben, amelyik valóban elbukik, mert egy szolgáltatásegység, egy konténer vagy egy ütemezett feladat más képességkészletet hordozhat, mint a bejelentkező shell. Az a teszt, amely rossz környezetben megy át, semmit sem bizonyít a bukó környezetről.

Amikor nem az eszköz a probléma

Ha az interfész-teszt sikerül, és a kliens mégis elbukik, a fennmaradó probléma a profil, a szolgáltatáskörnyezet vagy az útvonal, és az eszköz rendben van. Ez az a pillanat, amikor abba kell hagyni az eszközcsomópontok szerkesztését, mert a további változtatások csak növelik a távolságot egy működő rendszertől.

Minden alkalommal ugyanazt az öt ellenőrzést futtasd, ne találj ki újat: be van-e töltve a modul rivális modul nélkül, karakteres eszköz-e az útvonal a megfelelő major és minor értékkel, tiszták-e a csatolási beállítások, hordozza-e a folyamatkörnyezet a képességet, és van-e házirend-megtagadás a hiba időbélyegénél. Az a hiba, amely mind az ötöt túléli, nem eszközprobléma, bármit is említ az üzenet.