VPN DNS പ്രവർത്തിക്കുന്നു, പക്ഷേ .local നാമങ്ങൾ ഇപ്പോഴും പരാജയപ്പെടുന്നു: അവ ആരാണ് പരിഹരിക്കുന്നത്?

ഒരേ VPN-ൽ രണ്ട് യന്ത്രങ്ങൾ, ഒരേ ഹോസ്റ്റ്നെയിം, എന്നാൽ അവയിൽ ഒന്ന് മാത്രം അത് പരിഹരിക്കുന്നു: വ്യത്യാസം സാധാരണയായി ടണലല്ല, മറിച്ച് ഏത് റിസോൾവർ ഉത്തരം നൽകി എന്നതാണ്. Linux ഡെസ്ക്ടോപ്പിൽ ആ നാമം നാമ സേവന സ്വിച്ചിലൂടെയും systemd-resolved-ന്റെ സ്റ്റബിലൂടെയും അല്ലെങ്കിൽ അപ്ലിക്കേഷൻ കൊണ്ടുവന്ന ഒരു റിസോൾവറിലൂടെയും പോകാം, ഓരോന്നും അതേ സഫിക്സിന് സ്വന്തം നിയമം പ്രയോഗിക്കുന്നു. നിയമങ്ങൾ വേർതിരിയുന്നത് സഫിക്സിലാണ്, കാരണം .local നിഷ്പക്ഷ ലേബലല്ല. എന്തെങ്കിലും ഏത് ക്രമത്തിൽ പ്രവർത്തിക്കുന്നു എന്ന് മാറ്റുന്നതിന് മുമ്പ് പരാജയപ്പെടുന്ന പ്രോഗ്രാം യഥാർത്ഥത്തിൽ ഏത് പാതയാണ് സ്വീകരിക്കുന്നതെന്ന് കണ്ടെത്തുക.

രണ്ട് റിസോൾവറുകൾ, രണ്ട് വ്യത്യസ്ത ഉത്തരങ്ങൾ

പരമ്പരാഗത glibc തിരയൽ nsswitch.conf-ന്റെ hosts: വരിയിലൂടെ സഞ്ചരിച്ച് ഒന്ന് ഉത്തരം നൽകുന്നതുവരെ ഓരോ മൊഡ്യൂളിനോടും ഊഴമിട്ട് ചോദിക്കുന്നു. സ്റ്റബ് ശ്രോതാവിലൂടെ systemd-resolved-നോട് സംസാരിക്കുന്ന ക്ലയന്റ് പകരം ഒരൊറ്റ പ്രോസസ്സിനോട് ചോദിക്കുന്നു, ആ പ്രോസസ്സ് ഓരോ ലിങ്കിനുമുള്ള നയവും സ്വന്തം പ്രത്യേക കേസുകളും പ്രയോഗിക്കുന്നു. സ്വന്തം റിസോൾവർ കൊണ്ടുവരുന്ന അല്ലെങ്കിൽ അങ്ങനെ ചെയ്യുന്ന ലൈബ്രറി ലിങ്ക് ചെയ്യുന്ന അപ്ലിക്കേഷന് രണ്ടിനെയും ഒഴിവാക്കാം. അതിനാൽ ഒരു ഹോസ്റ്റ്നെയിമിന് ഒരു യന്ത്രത്തിൽ മൂന്ന് ഉടമകളുണ്ടാകാം, അവരിൽ ഒരാൾക്ക് മാത്രം VPN എന്താണ് ഉദ്ദേശിച്ചതെന്ന് അറിയാം.

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

ഏത് കമാൻഡാണ് യഥാർത്ഥത്തിൽ നിങ്ങളുടെ റിസോൾവറിനോട് ചോദിച്ചത്

രണ്ട് വായന-മാത്രം കമാൻഡുകൾ ബന്ധപ്പെട്ട ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു, അവ താരതമ്യം ചെയ്യുന്നത് കോൺഫിഗറേഷൻ വായിക്കുന്നതിനേക്കാൾ വേഗത്തിൽ പ്രശ്നം പ്രാദേശികവൽക്കരിക്കുന്നു. യഥാർത്ഥ ആന്തരിക നാമം ഉപയോഗിക്കുക, ഔട്ട്പുട്ട് സ്വകാര്യമായി സൂക്ഷിക്കുക, കാരണം ആന്തരിക റെക്കോർഡുകൾ ആന്തരികമായി തന്നെ തുടരും. രണ്ടും പരാജയപ്പെടുന്ന പ്രോഗ്രാം പ്രവർത്തിക്കുന്ന അതേ സെഷനിൽ പ്രവർത്തിപ്പിക്കുക:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

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

എന്തുകൊണ്ടാണ് .local നിങ്ങളുടെ unicast മേഖല ഒഴിവാക്കുന്നത്

