നിങ്ങളുടെ /etc/hosts എൻട്രി VPN-ന്റെ DNS-ൽ എത്താത്തത് എന്തുകൊണ്ട്

നിങ്ങൾ /etc/hosts-ലേക്ക് ഒരു പേര് ചേർത്തു, VPN-ലേക്ക് കണക്റ്റ് ചെയ്തു, റെക്കോർഡ് എല്ലാവർക്കും ദൃശ്യമാകുമെന്ന് പ്രതീക്ഷിച്ചു. അങ്ങനെ സംഭവിക്കുന്നില്ല, ആശ്ചര്യം സാധാരണയായി രണ്ടാമത്തെ ലക്ഷണത്തോടൊപ്പം വരുന്നു: പേര് നിങ്ങളുടെ മെഷീനിൽ റിസോൾവ് ചെയ്യുന്നു, സഹപ്രവർത്തകന്റെ മെഷീനിൽ പരാജയപ്പെടുന്നു, ഇത് തകർന്ന VPN DNS സേവനം പോലെ തോന്നിക്കുന്നു, യഥാർത്ഥത്തിൽ hosts ഫയൽ അതിനായി രൂപകൽപ്പന ചെയ്തത് കൃത്യമായി ചെയ്യുകയാണ്. hosts ഫയൽ പ്രാദേശിക നാമ-റിസല്യൂഷൻ കോൺഫിഗറേഷനാണ്, സോൺ അപ്ഡേറ്റ് അല്ല, സാധാരണ VPN കണക്ഷനിൽ ഒന്നും അത് അപ്ലോഡ് ചെയ്യുന്നില്ല.

Hosts പ്രാദേശിക ഓവർറൈഡാണ്, സോൺ അപ്ഡേറ്റ് അല്ല

ഫയൽ എന്നത് നാമ-സേവന ലൈബ്രറികൾ DNS സെർവറിനോട് ചോദിക്കുന്നതിന് മുമ്പ് അല്ലെങ്കിൽ പകരം പരിശോധിക്കുന്ന മാപ്പിംഗുകളുടെ പട്ടികയാണ്. 10.40.0.20 build.corp.example പോലുള്ള ഒരു വരി ആ ഒരു മെഷീനിലെ ആപ്ലിക്കേഷനുകൾ എന്ത് നിഗമനത്തിലെത്തുന്നു എന്നത് മാറ്റുന്നു. അത് ഒരു റെക്കോർഡ് സൃഷ്ടിക്കുന്നില്ല, ടണലിലൂടെ സഞ്ചരിക്കുന്നില്ല, ടണൽ ചൂണ്ടുന്ന DNS സെർവറിന് അതിന്റെ നിലനിൽപ്പിനെക്കുറിച്ച് ഒരു അറിവുമില്ല.

അതുകൊണ്ടാണ് പരാജയം അസമമായിരിക്കുന്നത്. നിങ്ങളുടെ ക്ലയന്റ് ഫയലിൽ നിന്ന് ഉത്തരം ലഭിക്കുന്നു. മറ്റൊരു ക്ലയന്റ് VPN-ന്റെ DNS സെർവറിനോട് ചോദിക്കുന്നു, അത് ഒന്നും തിരികെ നൽകുന്നില്ല, ആപ്ലിക്കേഷൻ പേര് നിലവിലില്ലെന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു. രണ്ട് മെഷീനുകളും ശരിയായി പെരുമാറുന്നു; ഒന്നിന് മാത്രം മറ്റൊന്ന് ഒരിക്കലും കണ്ടിട്ടില്ലാത്ത ഓവർറൈഡ് ഉണ്ട്.

രണ്ട് കമാൻഡുകൾ, രണ്ട് വ്യത്യസ്ത ഘടകങ്ങൾ

ഈ തർക്കം അവസാനിപ്പിക്കാനുള്ള ഏറ്റവും വേഗതയേറിയ മാർഗം വ്യത്യാസം രണ്ട് കമാൻഡുകളിൽ ദൃശ്യമാക്കുകയാണ്, രണ്ടും hosts എൻട്രി ഉള്ള ക്ലയന്റിൽ പ്രവർത്തിപ്പിക്കുന്നു:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

