/dev/net/tun nawawala kahit naka-load ang tun: ayusin ang node ng device

OpenVPN ay humihinto na may reklamong errno 2 tungkol sa /dev/net/tun habang lsmod ay mahinahong naglilista ng module ng tun. Parehong totoo ang dalawang katotohanan sa parehong oras. Nagbibigay ang module ng driver, at ang landas na binubuksan ng kliyente ay isang node ng device na kailangang gawin ng ibang bagay. Ang pagtrato sa kanila bilang isang bagay lamang ang dahilan kung bakit ang halatang pag-aayos na muling pag-load ng module ay walang binabago.

Dalawang bagay, dalawang magkaibang may-ari

Ang module ng kernel at ang node ng device ay magkahiwalay na bagay na may magkahiwalay na siklo ng buhay. Ang pag-load ng module ay nagrerehistro ng driver, at sa sistemang may devtmpfs hinihiling ng kernel na gawin ang katumbas na node. Sa sistemang walang devtmpfs walang gumagawa ng anuman, at ang driver ay nakaupo doon na walang landas na tumuturo dito. Ang module ay maaaring naka-load, malusog at ganap na hindi maabot sa pamamagitan ng file system sa parehong sandali.

Kaya nga ang teksto ng error at ang listahan ng module ay hindi nagkakasalungatan. Binubuksan ng kliyente ang isang landas, wala ang landas, at ibinabalik ng kernel ang ENOENT bago pa man tanungin ang driver ng tun. Ang muling pag-load ng module ay hindi makakaayos ng nawawalang landas, at ang paggawa ng landas ay hindi makakaayos ng nawawalang driver.

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

devtmpfs laban sa tahasang mknod

Karaniwang dalawang mekanismo ang gumagawa ng node na iyon, at ang pag-alam kung alin ang dapat maging responsable ay nagsasabi kung ano ang aayusin. Hinihintulutan ng devtmpfs ang kernel na gumawa ng mga node ng device sa isang naka-mount na instance, at inilalapat ng udev ang pagmamay-ari at mga pahintulot sa ibabaw nila. Ang tahasang mknod ay ang manwal na landas para sa mga image at namespace kung saan wala sa dalawa ang tumatakbo sa boot.

Ikumpara ang mga resulta hindi ang mga intensyon. Kung naka-mount ang devtmpfs sa /dev at wala pa rin ang node, ang driver ay hindi ang inaakala mo, o may nagtanggal ng node pagkatapos ng boot. Kung ang /dev ay ordinaryong direktoryo sa loob ng nabuksang rootfs, walang awtomatikong mekanismo at ang gumagawa ng image ay dapat gumawa ng node.

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

Kung saan wala sa dalawang mekanismo ang tumatakbo, ang node ay dapat gawin sa kamay, at mahalaga ang pagkakasunod-sunod. Gawin muna ang parent directory, dahil mknod ay hindi ito maiimbento, pagkatapos ang character device, pagkatapos ang mode na nag-iiwan nitong maisusulat ng root lamang. I-load muli ang module bago gumawa ng node, at alisin lamang ang umiiral na landas pagkatapos na ls ay nagpakita na ito ay direktoryo at hindi device.

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

Ang pinakamabilis na diskriminante ay ang uri na iniuulat ng stat at ang direktoryo sa landas na iyon ang pinakakaraniwang sorpresa sa minimal na image. Ang mkdir na may mabuting layunin sa isang Dockerfile ay nag-iiwan ng eksaktong iyon, at walang dami ng pag-load ng module ang pumapalit sa direktoryo ng character device. Major 10 kasama ang minor 200 ang rehistradong pares para sa tun, na ipinapahayag sa hexadecimal bilang a at c8.

Apat na bakas, apat na dahilan

