VPN-ൽ NXDOMAIN എന്നത് ടണൽ തകരാറല്ല

ഒരു പരാജയപ്പെട്ട ലുക്കപ്പ് ടണൽ തകർന്നതിന്റെ തെളിവായി വായിക്കാൻ പ്രലോഭനമുണ്ട്, പ്രത്യേകിച്ച് പേര് പത്ത് മിനിറ്റ് മുൻപ് പ്രവർത്തിച്ചിരുന്നെങ്കിൽ. ഉത്തരം മറ്റൊന്ന് പറയുന്നു. NXDOMAIN പൂർത്തിയായ ഒരു DNS ഇടപാടാണ്, അതിൽ റിസോൾവർ ചോദിച്ച പേര് നിലവിലില്ലെന്ന് പ്രഖ്യാപിച്ചു; തകർന്ന ടണൽ സാധാരണയായി നിശ്ശബ്ദത, ടൈംഔട്ട് അല്ലെങ്കിൽ തെറ്റായ സെർവറിനെതിരായ റിസൊല്യൂഷൻ ശ്രമം ഉണ്ടാക്കുന്നു. wireshark ഇല്ലാത്ത വാദരൂപം ഒരു ക്വറി, ഒരു ഉത്തരം നൽകുന്നയാൾ, ഒരു ഉത്തര കോഡ് എന്നിവയാണ്, ഏതെങ്കിലും കോൺഫിഗറേഷൻ മാറ്റത്തിന് മുൻപ് ഈ ത്രികം രേഖപ്പെടുത്താൻ യോഗ്യമാണ്.

ഉത്തരം യഥാർത്ഥത്തിൽ എന്ത് സ്ഥാപിക്കുന്നു

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

ആ വ്യത്യാസം പരിഹാരം എവിടെയാണെന്ന് തീരുമാനിക്കുന്നു. A റെക്കോർഡ് ഉള്ള ഹോസ്റ്റിൽ AAAA റെക്കോർഡ് ഇല്ലാതിരിക്കുന്നത് ഹോസ്റ്റ് ഇല്ലാതിരിക്കലല്ല, അതിനെ പിന്തുടർന്ന് സർട്ടിഫിക്കറ്റ് വീണ്ടും നൽകുന്നതോ ടണൽ വീണ്ടും നിർമ്മിക്കുന്നതോ ലഭ്യമായ ഏക സൂചന പാഴാക്കുന്നു. ഈ വേർതിരിവ് തുടർനടപടിയുടെ രൂപവും നിർണ്ണയിക്കുന്നു: നാമകരണ പ്രശ്നം സോണിൽ പരിഹരിക്കുന്നു, തരം പ്രശ്നം ശരിയായ റെക്കോർഡ് ചോദിച്ചോ വിലാസ കുടുംബം വെറുതെ ഇല്ലെന്ന് സ്വീകരിച്ചോ പരിഹരിക്കുന്നു.

മിത്ത്: സ്വകാര്യ നാമം ഇല്ലാതിരിക്കുന്നത് ടണൽ പരാജയപ്പെട്ടു എന്നാണ്

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

split-horizon ക്രമീകരണങ്ങൾ ഇത് സാധാരണമാക്കുന്നു: ഒരേ സോൺ നാമം പൊതുവിലും ആന്തരികമായും വ്യത്യസ്ത ഉള്ളടക്കത്തോടെ നിലനിൽക്കുന്നു, സ്വകാര്യ റെക്കോർഡുകൾ ആന്തരിക റിസോൾവറിന് മാത്രം അറിയാം. അതിനാൽ അധികാരമുള്ളതായി തോന്നുന്ന നിഷേധാത്മക ഉത്തരം ലഭിക്കുന്നത് ഏത് റിസോൾവർ ഉത്തരം നൽകി എന്നതിന് തെളിവാണ്, ഇന്റർഫേസിന്റെ അവസ്ഥയ്ക്കുള്ള തെളിവല്ല.

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

ശരിയായ നാമത്തോടെ ശരിയായ റിസോൾവറിനോട് ചോദിക്കുക

വിധി രേഖപ്പെടുത്തുന്നതിന് മുൻപ് ഉത്തരം നൽകുന്നയാളെ രേഖപ്പെടുത്തുക. ഏത് സെർവർ ഉത്തരം നൽകി എന്ന് കാണിക്കാത്ത ലുക്കപ്പ് നയ പ്രശ്നവും നാമസ്ഥല പ്രശ്നവും വേർതിരിക്കാൻ കഴിയില്ല, രണ്ടിന്റെയും പരിഹാരങ്ങൾ ബന്ധമില്ലാത്തവയാണ്.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

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

നിഷേധാത്മക കാഷിംഗ് പരിഹാരത്തിന് ശേഷമുള്ള കാലതാമസം വിശദീകരിക്കുന്നു

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

പ്രാദേശിക കാഷ് ശൂന്യമാക്കി, പിന്നീട് അതേ ഉത്തരം നൽകുന്നയാളോട് അതേ ക്വറി ആവർത്തിക്കുക. പ്രാദേശിക റിസോൾവർ സേവനം ഉപയോഗിക്കുന്ന സിസ്റ്റങ്ങളിൽ അത് ഒരു കമാൻഡാണ്; മറ്റുള്ളവയിൽ അത് സേവന പുനരാരംഭമോ പ്ലാറ്റ്ഫോം യൂട്ടിലിറ്റിയോ ആണ്, നിർദ്ദിഷ്ട ഉപകരണത്തേക്കാൾ പിന്നീട് ഒരേ പരിശോധന ആവർത്തിക്കുന്നതാണ് പ്രധാനം.

നാമത്തെ പാതയിൽ നിന്ന് വേർതിരിക്കുക

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

രേഖ സൂക്ഷിക്കുക: ക്വറി, ഉത്തരം നൽകുന്നയാൾ, കോഡ്, റിസോൾവ് ചെയ്ത വിലാസം. ആ രേഖയാണ് പിന്നീടുള്ള റിപ്പോർട്ടിനെ പരിശോധനായോഗ്യമാക്കുന്നത്, അതാണ് രോഗനിർണ്ണയവും മന്ദഗതിയിലെന്ന് തോന്നിയ ടണലിനെക്കുറിച്ചുള്ള കഥയും തമ്മിലുള്ള വ്യത്യാസം.