ആദ്യത്തേത് സിസ്റ്റത്തിന്റെ സ്വന്തം ലുക്കപ്പ് പാതയോട് ചോദിക്കുന്നു, സാധാരണ glibc സിസ്റ്റത്തിൽ അത് DNS-ന് മുമ്പ് പ്രാദേശിക ഫയലുകൾ വായിക്കുന്നു. രണ്ടാമത്തേത് ആ വിലാസത്തിലെ സെർവറിലേക്ക് നേരിട്ട് DNS ക്വറി അയയ്ക്കുന്നു, പ്രാദേശിക ഫയലുകൾ ഒട്ടും പരിശോധിക്കുന്നില്ല. ആദ്യത്തേത് നിങ്ങളുടെ എൻട്രി തിരികെ നൽകുകയും രണ്ടാമത്തേത് NXDOMAIN നൽകുകയും ചെയ്യുമ്പോൾ, റെക്കോർഡ് DNS-ൽ ഇല്ലെന്നും നിങ്ങളുടെ മെഷീൻ പ്രാദേശിക ഓവർറൈഡിൽ നിന്ന് ഉത്തരം നൽകുകയാണെന്നും നിങ്ങൾ തെളിയിച്ചു.

ക്രമം കോൺഫിഗർ ചെയ്യാവുന്നതാണ്, ഒരു പ്രത്യേക വിതരണത്തെക്കുറിച്ച് എന്തെങ്കിലും നിഗമനത്തിലെത്തുന്നതിന് മുമ്പ് അത് പരിശോധിക്കുന്നത് മൂല്യവത്താണ്. /etc/nsswitch.conf-ലെ hosts: വരി നോക്കുക; hosts: files dns ആദ്യം ഫയലുകൾ പരിശോധിക്കുന്നു. ക്രമം മാറ്റാൻ മാത്രമായി ആ ഉദാഹരണം പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷനിൽ പകർത്തരുത്, കാരണം യഥാർത്ഥ സിസ്റ്റങ്ങൾ ഉദാഹരണത്തിലില്ലാത്ത അധിക ഉറവിടങ്ങളും വ്യവസ്ഥാപരമായ സേവന എൻട്രികളും പലപ്പോഴും ലിസ്റ്റ് ചെയ്യുന്നു.

systemd-resolved പരിശോധനയെ മങ്ങലാക്കുന്നു

systemd-resolved ഉപയോഗിക്കുന്ന സിസ്റ്റത്തിൽ പ്രാദേശിക സ്റ്റബ് hosts ഡാറ്റാബേസിൽ നിന്നും പേരുകൾ നൽകുന്നു. അതിനാൽ 127.0.0.53-ഓട് ക്വറി ചെയ്യുന്നത് റിമോട്ട് സെർവറിന്റെ സ്വതന്ത്ര പരിശോധനയല്ല, അത് DNS ക്വറി പോലെ തോന്നുകയും അങ്ങനെ പെരുമാറുകയും ചെയ്താലും. റിസോൾവറിന് എന്ത് അറിയാം, ഏത് സെർവറുകളോട് ചോദിക്കും എന്ന് നിങ്ങൾക്ക് ഇതിലൂടെ ഉറപ്പാക്കാം:

resolvectl query build.corp.example
resolvectl status

status ഔട്ട്പുട്ട് ഓരോ ലിങ്കിനും DNS സെർവറുകൾ പേരിടുന്നു, അങ്ങനെ VPN ലിങ്കിന് റിസോൾവർ ലഭിച്ചോ ഇല്ലയോ എന്ന് നിങ്ങൾ അറിയുന്നു. ആ ചോദ്യം hosts എൻട്രിയിൽ നിന്ന് വേറിട്ടതാണ്, സ്വകാര്യ നാമം ഒരാൾക്കല്ല എല്ലാ ഉപയോക്താവിനും പരാജയപ്പെടുമ്പോൾ ചോദിക്കാൻ യോഗ്യമായ ചോദ്യം അതാണ്.