Apat na dahilan ang nagpapaliwanag sa halos lahat ng kaso, at bawat isa ay nag-iiwan ng ibang bakas sa mga log. Simulan sa kapaligiran ng boot. Ang mga image na walang disk, embedded na board at yugto ng initramfs ay madalas na hindi nag-mount ng devtmpfs o ng /devna pinamamahalaan ng udev, kaya walang proseso ang sumusulat ng node. Pagkatapos basahin ang mga opsyon sa pag-mount ng anumang nagho-host ng /dev, dahil ang nodev ay nagpapahintulot na umiral ang landas habang tumatanggi itong buksan ito, at ang bind mount na kinuha mula sa hardened na host ay nagdadala ng bandila nang hindi nagpapahayag. Ang read-only na mount ay nabigo nang mas maaga at mas malakas: mknod ay nagbabalik doon ng EROFS, samantalang ang EPERM ay nangangahulugang kulang ang proseso sa kakayahan at hindi na ipinagtatanggol ng file system ang sarili nito. Sa huli, ang container runtime na may sariling /dev tmpfs ay nangangailangan na ang node ay ma-inject sa sarili nitong namespace, at ang device cgroup nito ay dapat pahintulutan ang pares na major at minor.

Suriin ang layer ng patakaran bago muling baguhin ang mga pahintulot. Maaaring tanggihan ng SELinux at AppArmor ang pagbubukas na pinapayagan ng bawat attribute ng file, at ang pagtanggi ay lumilitaw sa audit log at hindi sa output ng kliyente. Ang pagbabago ng pahintulot na hindi kailanman lumilitaw sa isang pagtanggi ay panahong ginugol sa ganap na maling layer.

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

Patunayan ito gamit ang interface, hindi listahan

Ang matagumpay na listahan ay nagpapatunay na may landas at wala nang iba pa. Buksan ang malusog na node ng tun para sa pagbasa at ang tawag ay bumabalik na may error, dahil ang device ay walang semantika ng pagbasa at hindi ito ordinaryong file. Ang error na iyon ang senyales ng tagumpay dito, at ang pagkilala dito ay pumipigil sa iyo na habulin ito bilang depekto.

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

Ang pasya na pagsubok ay gumagawa ng interface, dahil sinasanay nito ang driver, node at mga pribilehiyo mo sa isang hakbang. Kung magtagumpay ang pagdaragdag at lumitaw ang link, gumagana ang tatlo. Kapag nabigo, hinihiwalay ng errno ang mga dahilan: ENOENT ay nangangahulugang walang magagamit na node, EPERM ay tumuturo sa kakayahan, bandila ng pag-mount o patakaran, at EBUSY ay nangangahulugang may ibang proseso nang nagmamay-ari ng interface.

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

Patakbuhin ang pagsubok na iyon sa kontekstong talagang nabigo, dahil ang service unit, container o naka-iskedyul na trabaho ay maaaring magdala ng ibang set ng kakayahan kaysa sa iyong login shell. Ang pagsubok na pumasa sa maling konteksto ay walang pinapatunayan tungkol sa nabibigo.

Kapag ang device ay hindi ang problema

Kung magtagumpay ang pagsubok ng interface at nabigo pa rin ang kliyente, ang natitirang problema ay ang profile, konteksto ng serbisyo o ruta, at maayos ang device. Iyon ang sandali upang itigil ang pag-edit ng mga node ng device, dahil ang karagdagang pagbabago ay nagdaragdag lamang ng distansya mula sa gumaganang sistema.

Patakbuhin ang parehong limang pagsusuri sa bawat pagkakataon sa halip na mag-imbento ng bago: naka-load ba ang module na walang karibal na module, character device ba ang landas na may tamang major at minor, malinis ba ang mga opsyon sa pag-mount, may kakayahan ba ang konteksto ng proseso, at may pagtanggi ba ng patakaran sa timestamp ng pagkasira. Ang depektong nakakalampas sa lima ay hindi problema ng device, anuman ang binanggit ng mensahe.