resolv.conf നിങ്ങളുടെ VPN DNS കാണിക്കുന്നതും എന്നാൽ ലുക്കപ്പുകൾ അത് അവഗണിക്കുന്നതും എന്തുകൊണ്ട്

ലോഗുകളിൽ ഒന്നും തെറ്റായി തോന്നുന്നില്ല: ഇന്റർഫേസ് പ്രവർത്തനക്ഷമമാണ്, റിസോൾവർ VPN-ന്റെ DNS സർവർ റിപ്പോർട്ട് ചെയ്യുന്നു, ഡിസ്കിലെ ഫയൽ അത് പട്ടികപ്പെടുത്തുന്നു. എന്നിട്ടും ഒരു ആന്തരിക ഹോസ്റ്റ്നാമം ഇപ്പോഴും പ്രാദേശിക റൗട്ടർ വഴി പരിഹരിക്കപ്പെടുന്നു. ഈ മൂന്ന് പ്രസ്താവനകൾ പരസ്പരവിരുദ്ധമല്ല, കാരണം ഫയലും ഓരോ ലിങ്കിന്റെയും അവസ്ഥയും ലുക്കപ്പിന്റെ പാതയും ഒരേ പേര് യാദൃച്ഛികമായി പങ്കിടുന്ന വ്യത്യസ്ത വസ്തുക്കളാണ്. താഴെ systemd-resolved ഉള്ള ഹോസ്റ്റിൽ ഒരു ക്വറി യഥാർത്ഥത്തിൽ പിന്തുടരുന്ന പാതയാണ്.

resolv.conf എന്ന പേരുള്ള മൂന്ന് വസ്തുക്കൾ

resolved ഉള്ള ഹോസ്റ്റിൽ /etc/resolv.conf സാധാരണയായി /run/systemd/resolve/stub-resolv.conf-ലേക്കുള്ള സിംബോളിക് ലിങ്കാണ്. ആ ലക്ഷ്യത്തിൽ പ്രാദേശിക stub ശ്രോതാവിന്റെ വിലാസം, 127.0.0.53, കൂടാതെ resolved കണക്കാക്കിയ തിരയൽ ഡൊമെയ്നുകളും അടങ്ങിയിരിക്കുന്നു. ഇത് അവസ്ഥയുടെ ഒരു കാഴ്ചയാണ്, അവസ്ഥ തന്നെയല്ല.

അവസ്ഥ resolved-ന്റെ ഓരോ ലിങ്കിലെയും കോൺഫിഗറേഷനിൽ ജീവിക്കുന്നു, അതുകൊണ്ടാണ് resolvectl status ഫയലുമായി വിയോജിക്കാനും എന്നിട്ടും ശരിയാകാനും കഴിയുന്നത്. ഓരോ ലിങ്കും അതിന്റേതായ സർവറുകളും അതിന്റേതായ റൂട്ടിംഗ് ഡൊമെയ്നുകളും വഹിക്കുന്നു, ഒരു ക്വറി വരുമ്പോൾ stub ആ ഡാറ്റ പരിശോധിക്കുന്നു. systemd-resolved മാനുവൽ സൃഷ്ടിക്കപ്പെടുന്ന ഫയലുകളും ഓരോ ലിങ്കിലെയും മാതൃകയും വിവരിക്കുന്നു; കാഴ്ചയും അവസ്ഥയും തമ്മിലുള്ള വേർതിരിവാണ് ഓർത്തിരിക്കാൻ യോഗ്യമായ ഭാഗം. സിംബോളിക് ലിങ്കിന്റെ ലക്ഷ്യം മാറ്റുന്നത് പരമ്പരാഗത ക്ലയന്റുകൾ വായിക്കുന്നതിനെ മാറ്റുന്നു, റിസോൾവർ അറിയുന്നതിനെയല്ല.

മൂന്നാമത്തെ വസ്തു, /run/systemd/resolve/resolv.conf, ഓരോ ലിങ്കും ഒരൊറ്റ സർവർ പട്ടികയായി പരത്തുന്നു. ആ ഫയലിലേക്ക് ചൂണ്ടുന്ന പ്രോഗ്രാം ക്വറികൾ നേരിട്ട് പട്ടികപ്പെടുത്തിയ സർവറുകളിലേക്ക് അയച്ച് stub ഒഴിവാക്കുന്നു, അതിനാൽ ഓരോ ലിങ്കിലെയും നയം ഇനി അതിനു ബാധകമല്ല. അതിനാൽ ഒരേ യന്ത്രത്തിലെ രണ്ട് പ്രോഗ്രാമുകൾക്ക് ഒരേ പേരിന് വ്യത്യസ്ത ഉത്തരം നൽകാം, ഒന്നും തകർന്നിട്ടില്ല.