ആപ്ലിക്കേഷനുകൾക്ക് മറ്റൊരു പാളി കൂടി ചേർക്കാം. സ്വന്തം DNS-over-HTTPS ക്രമീകരണമുള്ള ബ്രൗസർ, സ്വന്തം റിസോൾവർ കോൺഫിഗറേഷനുള്ള കണ്ടെയ്നർ, അല്ലെങ്കിൽ പ്രോസസിന്റെ മുഴുവൻ ജീവിതകാലത്തും ലുക്കപ്പുകൾ കാഷെ ചെയ്യുന്ന റൺടൈം എന്നിവയ്ക്ക് സിസ്റ്റത്തിൽ നിന്ന് വ്യത്യസ്തമായി ഉത്തരം നൽകാം. ഒരു കമാൻഡ് മെഷീനിലെ എല്ലാ പ്രോഗ്രാമിനെയും വിവരിക്കുന്നു എന്ന് അനുമാനിക്കുന്നതിന് പകരം നിങ്ങൾക്ക് പ്രധാനമായ ആപ്ലിക്കേഷൻ പരിശോധിക്കുക.

VPN-ന് കുറുകെ ഒരു പേര് യഥാർത്ഥത്തിൽ പങ്കിടുന്നത് എന്ത്

ഒരു സ്വകാര്യ നാമം എല്ലാവർക്കും പ്രവർത്തിക്കണമെങ്കിൽ, എല്ലാവരുടെയും റിസോൾവറിന് എത്താവുന്ന ഒരു ഉടമ ആവശ്യമാണ്. വ്യക്തമായ ഉത്തരം റെക്കോർഡ് ഒരു മാനേജുചെയ്ത സോണിൽ പ്രസിദ്ധീകരിക്കുകയും ആ സോൺ ഉദ്ദേശിച്ച VPN DNS പാതയിലൂടെ റിസോൾവ് ചെയ്യാവുന്നതാക്കുകയും ചെയ്യുകയാണ്. അപ്പോൾ റെക്കോർഡിന് ഒരു സത്യ സ്രോതസ്സ്, ഓഡിറ്റ് ട്രെയിൽ, ജീവിതചക്രം എന്നിവ ഉണ്ടാകും, ഏത് ലാപ്ടോപ്പിൽ പ്രാദേശിക ഓവർറൈഡ് ഉണ്ടെന്ന് ആരും ഓർക്കേണ്ടതില്ല.

hosts ഫയലുകൾ വിതരണം ചെയ്യുന്നത് സാധുവായ ഒരു ബദലാണ്, അത് നാമ-സേവനമല്ല, എൻഡ്പോയിന്റ് മാനേജ്മെന്റാണ്. നിങ്ങൾ അത് തിരഞ്ഞെടുക്കുകയാണെങ്കിൽ, ഫ്ലീറ്റ് മാനേജ് ചെയ്യുന്നത് ഫയൽ വിന്യസിക്കുകയും പതിപ്പാക്കുകയും നീക്കം ചെയ്യുകയും വേണം, ഡിസൈനിൽ അത് അങ്ങനെ തന്നെ വിവരിക്കണം. “VPN അത് കൈകാര്യം ചെയ്യുന്നു” എന്നത് ആ പ്രക്രിയയുടെ വിവരണമല്ല.

