ip netns exec, DNS എന്നിവ: നെയിംസ്പേസിനുള്ളിൽ പേരുകൾ എന്തുകൊണ്ട് പരാജയപ്പെടുന്നു

ഒരു കമാൻഡ് VPN നെയിംസ്പേസിനുള്ളിൽ 10.8.0.5 ലേക്ക് ഒരു പരാതിയുമില്ലാതെ എത്തുന്നു, അതേ കമാൻഡ് ഹോസ്റ്റ്നെയിം ഉപയോഗിക്കുന്ന നിമിഷം പരാജയപ്പെടുന്നു. നെയിംസ്പേസിന് സ്വന്തം ഇന്റർഫേസുകളും റൂട്ടുകളും സോക്കറ്റുകളും ഉണ്ട്; സ്വന്തം റിസോൾവർ ഫയൽ ഇല്ല. എന്തെങ്കിലും അവിടെ ഒന്ന് വെച്ചില്ലെങ്കിൽ, അകത്തെ പ്രോസസ് ഹോസ്റ്റിന്റെ /etc/resolv.conf വായിച്ച്, ആ നെറ്റ്വർക്ക് സ്റ്റാക്കിൽ നിന്ന് എത്താൻ കഴിയാത്ത ഒരു സെർവറിനോട് ചോദിക്കുന്നു.

ഇത് റൂട്ടിംഗ് പ്രശ്നമല്ല, ഫയൽ തിരഞ്ഞെടുപ്പ് പ്രശ്നമാണ്, അതുകൊണ്ടാണ് സംഖ്യാത്മക ലക്ഷ്യസ്ഥാനം ഇപ്പോഴും പ്രവർത്തിക്കുന്നത്.

പ്രോസസ് യഥാർത്ഥത്തിൽ ലഭിക്കുന്ന റിസോൾവർ കാഴ്ച പരിശോധിക്കുക

നിങ്ങൾ ഉപയോഗിച്ച ഷെൽ നിങ്ങൾ ഡീബഗ് ചെയ്യുന്ന പ്രോസസിന് തുല്യമാണെന്ന് കരുതരുത്. ഒരു ഗ്രാഫിക്കൽ ആപ്ലിക്കേഷൻ, ഒരു systemd യൂണിറ്റ്, ഒരു കണ്ടെയ്നർ എന്നിവയിൽ ഓരോന്നിനും വ്യത്യസ്ത മൗണ്ട് അല്ലെങ്കിൽ നെറ്റ്വർക്ക് സന്ദർഭത്തിൽ പ്രവേശിക്കാം. അതേ ലോഞ്ച് പാതയിലൂടെ ലുക്കപ്പ് പ്രവർത്തിപ്പിച്ച്, അകത്തുനിന്ന് റിസോൾവർ ഫയൽ പ്രിന്റ് ചെയ്യുക.

ip netns add ഉപയോഗിച്ച് നിർമ്മിച്ച നെയിംസ്പേസിന് വായന-മാത്ര പരിശോധന ചെറുതാണ്:

ip netns exec vpn cat /etc/resolv.conf

ഫലം എത്താവുന്ന ഒരു വിലാസമാണോ, loopback സ്റ്റബ്ബാണോ, അതല്ലെങ്കിൽ വ്യത്യസ്ത എത്തിച്ചേരൽ ഉള്ള ഒരിടത്തേക്ക് ചൂണ്ടുന്ന സിംബോളിക് ലിങ്കാണോ എന്ന് ശ്രദ്ധിക്കുക.

exec സഹായി യഥാർത്ഥത്തിൽ മൗണ്ട് ചെയ്യുന്നത്

ip-netns ഉപകരണം ഓരോ നെയിംസ്പേസിന്റെയും കോൺഫിഗറേഷൻ /etc/netns/NAME/-ന് കീഴിൽ രേഖപ്പെടുത്തുന്നു. അത് ഒരു പ്രോസസ് ലോഞ്ച് ചെയ്യുമ്പോൾ, സഹായി ഒരു മൗണ്ട് നെയിംസ്പേസ് സൃഷ്ടിച്ച് ആ ഫയലുകൾ അവയുടെ സാധാരണ പാതകൾക്ക് മുകളിൽ bind-mount ചെയ്യുന്നു, അതിനാൽ പ്രോസസ് നെയിംസ്പേസിന് പ്രത്യേകമായ പകർപ്പ് കാണുന്നു. ഇത് ഈ പ്രത്യേക ലോഞ്ചറിന്റെ സൗകര്യമാണ്. unshare അല്ലെങ്കിൽ കണ്ടെയ്നർ റൺടൈം പോലുള്ള മറ്റൊരു വഴിയിലൂടെ നെറ്റ്വർക്ക് നെയിംസ്പേസിൽ പ്രവേശിക്കുന്നത് അത് സ്വയമേവ പുനർനിർമ്മിക്കുന്നില്ല.

ഇവിടെ കെണി loopback റിസോൾവറാണ്: 127.0.0.53 അർത്ഥമാക്കുന്നത് നെയിംസ്പേസിന്റെ സ്വന്തം loopback ആണ്, ഹോസ്റ്റിന്റെ സ്റ്റബ്ബല്ല. ഹോസ്റ്റ് നെയിംസ്പേസിൽ മാത്രം കേൾക്കുന്ന സ്റ്റബ് പുതിയതിൽ സേവനമാകുന്നില്ല.

