LXD കണ്ടെയ്നറിന് /dev/net/tun തുറക്കാനാകുന്നില്ലേ? unix-char എൻട്രി പരിശോധിക്കുക

LXD ഉപകരണ നോഡ് ചേർത്താണ് ഹോസ്റ്റിന്റെ പ്രതീക ഉപകരണം കണ്ടെയ്നറിന് നൽകുന്നത്, അതിനെ സൃഷ്ടിക്കാൻ അതിഥിയെ പഠിപ്പിച്ചല്ല. കണ്ടെയ്നറിൽ /dev/net/tun ഇല്ലെങ്കിൽ, ഉപകരണം ഹോസ്റ്റിൽ ഉണ്ടാകാം, എന്നിട്ടും അതിഥിക്ക് അത് തുറക്കാൻ കഴിയണമെന്നില്ല. unix-char എൻട്രി ആ വഴിയുടെ മാനേജർ ഭാഗത്തെ പകുതിയാണ്, അത് സവിശേഷാധികാര കണ്ടെയ്നറിനെക്കാൾ ബോധപൂർവം ഇടുങ്ങിയതാണ്. അതുകൊണ്ടാണ് ഹോസ്റ്റ് നോഡും കണ്ടെയ്നർ നോഡും വെവ്വേറെ പരിശോധനകൾ അർഹിക്കുന്നത്.

സംവിധാനം കണ്ണിൽ നിർത്താൻ മതിയാകും വിധം ചെറുതാണ്: LXD ഹോസ്റ്റ് പാത്ത് പരിഹരിക്കുന്നു, ഇൻസ്റ്റൻസിനുള്ളിൽ യോജിക്കുന്ന നോഡ് സൃഷ്ടിക്കുന്നു, ഉപകരണത്തെ കണ്ടെയ്നറിന്റെ ഉപകരണ cgroup-ലേക്ക് ചേർക്കുന്നു. പിന്നീട് അതിഥി പ്രോസസ്സിന് നോഡ് എന്തിനെങ്കിലും ഉപയോഗിക്കാൻ സ്വന്തം അനുമതിയും കഴിവും വേണം.

unix-char എൻട്രി യഥാർത്ഥത്തിൽ മാറ്റുന്നത്

unix-char ഉപകരണം LXD-യോട് ഹോസ്റ്റിന്റെ ഒരു പ്രതീക ഉപകരണം കണ്ടെയ്നറിനുള്ളിൽ തിരഞ്ഞെടുത്ത പാത്തിൽ നൽകാൻ പറയുന്നു. എൻട്രിക്ക് മൂന്ന് പ്രധാന ഭാഗങ്ങളുണ്ട്: മാനേജർ ഉപയോഗിക്കുന്ന ഉപകരണ ലേബൽ, ഹോസ്റ്റിലെ source പാത്ത്, അതിഥി കാണുന്ന path. അവസാന രണ്ടെണ്ണം മാത്രമാണ് ഉപകരണത്തെ തന്നെ വിവരിക്കുന്നത്. അവയിലൊന്നിൽ ടൈപ്പിംഗ് പിശക് വന്നാൽ ക്ലയന്റ് ഒരിക്കലും തുറക്കാത്ത സ്ഥലത്ത് നോഡ് ഉണ്ടാകും.

ഹോസ്റ്റിൽ ഉപകരണം സാധാരണയായി /dev/net/tun ആണ്. കണ്ടെയ്നറിനുള്ളിൽ നിങ്ങൾക്ക് അതേ പാത്ത് നിലനിർത്താം അല്ലെങ്കിൽ മറ്റൊന്ന് തിരഞ്ഞെടുക്കാം, പക്ഷേ പാത്ത് VPN ക്ലയന്റ് പ്രതീക്ഷിക്കുന്നതുമായി യോജിക്കണം. /dev/net/tun നിലനിർത്തുന്നത് രണ്ടാമത്തെ കോൺഫിഗറേഷൻ പ്രശ്നം ഒഴിവാക്കുന്നു, കാരണം മിക്ക ക്ലയന്റുകളും ആ പാത്ത് ചോദിക്കാതെ തുറക്കുന്നു.

ഇൻസ്റ്റൻസ് തുടങ്ങുമ്പോഴോ ഉപകരണം ഹോട്ട്പ്ലഗ് ചെയ്യുമ്പോഴോ മാനേജർ എൻട്രി പ്രയോഗിക്കുന്നു. അത് അതിഥിയിലേക്ക് ഡ്രൈവർ പകർത്തുന്നില്ല, ടണൽ ഇന്റർഫേസ് സൃഷ്ടിക്കുന്നുമില്ല. നോഡ് ദൃശ്യമാക്കി കണ്ടെയ്നറിന്റെ ഉപകരണ നിയന്ത്രണ ഗ്രൂപ്പ് വഴി പ്രവേശനം അനുവദിക്കുന്നു.

ഉപകരണം അതിഥിക്കുള്ളിൽ അല്ല, ഇൻസ്റ്റൻസിൽ പ്രഖ്യാപിക്കുക