NSS വഴി ഒരു ലുക്കപ്പ് പിന്തുടരുക

ഒരു പേരിന് ആരാണ് ഉത്തരം നൽകുന്നതെന്ന് തീരുമാനിക്കാൻ glibc /etc/nsswitch.conf വായിക്കുന്നു. resolve അടങ്ങിയ hosts വരി ചോദ്യം nss-resolve-ലേക്ക് അയയ്ക്കുന്നു, അത് D-Bus വഴി resolved-നോട് ചോദിച്ച് ഓരോ ലിങ്കിന്റെയും ഉത്തരം സ്വീകരിക്കുന്നു. files dns മാത്രമുള്ള വരി ക്വറി /etc/resolv.conf കൈവശം വയ്ക്കുന്ന വിലാസത്തിലേക്ക് അയയ്ക്കുന്നു.

ആ ഒരു വരി ബ്രൗസറും dig-ഉം തമ്മിലുള്ള മിക്ക അഭിപ്രായവ്യത്യാസങ്ങളും വിശദീകരിക്കുന്നു. dig resolv.conf നേരിട്ട് വായിക്കുന്നു, NSS-നെ ഒരിക്കലും തൊടുന്നില്ല, അതിനാൽ അപ്ലിക്കേഷൻ ഉപയോഗിക്കുന്ന പാതയല്ല, stub അല്ലെങ്കിൽ മുകളിലെ സർവർ പരിശോധിക്കുന്നു. getent hosts internal.example NSS വഴി കടന്നുപോകുന്നു, അതിന്റെ ഉത്തരം dig-ന്റെ ഉത്തരവുമായി താരതമ്യം ചെയ്യുന്നതാണ് ആദ്യത്തെ ഉപയോഗപ്രദമായ അളവ്.

സ്വന്തം റിസോൾവർ കൊണ്ടുനടക്കുന്നതോ നിശ്ചിത എൻഡ്പോയിന്റിലേക്ക് HTTPS-ൽ DNS സംസാരിക്കുന്നതോ ആയ അപ്ലിക്കേഷനുകൾ രണ്ട് പാതകളും ഒഴിവാക്കുന്നു. resolv.conf-ലും resolved അവസ്ഥയിലും ഒന്നും അവയെ നിയന്ത്രിക്കുന്നില്ല.

ഫയൽ ആരുടെതാണെന്നും എങ്ങോട്ടാണ് ചൂണ്ടുന്നതെന്നും പരിശോധിക്കുക

എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് ലിങ്ക് ശൃംഖല വായിക്കുക, കാരണം ഉടമസ്ഥതയാണ് ഏത് ഫയലാണ് അധികാരമുള്ളതെന്ന് തീരുമാനിക്കുന്നത്. താഴെയുള്ള ഓരോ കമാന്റും അവസ്ഥ മാത്രം വായിക്കുന്നു.

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

ആദ്യ വരി ലിങ്കും അതിന്റെ ലക്ഷ്യവും ഒരുമിച്ച് അച്ചടിക്കുന്നു, VPN സ്ക്രിപ്റ്റിന്റെ ഉടമസ്ഥതയിലുള്ള സാധാരണ ഫയൽ എന്നാൽ റിസോൾവർ ആ എഴുത്ത് ഒരിക്കലും ഇൻപുട്ടായി കണക്കാക്കുന്നില്ല. അവസ്ഥയുടെ ഔട്ട്പുട്ട് ഓരോ ലിങ്കിന്റെയും സർവറുകളും ഓരോ ക്വറിയും എങ്ങോട്ട് പോകുന്നുവെന്ന് തീരുമാനിക്കുന്ന റൂട്ടിംഗ് ഡൊമെയ്നുകളും പട്ടികപ്പെടുത്തുന്നു. nsswitch വരി stub ഒട്ടും പരിശോധിക്കുന്നുണ്ടോ എന്ന് പറയുന്നു, അതിനാൽ ഫയലിൽ stub വിലാസം ഉണ്ടായിട്ടും അവിടെ resolve ഇല്ലെങ്കിൽ ക്വറികൾ പ്രാദേശിക ശ്രോതാവിനെ എത്തുന്നു, പക്ഷേ വിഭജനം ഒന്നും നിയന്ത്രിക്കുന്നില്ല. ആ അവസാന പട്ടികയും പ്രധാനമാണ്, കാരണം stub-resolv.conf ഇല്ലാത്ത ഹോസ്റ്റ് ഇവിടെ വിവരിച്ച ക്രമീകരണം പ്രവർത്തിപ്പിക്കുന്നില്ല.