നെയിംസ്പേസിന് എത്താൻ കഴിയുന്ന ഒരു റിസോൾവർ തിരഞ്ഞെടുക്കുക

ഫയൽ ഏത് സെർവറിനെ പേരിട്ടാലും, അതിന് ആ നെയിംസ്പേസിൽ നിന്ന് ഇപ്പോഴും ഒരു റൂട്ട് വേണം. ഒരു പൊതു റിസോൾവർ പൊതു പേരുകൾക്ക് ഉത്തരം നൽകിയാലും ആന്തരിക സോണിന് പരാജയപ്പെടാം, കാരണം സ്വകാര്യ സേവനം ടണലിലൂടെ മാത്രമേ എത്താൻ കഴിയൂ. ലുക്കപ്പ് പരാജയപ്പെട്ടതിന് ശേഷമല്ല, വിലാസത്തോടൊപ്പം അതേ സമയം റൂട്ട് പരിശോധിക്കുക.

സ്വന്തം റിസോൾവറുള്ള ആപ്ലിക്കേഷനുകൾ, ഉദാഹരണത്തിന് DNS over HTTPS ഉപയോഗിക്കുന്ന ഒന്ന്, ഫയൽ പൂർണ്ണമായി അവഗണിച്ചേക്കാം. ഉപകരണത്തിന് സ്വന്തം DNS ക്രമീകരണമുണ്ടെങ്കിൽ, resolv.conf മാറ്റുന്നത് അതിനെ ബാധിക്കില്ല, നെയിംസ്പേസ് ഒരിക്കലും പ്രശ്നമായിരുന്നില്ല.

ഫയൽ ശരിയായ സ്ഥലത്ത് എഴുതുക

/etc/netns/NAME/resolv.conf-ന് കീഴിൽ നെയിംസ്പേസിന് പ്രത്യേകമായ ഫയൽ സൃഷ്ടിച്ച് ലോഞ്ചർ അത് അവതരിപ്പിക്കട്ടെ. അത് ഏറ്റവും കുറഞ്ഞതാക്കി വയ്ക്കുക: എത്താൻ കഴിയുന്ന ഒന്നോ രണ്ടോ സെർവറുകളും ജോലിക്ക് ആവശ്യമായ തിരയൽ ഡൊമെയ്നുകളും. ഒരു കൂട്ടം പ്രോസസുകൾക്കായി ഉദ്ദേശിച്ച കാഴ്ച ശരിയാക്കാൻ ഹോസ്റ്റിന്റെ സൃഷ്ടിക്കപ്പെട്ട റിസോൾവർ ഫയൽ എഡിറ്റ് ചെയ്യരുത്, കാരണം അത് യന്ത്രത്തിലെ എല്ലാ ആപ്ലിക്കേഷനുകളെയും മാറ്റുന്നു. ഹോസ്റ്റ് റിസോൾവർ മാനേജർ ഉപയോഗിക്കുന്നുവെങ്കിൽ, അതിനോട് പോരാടുന്നതിന് പകരം ആ മാനേജരിലൂടെ നെയിംസ്പേസ് പാത ക്രമീകരിക്കുക.

ഫയലിന്റെ ഉള്ളടക്കം റൺബുക്കിൽ രേഖപ്പെടുത്തുക. അല്ലെങ്കിൽ അടുത്ത ആൾ ഹോസ്റ്റിന്റെ റിസോൾവർ പരിശോധിച്ച്, പ്രവർത്തിക്കുന്ന ഉത്തരം കണ്ട്, നെയിംസ്പേസ് കുഴപ്പമില്ലെന്ന് തീരുമാനിക്കും.

മുഴുവൻ പാതയും വീണ്ടും പരിശോധിക്കുക

നെയിംസ്പേസിനുള്ളിൽ സംഖ്യാത്മക വിലാസം, ആന്തരിക പേര്, പൊതു പേര് എന്നിവ ഉപയോഗിച്ച് പരിശോധിക്കുക. ഈ ക്രമം എത്തിച്ചേരലിനെ റിസല്യൂഷനിൽ നിന്ന് വേർതിരിക്കുന്നു, ആന്തരിക സോണുകളെ പൊതു സോണുകളിൽ നിന്ന് വേർതിരിക്കുന്നു. തുടർന്ന് നെയിംസ്പേസ് വീണ്ടും സൃഷ്ടിച്ച് ആവർത്തിക്കുക, കാരണം പ്രവർത്തിക്കുന്ന ഇൻസ്റ്റൻസിൽ മാത്രമുള്ള ഫയൽ അതിനൊപ്പം മാഞ്ഞുപോകുന്നു.

ഫയൽ ഷെല്ലല്ല, പ്രോസസാണ് സ്വീകരിക്കുന്നതെന്ന് ഉറപ്പാക്കുക. ഇന്ററാക്ടീവ് ഷെല്ലിൽ നിന്ന് പ്രവർത്തിക്കുകയും സേവനത്തിൽ നിന്ന് പരാജയപ്പെടുകയും ചെയ്യുന്ന ലുക്കപ്പ് മൗണ്ട്-സന്ദർഭത്തെക്കുറിച്ചുള്ള ഒരു കണ്ടെത്തലാണ്, അടുത്ത സംഭവത്തിന് മുമ്പ് പൂജ്യത്തിൽ നിന്ന് വീണ്ടും കണ്ടെത്തുന്നതിന് പകരം അത് എഴുതിവയ്ക്കുന്നത് മൂല്യവത്താണ്.