LAN ഹോസ്റ്റ്നെയിം VPN വഴി പ്രവർത്തിക്കുന്നില്ല: സഫിക്സ്, mDNS അല്ലെങ്കിൽ സോൺ?

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

പേര് ഏത് സംവിധാനത്തെ ആശ്രയിച്ചിരിക്കുന്നു എന്ന് കണ്ടെത്തി തുടങ്ങുക.

വ്യത്യസ്തമായി പെരുമാറുന്ന മൂന്ന് തരം പേരുകൾ

fileserver പോലുള്ള ഒറ്റ-ലേബൽ പേര് സാധാരണയായി റിസോൾവർ ചേർക്കുന്ന DNS തിരയൽ സഫിക്സിനെ ആശ്രയിക്കുന്നു. ആ സഫിക്സ് പലപ്പോഴും പ്രാദേശിക DHCP ലീസിനൊപ്പം വരുന്നു, അതിനാൽ VPN-ൽ നിന്ന് വിലാസം ലഭിക്കുന്ന ദൂരസ്ഥ ക്ലയന്റിന് അത് അറിയാൻ കാരണമില്ല. റൂട്ട് ചേർക്കുന്നത് സഫിക്സ് എത്തിക്കുന്നില്ല. ചെറിയ പേര് പേരായി നിലനിൽക്കുന്നത് നിർത്തുന്നു, പിന്നിലെ വിലാസം എത്തിച്ചേരാവുന്നതാണെങ്കിലും.

.local ൽ അവസാനിക്കുന്ന പേര് സാധാരണയായി പ്രാദേശിക ലിങ്കിൽ മൾട്ടികാസ്റ്റ് DNS വഴി പരിഹരിക്കുന്നു, RFC 6762 വിവരിക്കുന്നതുപോലെ. മൾട്ടികാസ്റ്റ് റൂട്ട് ചെയ്ത ടണൽ കടക്കുന്നില്ല, എന്തെങ്കിലും ബോധപൂർവം അത് ബ്രിഡ്ജ് ചെയ്യുകയോ പ്രോക്സി ചെയ്യുകയോ ചെയ്യുന്നില്ലെങ്കിൽ, അതിനാൽ നിങ്ങൾ സെഗ്മെന്റ് വിടുന്ന നിമിഷം പേര് പരിഹരിക്കുന്നത് നിർത്തുന്നു.

പൂർണ്ണമായി യോഗ്യമായ കമ്പനിയുടെ പേര് സംഘടനയുടെ റിസോൾവറുകൾ സേവിക്കുന്ന ആന്തരിക സോണിന് ഉള്ളതാണ്. VPN ആ റിസോൾവറുകൾ പുഷ് ചെയ്യുകയും ക്ലയന്റ് അവ ഉപയോഗിക്കാൻ കോൺഫിഗർ ചെയ്യുകയും ചെയ്യുമ്പോൾ അത് ദൂരത്തുനിന്ന് പ്രവർത്തിക്കുന്നു. കൂടാതെ localhost RFC 6761 അനുസരിച്ച് പ്രത്യേക-ഉപയോഗമാണ്: അത് നിങ്ങളുടെ മുന്നിലുള്ള യന്ത്രത്തെ സൂചിപ്പിക്കുന്നു, ഒരിക്കലും ദൂരസ്ഥ സേവനത്തെയല്ല.

റൂട്ട് മാറ്റുന്നതിന് മുമ്പ് റിസോൾവർ വായിക്കുക

ഏത് നെയിം സർവർ ഉത്തരം നൽകി, ഏത് സഫിക്സ് ചേർത്തു എന്ന് ചോദിക്കുക. വ്യത്യസ്ത റിസോൾവറുകളിലൂടെയുള്ള അതേ ക്വറി വ്യത്യസ്ത ഉത്തരങ്ങൾ നൽകുന്നു, ആ വ്യത്യാസമാണ് നിങ്ങൾക്ക് വേണ്ട തെളിവ്.

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

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

ശരിയായ പേര് ക്ലയന്റിലേക്ക് എത്തിക്കുക

അഡ്മിനിസ്ട്രേറ്ററിൽ നിന്ന് രേഖപ്പെടുത്തിയ ദൂരസ്ഥ-പ്രവേശന പേര് പൂർണ്ണമായി ചോദിക്കുക, സഫിക്സുകൾ ഊഹിക്കുന്നതിന് പകരം പ്രൊഫൈലിൽ അത് ഉപയോഗിക്കുക. വിന്യാസം split DNS പിന്തുണയ്ക്കുന്നുവെങ്കിൽ, ആന്തരിക ഡൊമെയ്ൻ ആന്തരിക സർവറുകൾ പരിഹരിക്കുന്നതിന് കോൺഫിഗർ ചെയ്യുക, ബാക്കിയെല്ലാം പ്രാദേശിക റിസോൾവർ നിലനിർത്തുന്നു. ക്ലയന്റ് പിന്തുണയ്ക്കുന്നിടത്ത് VPN കോൺഫിഗറേഷനിലൂടെ തിരയൽ ഡൊമെയ്ൻ പുഷ് ചെയ്യുക.

ഫലം ഗേറ്റ്വേയിലല്ല, ക്ലയന്റിൽ പരിശോധിക്കുക. സർവറിൽ പ്രയോഗിച്ച് ക്ലയന്റിൽ എത്താത്ത ക്രമീകരണം ഒന്നും മാറ്റുന്നില്ല.

സർട്ടിഫിക്കറ്റിന്റെ ഐഡന്റിറ്റി സുരക്ഷിതമായി സൂക്ഷിക്കുക

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

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