ശൃംഖല മറ്റൊരു പാക്കേജ് നിയന്ത്രിക്കുന്ന ഫയലിൽ അവസാനിക്കുകയാണെങ്കിൽ, VPN ക്ലയന്റും ആ പാക്കേജും ഒത്തുതീർപ്പാക്കേണ്ട രണ്ട് ഉടമകളാണ്. ലിങ്ക് മാറ്റിസ്ഥാപിക്കുന്നത് ഒരു ഉടമയുടെ ജോലി കളയുകയും മറ്റേയാളുടെത് അതിന്റെ സ്ഥാനത്ത് വയ്ക്കുകയും ചെയ്യുന്നു.

ലിങ്കിന്റെ ഉടമയുടെ അടുത്ത് നന്നാക്കുക

ഒരു VPN കണക്ഷൻ അതിന്റെ സർവറുകളും ഡൊമെയ്നുകളും സ്വന്തം ലിങ്കിൽ രജിസ്റ്റർ ചെയ്ത്, വിച്ഛേദിക്കുമ്പോൾ അവ പിൻവലിക്കണം. NetworkManager-ന്റെ resolved സംയോജനവും ക്ലയന്റിന്റെ സ്വന്തം സഹായിയും അങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത്; resolv.conf മാത്രം വീണ്ടും എഴുതുന്ന സ്ക്രിപ്റ്റ് അങ്ങനെ ചെയ്യുന്നില്ല.

ഇതിനകം നിലവിലുള്ള ഒരു ലിങ്കിൽ റൺടൈം ക്രമീകരണങ്ങൾ സംവിധാനം കാണിക്കുന്നു. resolvectl dns tun0 10.40.0.53 ഒരു സർവർ ചേർക്കുന്നു, resolvectl domain tun0 '~corp.example' ഒരു റൂട്ടിംഗ് ഡൊമെയ്ൻ ചേർക്കുന്നു. ടിൽഡ (~) ഭാരം വഹിക്കുന്ന പ്രതീകമാണ്: അത് ആ പ്രത്യയത്തിന്റെ ക്വറികൾ ഈ ലിങ്കിലേക്ക് ഒതുക്കി ബാക്കിയെല്ലാം ശാന്തമായി വിടുന്നു, അതില്ലാതെ അതേ മൂല്യം തിരയൽ ഡൊമെയ്നാകുകയും വിഭജനം ബാഷ്പീഭവിക്കുകയും ചെയ്യുന്നു. ആ വിലാസങ്ങൾ ലാബ് ഉദാഹരണങ്ങളാണ്, സ്ഥിരമായ കോൺഫിഗറേഷനല്ല. resolvectl query host.corp.example ഉപയോഗിച്ച് സ്ഥിരീകരിച്ച് ഏത് ലിങ്കാണ് ഉത്തരം നൽകിയതെന്ന് വായിക്കുക.

രജിസ്റ്റർ ചെയ്ത സർവറിന് ഇപ്പോഴും ഒരു റൂട്ട് വേണം. ക്വറി ശരിയായ ലിങ്കിൽ എത്തി സമയം കഴിയുമ്പോൾ, കുറ്റം റിസോൾവർ ഉടമസ്ഥതയിലല്ല, ടണലിലൂടെയുള്ള എത്തിച്ചേരലിലാണ്.

പ്രവർത്തിക്കുന്ന അവസ്ഥ എങ്ങനെയിരിക്കും

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

ശേഷം വിച്ഛേദിച്ച് രണ്ട് ക്വറികളും ആവർത്തിക്കുക. ടിയർഡൗണിന് ശേഷവും തന്റെ ഡൊമെയ്നുകൾ രജിസ്റ്റർ ചെയ്ത് വയ്ക്കുന്ന ക്ലയന്റ് മണിക്കൂറുകൾക്ക് ശേഷം ആന്തരിക ലുക്കപ്പുകളിൽ പരാജയപ്പെടുന്ന യന്ത്രം സൃഷ്ടിക്കുന്നു, തുറന്ന ടണലും വ്യക്തമായ കാരണവുമില്ലാതെ.