LXD അഡ്മിനിസ്ട്രേഷൻ സന്ദർഭത്തിൽ നിന്ന് എൻട്രി ചേർക്കുക, ഇൻസ്റ്റൻസും പിന്നീട് തിരിച്ചറിയാവുന്ന ലേബലും പറയുക. vpnbox എന്ന കണ്ടെയ്നറിന് കമാൻഡ് ഇതാണ്:

lxc config device add vpnbox tun unix-char source=/dev/net/tun path=/dev/net/tun
lxc config device show vpnbox

ലേബൽ tun ഇൻസ്റ്റൻസ് കോൺഫിഗറേഷനിൽ മാത്രമുള്ളതാണ്. അത് ഇന്റർഫേസ് പേരല്ല, അതിഥിയിലെ ഒന്നുമായി യോജിക്കേണ്ടതുമില്ല. ഒരു പ്രൊഫൈൽ ഇതേ ഉപകരണം ഇതിനകം നൽകുന്നുണ്ടെങ്കിൽ, രണ്ടാമത്തെ എൻട്രി ആവർത്തനമല്ല, മറിച്ച് സംഘർഷം സൃഷ്ടിക്കുന്നു, അതിനാൽ ആദ്യം ഫലപ്രദമായ കോൺഫിഗറേഷൻ പരിശോധിക്കുക.

കണ്ടെയ്നറിനുള്ളിൽ ഫയലുകൾ തിരുത്തുന്നത് തെറ്റായ പാളിയാണ്. സ്റ്റാർട്ടപ്പ് സ്ക്രിപ്റ്റിലെ mknod സവിശേഷാധികാര കണ്ടെയ്നറിൽ പ്രവർത്തിക്കുന്നതായി തോന്നിയേക്കാം, പിന്നീട് പുനഃസൃഷ്ടിയിൽ അപ്രത്യക്ഷമാകാം അല്ലെങ്കിൽ കുറഞ്ഞ അധികാരമുള്ളതിൽ പരാജയപ്പെടാം. ഇൻസ്റ്റൻസിന്റെ ഉപകരണ കൂട്ടത്തിന്റെ ഉടമ മാനേജരാണ്; നോഡിന്റെ ഉടമയും അവനായിരിക്കട്ടെ.

ഉടമസ്ഥതയും മോഡും അതിഥി പ്രോസസ്സുമായി യോജിപ്പിക്കുക

unix-char എൻട്രിക്ക് കണ്ടെയ്നറിനുള്ളിലെ നോഡിന് uid, gid, mode സജ്ജമാക്കാം. എല്ലാ ഉപയോക്താക്കൾക്കും ഉപകരണം തുറക്കുന്നതിനോ കണ്ടെയ്നർ സവിശേഷാധികാര മോഡിലേക്ക് മാറ്റുന്നതിനോ പകരം, VPN ക്ലയന്റ് പ്രവർത്തിപ്പിക്കുന്ന അക്കൗണ്ടുമായി യോജിപ്പിക്കാൻ അവ ഉപയോഗിക്കുക.

ദൃശ്യത അനുമതിയുടെ അതേ കാര്യമല്ല. root ഉടമസ്ഥതയിലുള്ളതും മോഡ് 600 ഉള്ളതുമായ നോഡ് അനധികൃത ഉപയോക്താവായി പ്രവർത്തിക്കുന്ന സേവനത്തിന് ദൃശ്യമാണ്, എന്നിട്ടും അതിന് അത് തുറക്കാനാകില്ല. ആദ്യം അതിഥി അക്കൗണ്ട് പരിശോധിക്കുക, പിന്നീട് ഉടമസ്ഥത ആ അക്കൗണ്ടിന് നൽകുക, മോഡ് ക്ലയന്റിന് ആവശ്യമുള്ളതിൽ കൂടുതൽ വീതിയിൽ വയ്ക്കരുത്.

പ്രോസസ്സിന് ടണൽ ഇന്റർഫേസ് കോൺഫിഗർ ചെയ്യാനുള്ള കഴിവ് കൂടി വേണം, സാധാരണയായി കണ്ടെയ്നറിന്റെ നെറ്റ്വർക്ക് നാമസ്ഥലത്ത് CAP_NET_ADMIN. ഉപകരണം നൽകുന്നത് ആ കഴിവ് നൽകുന്നില്ല, കഴിവ് നൽകുന്നത് ഉപകരണം നൽകുന്നുമില്ല; ഇവ സ്വതന്ത്ര ആവശ്യകതകളാണ്.

എൻട്രി എന്ത് നൽകുന്നില്ല എന്ന് അറിയുക

ദൃശ്യമായ നോഡ് പ്രവർത്തിക്കുന്ന VPN അല്ല. ക്ലയന്റ് പാക്കേജ് ഇപ്പോഴും ഇൻസ്റ്റാൾ ചെയ്യണം, പ്രൊഫൈൽ ഇപ്പോഴും സാധുവായിരിക്കണം, സേവനം ഇപ്പോഴും ആരംഭിക്കണം. പ്രാമാണീകരണം, റൂട്ടുകൾ, DNS എന്നിവ ക്ലയന്റിന്റെ ജോലിയായി തുടരുന്നു, അവിടത്തെ പരാജയം ഉപകരണ എൻട്രി തെറ്റാണെന്ന തെളിവല്ല.

