/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 સાથે કેરેક્ટર ઉપકરણ છે કે નહીં, માઉન્ટ વિકલ્પો સ્વચ્છ છે કે નહીં, પ્રક્રિયા સંદર્ભ ક્ષમતા ધરાવે છે કે નહીં, અને નિષ્ફળતાના સમયગાળા પર નીતિ નકાર છે કે નહીં. પાંચેયમાંથી પસાર થતી ખામી ઉપકરણની સમસ્યા નથી, સંદેશ શું કહે તે ગમે તે.