systemd-resolved-ന്റെ റഫറൻസ് അനുസരിച്ച് .local-ൽ അവസാനിക്കുന്ന ബഹു-ലേബൽ നാമങ്ങൾ mDNS പ്രവർത്തനക്ഷമമാകുമ്പോൾ സാധാരണ unicast DNS-നെക്കാൾ പകരം സാധാരണയായി multicast DNS-ലേക്ക് പോകുന്നു. RFC 6762 ആ നാമസ്ഥലം link-local multicast-നായി മാറ്റിവെക്കുന്നു, അതിനാൽ ഒരു കോർപ്പറേറ്റ് മേഖലയ്ക്ക് ആ സഫിക്സിനായി ഒരിക്കലും ചോദിക്കാത്ത ശരിയായ റെക്കോർഡ് സൂക്ഷിക്കാം. ടണലിന് റിസോൾവറിനെ തികഞ്ഞ രീതിയിൽ റൂട്ട് ചെയ്യാം, എന്നിട്ടും മത്സരത്തിൽ തോൽക്കാം. കാഷിൽ നിന്ന് വിജയിക്കുന്ന ping ഇപ്പോൾ നടന്ന തിരയലിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

രേഖപ്പെടുത്തിയ ഒരു അപവാദമുണ്ട്, അത് ഈ കേസുകളിൽ മിക്കതും പരിഹരിക്കുന്നു: ഒരു ലിങ്ക് ആ സഫിക്സിനെ തിരയൽ ഡൊമെയ്നോ റൂട്ടിംഗ് ഡൊമെയ്നോ ആയി പ്രഖ്യാപിക്കുമ്പോൾ, ഡീമൺ അതിനെ unicast പാതയിൽ നിർത്തി multicast പ്രത്യേക കേസ് ഒഴിവാക്കുന്നു. അത് ഓരോ ലിങ്കിന്റെയും നയമാണ്, ആഗോള മുൻഗണനയല്ല. ഒരേ VPN സെർവറുള്ള രണ്ട് യന്ത്രങ്ങൾ ഒരു നെറ്റ്വർക്ക് പ്രൊഫൈൽ ഡൊമെയ്ൻ പ്രഖ്യാപിക്കുകയും മറ്റൊന്ന് പ്രഖ്യാപിക്കാതിരിക്കുകയും ചെയ്താൽ വ്യത്യസ്തമായി പെരുമാറാം, അതിനാൽ ഓർമ്മയുള്ള പ്രൊഫൈലല്ല, സജീവമായ പ്രൊഫൈൽ വായിക്കുക.

ഇടുങ്ങിയ അപവാദം ആഗോള പുനഃക്രമീകരണത്തെ തോൽപ്പിക്കുന്നു

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

വിച്ഛേദനത്തെയും അത് അതിജീവിക്കുന്നു, കാരണം ലിങ്ക് തിരികെ വരുമ്പോൾ ലിങ്ക് നയം വീണ്ടും പ്രയോഗിക്കുന്നു. പങ്കിട്ട nsswitch.conf തിരുത്തുന്നത് പ്രലോഭനീയവും ചെലവേറിയതുമായ ബദലാണ്, കാരണം അത് യന്ത്രത്തിലെ എല്ലാ നാമത്തിനും തിരയൽ സ്വഭാവം മാറ്റുന്നു, പ്രാദേശിക കണ്ടെത്തൽ ഉൾപ്പെടെ. multicast ഡീമൺ പ്രവർത്തനരഹിതമാക്കുന്നതും തുല്യമല്ല: അത് പ്രാദേശിക സ്വഭാവം നീക്കം ചെയ്യുന്നു, പക്ഷേ ഒരു റിസോൾവറിനും കോർപ്പറേറ്റ് മേഖല പഠിപ്പിക്കുന്നില്ല. സേവനം പാരമ്പര്യമല്ലാതെ പുതിയതാണെങ്കിൽ, നിങ്ങളുടെ സംഘടന നിയന്ത്രിക്കുന്ന ഒരു സബ്ഡൊമെയ്നിന് കീഴിൽ അത് വയ്ക്കുക, മത്സരം പൂർണ്ണമായി ഒഴിവാക്കുക. നാമം ഫേംവെയറിൽ ഉറപ്പിച്ചതോ ലേബലിൽ അച്ചടിച്ചതോ ആണെങ്കിൽ ഇടുങ്ങിയ അപവാദം തിരഞ്ഞെടുക്കുക, ക്ലയന്റ് ഇപ്പോഴും നിങ്ങൾ നിയന്ത്രിക്കുന്നുവെങ്കിൽ പുതിയ സബ്ഡൊമെയ്ൻ തിരഞ്ഞെടുക്കുക.

മാറ്റത്തിന് ശേഷം എന്താണ് തെളിയിക്കേണ്ടത്

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

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

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