/dev/net/tun లేదు కానీ tun లోడ్ అయింది: పరికర నోడ్‌ను సరిచేయండి

OpenVPN errno 2 ఫిర్యాదుతో ఆగుతుంది, అది /dev/net/tun గురించి, అయితే lsmod tun మాడ్యూల్‌ను సులభంగా జాబితా చేస్తుంది. రెండు వాస్తవాలు ఒకే సమయంలో నిజం. మాడ్యూల్ డ్రైవర్‌ను అందిస్తుంది, క్లయింట్ తెరిచే మార్గం మరేదో సృష్టించాల్సిన పరికర నోడ్. రెండింటినీ ఒకే వస్తువుగా చూడటమే మాడ్యూల్‌ను తిరిగి లోడ్ చేసే స్పష్ట పరిష్కారం ఏమీ మార్చని కారణం.

రెండు వస్తువులు, రెండు వేర్వేరు యజమానులు

కర్నెల్ మాడ్యూల్ మరియు పరికర నోడ్ స్వతంత్ర జీవిత చక్రాలు ఉన్న స్వతంత్ర వస్తువులు. మాడ్యూల్ లోడ్ చేయడం డ్రైవర్‌ను నమోదు చేస్తుంది, devtmpfs ఉన్న వ్యవస్థలో కర్నెల్ సంబంధిత నోడ్‌ను సృష్టించమని కోరుతుంది. devtmpfs లేని వ్యవస్థలో ఏదీ ఏమీ సృష్టించదు, డ్రైవర్ దాని వైపు చూపే ఏ మార్గం లేకుండా అక్కడే కూర్చుంటుంది. మాడ్యూల్ ఒకే క్షణంలో లోడ్ అయి, ఆరోగ్యంగా, ఫైల్ సిస్టమ్ ద్వారా పూర్తిగా అందుబాటులో లేకుండా ఉండవచ్చు.

అందుకే లోపం వచనం మరియు మాడ్యూల్ జాబితా ఒకదానికొకటి విరుద్ధంగా లేవు. క్లయింట్ మార్గాన్ని తెరుస్తుంది, మార్గం లేదు, tun డ్రైవర్‌ను అడిగే ముందే కర్నెల్ ENOENT తిరిగి ఇస్తుంది. మాడ్యూల్‌ను తిరిగి లోడ్ చేయడం తప్పిపోయిన మార్గాన్ని సరిచేయలేదు, మార్గాన్ని సృష్టించడం తప్పిపోయిన డ్రైవర్‌ను సరిచేయలేదు.

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

devtmpfs మరియు స్పష్ట mknod

సాధారణంగా రెండు యంత్రాంగాలు ఆ నోడ్‌ను సృష్టిస్తాయి, ఏది బాధ్యత వహించాలో తెలిస్తే ఏమి సరిచేయాలో తెలుస్తుంది. devtmpfs కర్నెల్‌ను మౌంట్ చేసిన ఇన్‌స్టాన్స్‌లో పరికర నోడ్‌లను సృష్టించనిస్తుంది, udev వాటిపై యాజమాన్యం మరియు అనుమతులను వర్తింపజేస్తుంది. స్పష్టమైన mknod బూట్‌లో రెండూ నడవని ఇమేజ్‌లు మరియు నేమ్‌స్పేస్‌ల కోసం చేతితో చేసే మార్గం.

ఉద్దేశాలను కాదు, ఫలితాలను పోల్చండి. devtmpfs /dev పై మౌంట్ అయినా నోడ్ ఇంకా లేకపోతే, డ్రైవర్ మీరు ఊహించినది కాదు, లేదా ఏదో బూట్ తర్వాత నోడ్‌ను తొలగించింది. /dev తెరిచిన rootfs లోపల సాధారణ డైరెక్టరీ అయితే, స్వయంచాలక యంత్రాంగం లేదు, ఇమేజ్ నిర్మించేవారు నోడ్‌ను సృష్టించాలి.

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

రెండు యంత్రాంగాలు నడవని చోట, నోడ్‌ను చేతితో చేయాలి, క్రమం ముఖ్యం. మొదట పేరెంట్ డైరెక్టరీని సృష్టించండి, ఎందుకంటే mknod దానిని కల్పించలేదు, తర్వాత అక్షర పరికరం, తర్వాత root కు మాత్రమే రాయగలిగే మోడ్. నోడ్ సృష్టించే ముందు మాడ్యూల్‌ను తిరిగి లోడ్ చేయండి, ఉన్న మార్గాన్ని ls అది పరికరం కాదు, డైరెక్టరీ అని చూపిన తర్వాత మాత్రమే తొలగించండి.

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

అత్యంత వేగవంతమైన భేదకం stat నివేదించే రకం, ఆ మార్గంలో డైరెక్టరీ ఉండటం కనీస ఇమేజ్‌లలో అత్యంత సాధారణ ఆశ్చర్యం. మంచి ఉద్దేశంతో రాసిన mkdir Dockerfile లో అదే మిగిలిస్తుంది, ఎన్ని మాడ్యూల్‌లు లోడ్ చేసినా డైరెక్టరీని అక్షర పరికరంతో భర్తీ చేయలేము. Major 10 మరియు minor 200 tun కోసం నమోదైన జోడి, హెక్స్‌లో a మరియు c8 గా వ్యక్తీకరించబడుతుంది.

నాలుగు జాడలు, నాలుగు కారణాలు

