Split-DNS ക്യാപ്ചർ: ഓരോ നിരീക്ഷണവും എവിടെ നടന്നുവെന്ന് പറയുക

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

ഒരു തിരച്ചിൽ, ഒട്ടേറെ നിരീക്ഷണ കേന്ദ്രങ്ങൾ

ഒരു ആന്തരിക നാമത്തിന് നോക്കാൻ കുറഞ്ഞത് അഞ്ച് സ്ഥലങ്ങളുണ്ട്: അപ്ലിക്കേഷനും അത് വിളിക്കുന്ന resolver API-യും, ക്ലയന്റിലെ പ്രാബല്യത്തിലുള്ള ഡൊമെയിൻ നയം, അഡാപ്റ്ററിലോ ഫിൽട്ടറിലോ ഉള്ള ക്യാപ്ചർ, നിയന്ത്രിത ഗേറ്റ്‌വേ അതിർത്തി, യഥാർത്ഥത്തിൽ ക്വറി സ്വീകരിക്കുന്ന resolver.

ഓരോന്നും വ്യത്യസ്ത ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു, ഒന്നും ഒറ്റയ്ക്ക് ക്വറി എവിടെ പോയെന്ന് തെളിയിക്കുന്നില്ല.

അഡാപ്റ്ററിലെ ക്യാപ്ചർ പാക്കറ്റുകൾ കാണിക്കുന്നു, ഉദ്ദേശ്യമല്ല. ക്ലയന്റ് ഏത് resolver തിരഞ്ഞെടുത്തുവെന്ന് അത് പറയുന്നില്ല, ശൂന്യമായ ക്യാപ്ചർ പാക്കറ്റ് ഉപേക്ഷിച്ചതല്ല, കാഷെ ചെയ്ത ഉത്തരമോ മറ്റൊരു resolver API-യോ ആകാം. ഓരോ നിരീക്ഷണവും ഒരു ഘട്ടത്തിന്റെ തെളിവായി കാണുക. തുടർന്ന് ഘട്ടങ്ങൾ ഒരു പാതയായി കൂട്ടിച്ചേർക്കുക.

ക്ലയന്റിന്റെ ഫിൽട്ടർ ആപ്പിനും വയറിനും ഇടയിലാണ്

Split-DNS ഉള്ള VPN ക്ലയന്റ് പാക്കറ്റ് യന്ത്രം വിടുന്നതിന് മുമ്പ് ഡൊമെയിൻ പൊരുത്തം പ്രയോഗിക്കുന്നു. ടണൽ സഫിക്സിലെ നാമങ്ങൾ ആന്തരിക resolver-ലേക്ക് പോകുന്നു; ബാക്കിയെല്ലാം പ്രാദേശിക resolver-ലേക്ക് പോകുന്നു. ഫിൽട്ടർ നയമാണ്, നയം പ്ലാറ്റ്ഫോമും ക്ലയന്റ് പതിപ്പും അനുസരിച്ച് വ്യത്യാസപ്പെടാം.

Cisco-യുടെ Secure Client Split-DNS മാർഗ്ഗനിർദ്ദേശം ഡൊമെയിൻ പൊരുത്തവും Windows ഫിൽട്ടറും ഉൾക്കൊള്ളുന്നു, ആപ്പ് സ്വദേശീയ resolver API ഉപയോഗിക്കുമ്പോൾ കാണുന്നതും nslookup പോലുള്ള ഉപകരണം കാണുന്നതും അത് വേർതിരിക്കുന്നു. ആ വ്യത്യാസങ്ങളാണ് കാര്യം.

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

nslookup ആപ്പിൽ നിന്ന് വ്യത്യസ്ത പാതയിലൂടെ പോകുന്നു

