/dev/net/tun vantar þó tun sé hlaðið: lagaðu tækishnútinn

OpenVPN stöðvast með errno 2 kvörtun um /dev/net/tun á meðan lsmod telur tun-einingabókasafnið upp án vandræða. Báðar staðreyndir eru sannar á sama tíma. Bókasafnið veitir rekil, og slóðin sem biðlarinn opnar er tækishnútur sem eitthvað annað verður að búa til. Að meðhöndla þau sem einn hlut er ástæðan fyrir því að hið augljósa viðgerð — að hlaða bókasafninu aftur — breytir engu sem er.

Tveir hlutir, tveir mismunandi eigendur

Kjarnaeiningabókasafn og tækishnútur eru óháðir hlutir með óháðum lífsferlum. Að hlaða bókasafninu skráir rekil, og í kerfi með devtmpfs biður kjarninn um að samsvarandi hnútur sé búinn til. Í kerfi án devtmpfs býr ekkert neitt til, og rekillinn situr þar án nokkurrar slóðar sem bendir á hann. Bókasafnið getur verið hlaðið, heilbrigt og algjörlega óaðgengilegt gegnum skráarkerfið á sama augnabliki.

Þess vegna stangast villutextinn og bókasafnslistinn ekki á. Biðlarinn opnar slóð, slóðin er ekki til, og kjarninn skilar ENOENT áður en tun-rekillinn er nokkurn tíma spurður. Að hlaða bókasafninu aftur getur ekki lagað slóð sem vantar, og að búa til slóðina getur ekki lagað rekil sem vantar.

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

devtmpfs gegn skýrum mknod

Venjulega búa tveir ferlar til þann hnút, og að vita hvor ætti að bera ábyrgð segir þér hvað á að laga. devtmpfs lætur kjarnann búa til tækishnúta í uppsettu eintaki, og udev setur eignarhald og heimildir ofan á þá. Skýrt mknod er handvirk slóð fyrir skrár og nafnrými þar sem hvorugt keyrir við ræsingu.

Berðu saman útkomur frekar en áform. Ef devtmpfs er uppsett á /dev og hnúturinn er enn ekki til, er rekillinn ekki sá sem þú gerir ráð fyrir, eða eitthvað fjarlægði hnútinn eftir ræsingu. Ef /dev er venjuleg mappa inni í útpakkaðri rootfs, er enginn sjálfvirkur ferill til og sá sem byggir skrána verður að búa til hnútinn.

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

Þar sem hvorugur ferillinn keyrir verður hnúturinn að vera gerður í höndunum, og röðin skiptir máli. Búðu fyrst til yfirmöppuna, því mknod getur ekki fundið hana upp, svo stafatækið, svo ham sem leyfir aðeins root að skrifa í hann. Hladdu bókasafninu aftur áður en þú býrð til hnútinn, og fjarlægðu slóð sem er til aðeins eftir að ls hefur sýnt að það er mappa en ekki tæki.

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

Tegundin sem stat greinir frá er hraðasti greinirinn, og mappa á þeirri slóð er algengasta óvænta atriðið í minimálum skrám. Vel meinandi mkdir í Dockerfile skilur eftir sig einmitt það, og engin upphæð af bókasafnshleðslu kemur mappa í stað stafatækis. Major 10 með minor 200 er skráða parið fyrir tun, gefið í sextándu sem a og c8.

Fjögur spor, fjórar orsakir

Fjórar orsakir skýra næstum hvert tilvik, og hver þeirra skilur eftir sig annað spor í annálunum. Byrjaðu á ræsingarumhverfinu. Disklausar skrár, innbyggðar borð og initramfs-stig setja oft hvorki devtmpfs né /devsem udev stýrir, svo ekkert ferli skrifar nokkurn tíma hnútinn. Lestu síðan uppsetningarvalkostina á því sem hýsir /dev, því nodev leyfir slóðinni að vera til á meðan hún neitar að opna hana, og bind-uppsetning tekin af harðgerðum hýsi ber fánann án þess að tilkynna sig. Uppsetning aðeins fyrir lestur bregst fyrr og háværara: mknod skilar EROFS þar, á meðan EPERM þýðir að ferlið skortir getuna en ekki að skráarkerfið verji sig. Að lokum þarf gámaruntime með eigið /dev tmpfs að hnúturinn sé sprautaður inn í eigið nafnrými hans, og tækjacgroup hans verður að leyfa major og minor parið.

Athugaðu stefnulagið áður en þú breytir heimildum aftur. SELinux og AppArmor geta neitað opnun sem sérhver skráareiginleiki leyfir, og sú neitun birtist í endurskoðunarannálnum en ekki í úttaki biðlarans. Heimildabreyting sem birtist aldrei í neitun er tími sem varið er á alveg rangt lag.

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

Sannaðu það með tengi, ekki lista

Árangursríkur listi sannar að slóð er til og ekkert meira. Opnaðu heilbrigðan tun-hnút til lestrar og kallið kemur til baka með villu, því tækið hefur enga lestrarmerkingu og er ekki venjuleg skrá. Sú villa er árangursmerkið hér, og að þekkja hana kemur í veg fyrir að þú eltir hana sem bilun.

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

Ákvörðunarprófið býr til tengi, því það æfir rekilinn, hnútinn og réttindi þín í einu skrefi. Ef viðbótin tekst og hlekkurinn birtist vinna allir þrír. Þegar hún bregst aðskilur errno orsakirnar: ENOENT þýðir að enginn nothæfur hnútur er til, EPERM bendir á getu, uppsetningarfána eða stefnu, og EBUSY þýðir að annað ferli á tengið þegar.

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

Keyrðu það próf í því samhengi sem raunverulega bregst, því þjónustueining, gámur eða tímasett verk geta borið aðra getusamstæðu en innskráningarskelin þín. Próf sem gengur í röngu samhengi sannar ekkert um það sem bregst.

Þegar tækið er ekki vandamálið

Ef tengisprófið tekst og biðlarinn bregst samt, er vandamálið sem eftir er sniðið, þjónustusamhengið eða leiðin, og tækið er í lagi. Það er augnablikið til að hætta að breyta tækishnútum, því frekari breytingar bæta aðeins fjarlægð frá virku kerfi.

Keyrðu sömu fimm athuganir í hvert sinn í stað þess að finna upp nýja: er bókasafnið hlaðið án keppinautar, er slóðin stafatæki með réttu major og minor, eru uppsetningarvalkostirnir hreinir, ber ferlisamhengið getuna, og er stefnuneitun á tímasetningu bilunarinnar. Bilun sem lifir allar fimm er ekki tækivandamál, hvað sem skilaboðin nefna.