/dev/net/tun tiada walaupun tun dimuatkan: betulkan nod peranti

OpenVPN berhenti dengan aduan errno 2 tentang /dev/net/tun sementara lsmod menyenaraikan modul tun dengan tenang. Kedua-dua fakta benar pada masa yang sama. Modul menyediakan pemacu, dan laluan yang dibuka klien ialah nod peranti yang perlu dicipta oleh sesuatu yang lain. Menganggap kedua-duanya sebagai satu objek ialah sebab pembaikan jelas iaitu memuat semula modul tidak mengubah apa-apa.

Dua objek, dua pemilik berbeza

Modul kernel dan nod peranti ialah objek bebas dengan kitaran hayat bebas. Memuatkan modul mendaftarkan pemacu, dan pada sistem dengan devtmpfs kernel meminta nod yang sepadan dicipta. Pada sistem tanpa devtmpfs tiada apa mencipta apa-apa, dan pemacu duduk di situ tanpa sebarang laluan yang menunjuk kepadanya. Modul boleh dimuatkan, sihat dan sama sekali tidak dapat dicapai melalui sistem fail pada masa yang sama.

Itulah sebabnya teks ralat dan senarai modul tidak bercanggah. Klien membuka laluan, laluan itu tiada, dan kernel mengembalikan ENOENT sebelum pemacu tun pernah ditanya. Memuat semula modul tidak dapat membaiki laluan yang hilang, dan mencipta laluan tidak dapat membaiki pemacu yang hilang.

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

devtmpfs berbanding mknod eksplisit

Biasanya dua mekanisme mencipta nod itu, dan mengetahui yang mana sepatutnya bertanggungjawab memberitahu anda apa yang perlu dibaiki. devtmpfs membenarkan kernel mencipta nod peranti dalam instans yang dipasang, dan udev menggunakan pemilikan serta kebenaran di atasnya. Satu mknod eksplisit ialah laluan manual untuk imej dan ruang nama tempat kedua-duanya tidak berjalan semasa boot.

Bandingkan hasil, bukan niat. Jika devtmpfs dipasang pada /dev dan nod masih tiada, pemacu bukan yang anda andaikan, atau sesuatu telah membuang nod selepas boot. Jika /dev ialah direktori biasa di dalam rootfs yang diekstrak, tiada mekanisme automatik dan sesiapa yang membina imej mesti mencipta nod itu.

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

Di tempat tiada mekanisme berjalan, nod mesti dibuat dengan tangan, dan urutannya penting. Cipta direktori induk dahulu, kerana mknod tidak dapat menciptanya, kemudian peranti aksara, kemudian mod yang membiarkannya boleh ditulis oleh root sahaja. Muat semula modul sebelum anda mencipta nod, dan buang laluan sedia ada hanya selepas ls menunjukkan bahawa ia direktori dan bukan peranti.

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

Jenis yang dilaporkan oleh stat ialah pembeza terpantas, dan direktori pada laluan itu ialah kejutan paling biasa dalam imej minimum. Satu mkdir yang berniat baik dalam Dockerfile meninggalkan tepat itu, dan tiada jumlah pemuatan modul menggantikan direktori dengan peranti aksara. Major 10 dengan minor 200 ialah pasangan berdaftar untuk tun, dinyatakan dalam perenambelasan sebagai a dan c8.

Empat jejak, empat punca

Empat punca menjelaskan hampir setiap kes, dan setiap satu meninggalkan jejak berbeza dalam log. Mulakan dengan persekitaran boot. Imej tanpa cakera, papan terbenam dan peringkat initramfs sering tidak memasang devtmpfs mahupun /devyang diuruskan udev, jadi tiada proses pernah menulis nod itu. Kemudian baca pilihan pemasangan pada apa sahaja yang menghoskan /dev, kerana nodev membenarkan laluan itu wujud tetapi enggan membukanya, dan pemasangan bind yang diambil daripada hos yang dikeraskan membawa bendera itu tanpa mengumumkan dirinya. Pemasangan baca sahaja gagal lebih awal dan lebih lantang: mknod mengembalikan EROFS di situ, manakala EPERM bermaksud proses itu kekurangan keupayaan dan bukan bahawa sistem fail melindungi dirinya. Akhir sekali, runtime kontena dengan /dev tmpfs sendiri memerlukan nod itu disuntik ke dalam ruang namanya sendiri, dan cgroup perantinya mesti membenarkan pasangan major dan minor.

Periksa lapisan dasar sebelum menukar kebenaran lagi. SELinux dan AppArmor boleh menolak pembukaan yang dibenarkan oleh setiap atribut fail, dan penolakan itu muncul dalam log audit dan bukan dalam output klien. Perubahan kebenaran yang tidak pernah muncul dalam penolakan ialah masa yang dihabiskan pada lapisan yang sama sekali salah.

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

Buktikan dengan antara muka, bukan senarai

Senarai yang berjaya membuktikan bahawa sesuatu laluan wujud dan tidak lebih. Buka nod tun yang sihat untuk dibaca dan panggilan kembali dengan ralat, kerana peranti itu tiada semantik baca dan bukan fail biasa. Ralat itulah isyarat kejayaan di sini, dan mengenalinya menghalang anda daripada mengejarnya sebagai kerosakan.

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

Ujian penentu mencipta antara muka, kerana ia melatih pemacu, nod dan keistimewaan anda dalam satu langkah. Jika penambahan berjaya dan pautan muncul, ketiga-tiganya berfungsi. Apabila ia gagal, errno memisahkan puncanya: ENOENT bermaksud tiada nod yang boleh digunakan, EPERM menunjuk kepada keupayaan, bendera pemasangan atau dasar, dan EBUSY bermaksud proses lain sudah memiliki antara muka itu.

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

Jalankan ujian itu dalam konteks yang benar-benar gagal, kerana unit perkhidmatan, kontena atau tugas berjadual boleh membawa set keupayaan berbeza daripada shell log masuk anda. Ujian yang lulus dalam konteks yang salah tidak membuktikan apa-apa tentang yang gagal.

Apabila peranti bukan masalahnya

Jika ujian antara muka berjaya dan klien masih gagal, masalah yang tinggal ialah profil, konteks perkhidmatan atau laluan, dan peranti itu baik. Itulah saat untuk berhenti menyunting nod peranti, kerana perubahan selanjutnya hanya menambah jarak daripada sistem yang berfungsi.

Jalankan lima pemeriksaan yang sama setiap kali dan bukan mencipta yang baharu: adakah modul dimuatkan tanpa modul saingan, adakah laluan itu peranti aksara dengan major dan minor yang betul, adakah pilihan pemasangan bersih, adakah konteks proses membawa keupayaan itu, dan adakah terdapat penolakan dasar pada cap masa kegagalan. Kerosakan yang bertahan kelima-limanya bukan masalah peranti, apa pun yang disebut oleh mesej itu.