nslookup സ്വന്തമായി DNS ക്വറി നിർമ്മിക്കുകയും ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ resolver നയം ഒഴിവാക്കുകയും ചെയ്യാം. അത് ഒരു നിർദ്ദിഷ്ട സെർവറിനോട് ഒരു നിർദ്ദിഷ്ട ചോദ്യം ചോദിക്കാൻ ഉപയോഗപ്രദമായ ഉപകരണമാക്കുന്നു, ആപ്പ് എന്ത് അനുഭവിക്കുമെന്ന് പരിശോധിക്കാൻ തെറ്റിദ്ധരിപ്പിക്കുന്ന ഉപകരണവുമാക്കുന്നു.

Windows-ൽ നാമപരിഹാര നയ പട്ടിക ഏത് സഫിക്സ് ഏത് സെർവർ ഉപയോഗിക്കുമെന്ന് തീരുമാനിക്കുന്നു. അത് വായിക്കുമ്പോൾ ആപ്പ് പിന്തുടരുന്ന നയം കാണാം, പലപ്പോഴും അതാണ് കാണാത്ത കഷണം.

നയം വായിച്ച ശേഷം അതേ ചോദ്യം സാധാരണ resolver വഴി ചോദിക്കുക:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

എൻക്രിപ്റ്റ് ചെയ്ത resolver-കൾ ക്വറി മറയ്ക്കുന്നു, കണക്ഷനല്ല

സ്വന്തം DNS-over-HTTPS resolver ഉള്ള ബ്രൗസർ തികച്ചും വ്യത്യസ്തമായ കേസാണ്. ക്വറി TLS-നുള്ളിൽ പുറത്തുപോകുന്നു, അതിനാൽ പാക്കറ്റ് ക്യാപ്ചർ resolver വിലാസത്തിലേക്കുള്ള കണക്ഷൻ കാണിക്കും, ചോദിക്കുന്ന നാമം കാണിക്കില്ല.

ആദ്യം ബ്രൗസറിന്റെ മാനേജ്ഡ് നയം കണ്ടെത്തുക, പിന്നീട് അതിനെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം തിരച്ചിലുമായി താരതമ്യം ചെയ്യുക. സ്വന്തം resolver തിരഞ്ഞെടുക്കാൻ അനുവാദമുള്ള ബ്രൗസർ Split-DNS നയം ഒട്ടും കാണാതിരിക്കാം.

അതേ മുൻകരുതൽ സ്വന്തം resolver കൊണ്ടുവരുന്ന ഏത് ക്ലയന്റിനും ബാധകമാണ്. ദൂര കണക്ഷൻ തിരിച്ചറിയുന്ന ക്യാപ്ചർ ക്വറി നാമത്തിന്റെ തെളിവല്ല. നാമം വേണമെങ്കിൽ, resolver-ന്റെ സ്വന്തം ലോഗുകളിൽ നിന്നോ ആപ്പിന്റെ ഡയഗ്നോസ്റ്റിക്സിൽ നിന്നോ എടുക്കുക, ബാധകമായ സ്വകാര്യതാ നിയമങ്ങളോടെ.

ലേബൽ ചെയ്ത പരിശോധനയുമായി താരതമ്യം ചെയ്യുക

പരിശോധനയ്ക്ക് അംഗീകൃത ആന്തരിക നാമം, കൂടാതെ സംവേദനക്ഷമമായ അർത്ഥമില്ലാത്ത പൊതു നാമം എന്നിവ തിരഞ്ഞെടുക്കുക. ഓരോന്നിനും സമയം, റെക്കോർഡ് തരം, ഉത്തരം, പ്രതീക്ഷിച്ച നയം എന്നിവ രേഖപ്പെടുത്തുക.

അനുവദനീയമായിടത്ത്, resolver-ന്റെ സ്വീകരണം ഒരു ഇടുങ്ങിയ ക്ലയന്റ് അല്ലെങ്കിൽ ഗേറ്റ്‌വേ നിരീക്ഷണവുമായി താരതമ്യം ചെയ്യുക:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

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