പൊതു DNS പ്രവർത്തിക്കുന്നത് Active Directory കണ്ടെത്താനാകും എന്ന് അർത്ഥമാക്കുന്നില്ല

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

മിത്ത്: പേരുകൾ പരിഹരിക്കുന്നു, അതിനാൽ DNS കഴിഞ്ഞു

ഒരു പൊതു സൈറ്റ് പരിഹരിക്കുന്നു എന്നത് ഏതെങ്കിലും റിസോൾവർ പൊതു സോണിലെ ഒരു പേരിനുള്ള ഒരു A അല്ലെങ്കിൽ AAAA ചോദ്യത്തിന് ഉത്തരം നൽകി എന്ന് മാത്രം പറയുന്നു. Active Directory അതേ പ്രോട്ടോക്കോൾ മറ്റൊരു ചോദ്യത്തിന് ഉപയോഗിക്കുന്നു: ഡൊമെയ്നിലെ സേവനങ്ങൾ എവിടെയാണ്, ഈ ക്ലയന്റ് ഏത് കൺട്രോളർ ഉപയോഗിക്കണം. ചോദ്യം ഡൊമെയ്നിന്റെ പേരിലുള്ള സോണിന് കീഴിൽ SRV റെക്കോർഡുകളായി പ്രകടിപ്പിക്കുന്നു, ആവർത്തന പൊതു റിസോൾവറിന് അവ സൂക്ഷിക്കാൻ കാരണമില്ല.

റെക്കോർഡ് ഇല്ലാത്തപ്പോൾ റിസോൾവർ നിഷേധാത്മക ഉത്തരം നൽകുന്നു, അത് തടസ്സമല്ല, സാധുവായ DNS ഉത്തരമാണ്. തുടർന്ന് ക്ലയന്റ് കൈയിൽ ഉണ്ടെങ്കിൽ കാഷെ ചെയ്ത കൺട്രോളർ വിവരങ്ങളിലേക്ക് മടങ്ങുന്നു, അതുകൊണ്ടാണ് ഡെസ്ക്ടോപ്പ് മണിക്കൂറുകളോളം നന്നായി തോന്നി റീബൂട്ടിനോ പാസ്വേഡ് മാറ്റത്തിനോ ശേഷം പരാജയപ്പെടുന്നത്.

ഡൊമെയ്ൻ ക്ലയന്റ് യഥാർത്ഥത്തിൽ എന്ത് ആവശ്യപ്പെടുന്നു, ക്രമത്തിൽ

corp.example പോലുള്ള ഡൊമെയ്നിന് പൊതു ലൊക്കേറ്റർ ചോദ്യം _ldap._tcp.dc._msdcs.corp.example ആണ്. SRV ഉത്തരങ്ങൾ സാധ്യതയുള്ള കൺട്രോളറുകളെയും അവയുടെ പോർട്ടുകളെയും പേരിടുന്നു, തുടർന്ന് കണക്ഷൻ തുറക്കുന്നതിന് മുമ്പ് ആ ഹോസ്റ്റ് നാമങ്ങൾക്ക് വിലാസ റെക്കോർഡുകൾ ക്ലയന്റിന് വേണം. സൈറ്റ് അറിയുന്ന കണ്ടെത്തൽ സൈറ്റ് ഉപഡൊമെയ്നിന് കീഴിൽ ചോദ്യങ്ങൾ ചേർക്കുന്നു, ഉത്തരങ്ങൾ ഏത് കൺട്രോളറുകളാണ് മുൻഗണനയെന്ന് നിർണ്ണയിക്കുന്നു, ഏതാണ് നിർബന്ധമെന്നല്ല.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

പ്രശ്നം ഉണ്ടാകുന്ന നെറ്റ്വർക്കിൽ നിന്ന് ആ ക്രമത്തിൽ ശൃംഖല പിന്തുടരുക. എത്തിച്ചേരാനാകാത്ത വിലാസത്തിലേക്ക് പരിഹരിക്കുന്ന ഹോസ്റ്റ് നാമം റൂട്ടിംഗ് പരാജയമാണ്, DNS പരാജയമല്ല. ലൊക്കേറ്റർ റെക്കോർഡുകൾ ഇല്ലാത്ത എത്തിച്ചേരാവുന്ന കൺട്രോളർ DNS പരാജയമാണ്, റൂട്ടിംഗ് പരാജയമല്ല. രണ്ടും സമാന ഉപയോക്തൃ പരാതികളും തികച്ചും വ്യത്യസ്ത അറ്റകുറ്റപ്പണികളും ഉണ്ടാക്കുന്നു.