systemd മറ്റൊരു നിയന്ത്രണം കൂട്ടിച്ചേർക്കാം. DeviceAllow ഉള്ളതോ കഠിനമാക്കിയ ഉപകരണ നയമുള്ളതോ ആയ യൂണിറ്റിന് കണ്ടെയ്നർ മാനേജർ നൽകിയ നോഡിലേക്കുള്ള പ്രവേശനം നിഷേധിക്കാം. നോഡ് ഉണ്ടായിരിക്കെ സേവനം അനുമതി പിശക് റിപ്പോർട്ട് ചെയ്യുമ്പോൾ യൂണിറ്റിന്റെ ഉപകരണ നയം പരിശോധിക്കുക, കണ്ടെയ്നർ വിശാലമാക്കുന്നതിന് പകരം ആ നയം മാറ്റുക.

ഹോട്ട്പ്ലഗ് ഓപ്ഷണലും വ്യക്തവുമാണ്. required=false ഉള്ള എൻട്രിക്ക് ഉറവിട പാത്ത് വേണം, ഹോസ്റ്റ് ഉപകരണം മാറുമ്പോൾ അത് പ്രത്യക്ഷപ്പെടാം അല്ലെങ്കിൽ അപ്രത്യക്ഷമാകാം. അത്തരം ജീവിതചക്രം വന്നുപോകുന്ന ഹാർഡ്വെയറിന് യോജിക്കുന്നു; VPN ബൂട്ടിൽ ആവശ്യമുള്ള TUN ഉപകരണത്തിന്, ഓപ്ഷണൽ എൻട്രി അതിന്റെ മുൻവ്യവസ്ഥ ഉണ്ടാകുന്നതിന് മുമ്പ് സേവനം തുടങ്ങാൻ അനുവദിച്ചേക്കാം.

ദൃശ്യത, തുറക്കൽ, ഇന്റർഫേസ് എന്ന ക്രമത്തിൽ പരിശോധിക്കുക

ആദ്യം ഉദ്ദേശിച്ച കണ്ടെയ്നറിനുള്ളിലെ നോഡ് സ്ഥിരീകരിക്കുക. പാത്ത്, പ്രധാന, ചെറിയ നമ്പറുകൾ, ഉടമസ്ഥത എന്നിവ ഹോസ്റ്റ് ഉപകരണവുമായും നിങ്ങൾ ചേർത്ത എൻട്രിയുമായും യോജിക്കണം. നോഡ് ഇല്ലെങ്കിൽ മാനേജർ എൻട്രി പ്രയോഗിച്ചിട്ടില്ല, അല്ലെങ്കിൽ മറ്റൊരു ഇൻസ്റ്റൻസിൽ പ്രയോഗിച്ചു.

lxc exec vpnbox -- ls -l /dev/net/tun
lxc exec vpnbox -- sh -c 'test -c /dev/net/tun && echo char-device-ok'

പിന്നീട് സേവന അക്കൗണ്ടിന് അത് തുറക്കാമെന്ന് സ്ഥിരീകരിക്കുക. ആ അക്കൗണ്ടായി നടത്തുന്ന ചെറിയ പരീക്ഷ ഉടമസ്ഥതാ പ്രശ്നത്തെ സേവന പ്രശ്നത്തിൽ നിന്ന് വേർതിരിക്കുന്നു. അവസാനം ക്ലയന്റ് തുടങ്ങി ടണൽ ഇന്റർഫേസ് പ്രത്യക്ഷപ്പെടുന്നുവെന്ന് സ്ഥിരീകരിക്കുക; ആദ്യ രണ്ടെണ്ണം വിജയിച്ചാലും ക്ലയന്റ് പ്രൊഫൈലോ കഴിവോ ഇപ്പോഴും തെറ്റായിരിക്കാം എന്നതിനാൽ, മുഴുവൻ വഴിയും തെളിയിക്കുന്നത് ആ മൂന്നാം ഘട്ടം മാത്രമാണ്.

മാറ്റം അംഗീകരിക്കുമ്പോൾ ഇൻസ്റ്റൻസ്, ഉപകരണ ലേബൽ, ഹോസ്റ്റ് ഉറവിടം, അതിഥി പാത്ത്, ഉടമ അക്കൗണ്ട് എന്നിവ രേഖപ്പെടുത്തുക. ആ അഞ്ച് മൂല്യങ്ങളാണ് പിന്നീടുള്ള പുനഃസൃഷ്ടി, കൈമാറ്റം അല്ലെങ്കിൽ പ്രൊഫൈൽ മാറ്റം സംരക്ഷിക്കേണ്ടത്, സന്ദർഭമില്ലാത്ത അനുമതി പിശകിനെക്കാൾ അവ താരതമ്യം ചെയ്യാൻ വളരെ എളുപ്പമാണ്.