నాలుగు కారణాలు దాదాపు ప్రతి సందర్భాన్ని వివరిస్తాయి, ప్రతి ఒక్కటి లాగ్‌లలో వేరే జాడను వదిలిస్తుంది. బూట్ వాతావరణంతో ప్రారంభించండి. డిస్క్ లేని ఇమేజ్‌లు, ఎంబెడెడ్ బోర్డులు మరియు initramfs దశలు తరచుగా devtmpfs లేదా udev నిర్వహించే /devమౌంట్ చేయవు, కాబట్టి ఏ ప్రక్రియా ఎప్పుడూ నోడ్‌ను రాయదు. తర్వాత /devహోస్ట్ చేసే దాని మౌంట్ ఎంపికలను చదవండి, ఎందుకంటే nodev మార్గం ఉండటానికి అనుమతిస్తుంది కానీ తెరవడానికి నిరాకరిస్తుంది, కఠినీకృత హోస్ట్ నుండి తీసుకున్న bind మౌంట్ తనను ప్రకటించుకోకుండా ఈ జెండాను మోస్తుంది. చదవడానికి-మాత్రమే మౌంట్ ముందుగానే మరియు గట్టిగా విఫలమవుతుంది: mknod అక్కడ EROFS తిరిగి ఇస్తుంది, EPERM అంటే ప్రక్రియకు సామర్థ్యం లేదు, ఫైల్ సిస్టమ్ తనను తాను కాపాడుకుంటోంది అని కాదు. చివరగా, తన సొంత /dev tmpfs ఉన్న కంటైనర్ రన్‌టైమ్ నోడ్‌ను తన స్వంత నేమ్‌స్పేస్‌లో ఇంజెక్ట్ చేయాలి, దాని పరికర cgroup major మరియు minor జోడిని అనుమతించాలి.

అనుమతులను మళ్లీ మార్చే ముందు విధాన పొరను తనిఖీ చేయండి. SELinux మరియు AppArmor ప్రతి ఫైల్ లక్షణం అనుమతించే తెరుపును నిరాకరించవచ్చు, ఆ నిరాకరణ క్లయింట్ అవుట్‌పుట్‌లో కాదు, ఆడిట్ లాగ్‌లో కనిపిస్తుంది. ఏ నిరాకరణలోనూ ఎప్పుడూ కనిపించని అనుమతి మార్పు పూర్తిగా తప్పు పొరపై గడిపిన సమయం.

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

జాబితాతో కాదు, ఇంటర్‌ఫేస్‌తో నిరూపించండి

విజయవంతమైన జాబితా ఒక మార్గం ఉందని నిరూపిస్తుంది అంతే. ఆరోగ్యకరమైన tun నోడ్‌ను చదవడానికి తెరవండి, పిలుపు లోపంతో తిరిగి వస్తుంది, ఎందుకంటే పరికరానికి చదవడపు అర్థం లేదు మరియు అది సాధారణ ఫైల్ కాదు. ఆ లోపమే ఇక్కడ విజయ సంకేతం, దానిని గుర్తించడం దానిని లోపంగా వెంబడించకుండా ఆపుతుంది.

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

నిర్ణాయక పరీక్ష ఒక ఇంటర్‌ఫేస్‌ను సృష్టిస్తుంది, ఎందుకంటే అది ఒకే అడుగులో డ్రైవర్, నోడ్ మరియు మీ ప్రత్యేకతలను పరీక్షిస్తుంది. జోడింపు విజయవంతమై లింక్ కనిపిస్తే మూడూ పని చేస్తాయి. అది విఫలమైనప్పుడు errno కారణాలను వేరు చేస్తుంది: ENOENT అంటే ఉపయోగించగల నోడ్ లేదు, EPERM సామర్థ్యం, మౌంట్ జెండాలు లేదా విధానాన్ని సూచిస్తుంది, EBUSY అంటే మరో ప్రక్రియ ఇప్పటికే ఇంటర్‌ఫేస్‌ను కలిగి ఉంది.

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

ఆ పరీక్షను నిజంగా విఫలమయ్యే సందర్భంలోనే నడపండి, ఎందుకంటే సేవా యూనిట్, కంటైనర్ లేదా షెడ్యూల్ చేసిన పని మీ లాగిన్ షెల్ కంటే వేరే సామర్థ్య సముదాయాన్ని కలిగి ఉండవచ్చు. తప్పు సందర్భంలో ఉత్తీర్ణమయ్యే పరీక్ష విఫలమయ్యే సందర్భం గురించి ఏమీ నిరూపించదు.

పరికరం సమస్య కానప్పుడు

ఇంటర్‌ఫేస్ పరీక్ష విజయవంతమైనా క్లయింట్ ఇంకా విఫలమైతే, మిగిలిన సమస్య ప్రొఫైల్, సేవా సందర్భం లేదా మార్గం, పరికరం బాగుంది. పరికర నోడ్‌లను సవరించడం ఆపాల్సిన క్షణం అదే, ఎందుకంటే మరిన్ని మార్పులు పని చేస్తున్న వ్యవస్థ నుండి దూరాన్ని మాత్రమే పెంచుతాయి.

ప్రతిసారీ కొత్తది కనిపెట్టకుండా అదే ఐదు తనిఖీలను నడపండి: మాడ్యూల్ పోటీ మాడ్యూల్ లేకుండా లోడ్ అయిందా, మార్గం సరైన major మరియు minor ఉన్న అక్షర పరికరమా, మౌంట్ ఎంపికలు శుభ్రంగా ఉన్నాయా, ప్రక్రియ సందర్భం సామర్థ్యాన్ని కలిగి ఉందా, మరియు వైఫల్యం సమయ ముద్రపై విధాన నిరాకరణ ఉందా. ఐదింటినీ దాటిన లోపం పరికర సమస్య కాదు, సందేశం ఏమి చెప్పినా.