ഡൈനാമിക് DNS രജിസ്ട്രേഷൻ മൂന്നാമത്തെ സംവിധാനമാണ്, അതിന്റേതായ അനുമതികൾ, അപ്ഡേറ്റ് പ്രാമാണീകരണം, റെക്കോർഡ് ആയുസ്സ് എന്നിവയുണ്ട്. അത് hosts എൻട്രിയിൽ നിന്ന് ഉണ്ടാകുന്നില്ല, ക്ലയന്റ് വെറുതെ കണക്റ്റ് ചെയ്യുന്നതിൽ നിന്നും ഉണ്ടാകുന്നില്ല, സെർവറും ക്ലയന്റും രണ്ടും അതിനായി കോൺഫിഗർ ചെയ്തിട്ടില്ലെങ്കിൽ. സ്വയം പ്രത്യക്ഷപ്പെടുന്ന ഒരു റെക്കോർഡ് ആരോ സുരക്ഷിത അപ്ഡേറ്റുകൾ പ്രവർത്തനക്ഷമമാക്കിയതിന്റെയും ഒരു ക്ലയന്റ് സ്വയം രജിസ്റ്റർ ചെയ്യുന്നതിന്റെയും സൂചനയാണ്, ആ കോൺഫിഗറേഷൻ ട്രബിൾഷൂട്ടിംഗ് ത്രെഡിലല്ല, ഡിസൈൻ റെക്കോർഡിലാണ് ഉണ്ടാകേണ്ടത്. ആ ക്രമീകരണത്തിന്റെ ഉടമ ആരെന്ന് ആർക്കും പറയാനാകുന്നില്ലെങ്കിൽ, യാന്ത്രിക റെക്കോർഡിനെ സ്ഥിരീകരിക്കാത്തതായി കണക്കാക്കി മാനേജുചെയ്ത സോൺ സത്യ സ്രോതസ്സായി നിലനിർത്തുക.

റിസോൾവ് ചെയ്ത പേര് ഒരു റൂട്ട് അല്ല

നാമ റിസല്യൂഷനും എത്തിച്ചേരാനുള്ള കഴിവും വേറിട്ടവയാണ്, കാലഹരണപ്പെട്ട പ്രാദേശിക മാപ്പിംഗ് അവയെ കൂട്ടിക്കലർത്താനുള്ള ക്ലാസിക് മാർഗമാണ്. സ്ഥലം മാറിയ വിലാസത്തിലേക്ക് ചൂണ്ടുന്ന hosts എൻട്രി DNS തിരുത്തിയതിന് വളരെ കഴിഞ്ഞും പഴയ ഹോസ്റ്റ് തിരഞ്ഞെടുക്കുന്നത് തുടരും, ലക്ഷണം നന്നായി റിസോൾവ് ചെയ്യുന്ന ഒരു പേരിലെ റൂട്ടിംഗ് പരാജയം പോലെ തോന്നും.

അതിനാൽ റിപ്പോർട്ട് “പേര് റിസോൾവ് ചെയ്യുന്നു പക്ഷേ സേവനം എത്തിച്ചേരാനാകില്ല” എന്നാകുമ്പോൾ, സിസ്റ്റം ലുക്കപ്പിനെ VPN DNS സെർവറിലേക്കുള്ള വ്യക്തമായ ക്വറിയുമായി താരതമ്യം ചെയ്യുക, തുടർന്ന് നിങ്ങൾക്ക് ലഭിച്ച വിലാസം സേവനം യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന വിലാസവുമായി പരിശോധിക്കുക. systemd-resolved റഫറൻസ് അത് പരിശോധിക്കുന്ന പ്രാദേശിക ഉറവിടങ്ങൾ രേഖപ്പെടുത്തുന്നു, ആ താരതമ്യത്തിന് ആവശ്യമായ ഭൂപടം അതാണ്.

തുടർന്ന് ഓവർറൈഡ് അതിന്റെ ഉടമ വഴി ശരിയാക്കുക. നിങ്ങളുടെ സ്വന്തം hosts ഫയലിൽ നിന്ന് ഒരു വരി നീക്കുന്നത് വിന്യാസ സ്ക്രിപ്റ്റിൽ നിന്ന് അതേ വരി ലഭിച്ച പന്ത്രണ്ട് ലാപ്ടോപ്പുകൾക്ക് ഒന്നും ചെയ്യുന്നില്ല, ആളുകൾക്ക് യഥാർത്ഥത്തിൽ ഉള്ള ഈ പ്രശ്നത്തിന്റെ പതിപ്പ് അതാണ്.