പൊതു റിസോൾവർ ഉത്തരം നൽകിയിട്ടും സൈൻ-ഇൻ എന്തുകൊണ്ട് തകരുന്നു

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

രണ്ട് ആന്തരിക റിസോൾവറുകൾ ഉണ്ടെങ്കിൽ രണ്ടും AD നാമസ്ഥലം സൂക്ഷിക്കുകയും ക്ലയന്റിന്റെ നിലവിലെ നെറ്റ്വർക്കിൽ നിന്ന് എത്താവുന്നതുമാകണം. വിഭജിത ടണൽ രൂപകൽപ്പനകൾ തകർക്കുന്നത് ഇവിടെയാണ്: VPN ടണലിന്റെ ഉപനെറ്റ്വർക്ക് വഹിച്ചേക്കാം, എന്നാൽ ആന്തരിക റിസോൾവർ ടണൽ റൂട്ട് ചെയ്യാത്ത പ്രിഫിക്സിലാണെങ്കിൽ ചോദ്യം ഉത്തരം നൽകാനാകാത്ത റിസോൾവറിലേക്ക് പോകുന്നു.

Windows നിർദ്ദിഷ്ട നാമസ്ഥലങ്ങളെ നിർദ്ദിഷ്ട സെർവറുകളിലേക്ക് അയക്കാവുന്ന നാമ പരിഹാര നയവും പ്രയോഗിക്കുന്നു, അഡാപ്റ്റർ കാണിക്കുന്ന DNS വിലാസങ്ങൾ മുഴുവൻ കഥയല്ല. ആ നയം മാറ്റാതെ അഡാപ്റ്റർ പട്ടിക മാറ്റിയാൽ ഫലപ്രദമായ കോൺഫിഗറേഷൻ തൊടാതെ നിൽക്കാം, അതുകൊണ്ടാണ് പ്രയോഗിച്ചതായി തോന്നുന്ന തിരുത്തിന് ഫലമില്ലാത്തത്.

ടണലിന്റെ DNS-ഉം അതിന്റെ റൂട്ടുകളും യോജിപ്പിൽ നിർത്തുക

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

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

ഒരു കണ്ടെത്തൽ വിളിയും ഒരു ജീവനുള്ള പ്രവർത്തനവും കൊണ്ട് സ്വീകരിക്കുക

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

Microsoft-ന്റെ DNS ക്ലയന്റിനുള്ള ശുപാർശകൾ ആന്തരിക നാമസ്ഥലം പരിഹരിക്കുന്നതിനും പൊതു ചോദ്യങ്ങൾ മുകളിലേക്ക് കൈമാറുന്നതിനും ഇടയിൽ അതേ രേഖ വരയ്ക്കുന്നു, VPN ഏർപ്പെടുത്തുമ്പോൾ സംരക്ഷിക്കേണ്ട ക്രമീകരണം അതാണ്.

പരാജയം മന്ദഗതിയിലുള്ളത് മാത്രമാണെങ്കിൽ, പരാജയപ്പെട്ടതല്ലെങ്കിൽ, കാലതാമസം രോഗനിർണ്ണയത്തിൽ നിന്ന് വേർതിരിച്ച് നിർത്തുക. കണ്ടെത്തലിനിടയിലെ സമയപരിധി എത്താനാകാത്ത കൺട്രോളറിൽ നിന്നോ തടഞ്ഞ പോർട്ടിൽ നിന്നോ വൈകി ഉത്തരം നൽകുന്ന റിസോൾവറിൽ നിന്നോ വരാം, അവയൊന്നും കാത്തിരിപ്പ് കൊണ്ട് മാത്രം തെളിയുന്നില്ല. റിസോൾവർ ക്രമീകരണം മാറ്റുന്നതിന് മുമ്പ് യഥാർത്ഥ ചോദ്യവും അതിന്റെ ഉത്തരവും ബന്ധന ശ്രമവും രേഖപ്പെടുത്തുക.