/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 ഉള്ള പ്രതീക ഉപകരണമാണോ, മൗണ്ട് ഓപ്ഷനുകൾ ശുദ്ധമാണോ, പ്രോസസ്സ് സന്ദർഭം കഴിവ് വഹിക്കുന്നുണ്ടോ, പരാജയ സമയമുദ്രയിൽ നയ നിരസിക്കൽ ഉണ്ടോ. അഞ്ചും കടന്ന് നിൽക്കുന്ന തകരാർ ഉപകരണത്തിന്റെ പ്രശ്നമല്ല, സന്ദേശം എന്ത് പറഞ്ഞാലും.