ഡയൽ-ഇന്നിന് ശേഷം സർവറിന്റെ പേര് അതിന്റെ VPN വിലാസത്തിലേക്ക് എന്തുകൊണ്ട് റിസോൾവ് ചെയ്യുന്നു

ഒരു ഓഫീസ് ഫയൽ സർവർ രാവിലെ മുഴുവൻ തന്റെ LAN വിലാസത്തിൽ പ്രതികരിക്കുന്നു, പിന്നീട് ഒരു ദൂരസ്ഥ ഉപയോക്താവ് ഡയൽ-ഇൻ ചെയ്യുന്നു, പേര് പകരം ടണൽ വിലാസത്തിലേക്ക് റിസോൾവ് ചെയ്യാൻ തുടങ്ങുന്നു. DNS-ൽ കൈകൊണ്ട് ഒന്നും തിരുത്തിയിട്ടില്ല, അതാണ് സൂചന: റെക്കോർഡ് പ്രസിദ്ധീകരിച്ചത് യന്ത്രം തന്നെയാണ്. രജിസ്ട്രാറർ, റെക്കോർഡ്, അല്ലെങ്കിൽ ക്ലയന്റിന്റെ കാഴ്ച എന്നിവയിൽ ഏതാണ് ശരിയാക്കേണ്ടതെന്ന് മൂന്ന് വ്യവസ്ഥകൾ തീരുമാനിക്കുന്നു, ക്രമം തെറ്റിയാൽ അടുത്ത കണക്ഷന് ശേഷം റെക്കോർഡ് തിരികെ വരും.

രണ്ട് വിലാസങ്ങൾ, ഒരു പേര്, മൂന്ന് വ്യവസ്ഥകൾ

മൾട്ടിഹോംഡ് Windows സർവറിന് ഒരു LAN വിലാസം, ഒന്നോ അതിലധികമോ ഡയൽ-ഇൻ വിലാസങ്ങൾ, ചിലപ്പോൾ രണ്ടാമത്തെ നെറ്റ്വർക്ക് കാർഡ് എന്നിവ ഉണ്ടാകാം. ഓരോ ഇന്റർഫേസിനും ഡൈനാമിക് രജിസ്ട്രേഷൻ അനുവദിച്ചിട്ടുണ്ടെങ്കിൽ അതിന്റെ വിലാസങ്ങൾ DNS-ൽ രജിസ്റ്റർ ചെയ്യാം. PPP അഡാപ്റ്റർ രജിസ്റ്റർ ചെയ്യുമ്പോൾ, അതേ ഹോസ്റ്റ് പേരിന് ടണൽ പങ്കാളിക്ക് മാത്രം എത്തിച്ചേരാവുന്ന ഒരു വിലാസം ലഭിക്കുന്നു, LAN ക്ലയന്റുകൾ അത് സാധുവായ ഉത്തരമായി സ്വീകരിക്കുന്നു.

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

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

രജിസ്ട്രാറർ മാറ്റുന്നതിന് മുമ്പ് റെക്കോർഡ് വായിക്കുക

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

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

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

റെക്കോർഡിന്റെ ടൈംസ്റ്റാമ്പും DNS കൺസോൾ അതിനെ ഡൈനാമിക് ആയി കാണിക്കുന്നുണ്ടോ എന്നതും എഴുതിവയ്ക്കുക. ആ ഒരു ഗുണം മുകളിലെ മൂന്ന് വ്യവസ്ഥകളിൽ ഏതാണ് ബാധകമെന്ന് പറയുന്നു, അതാണ് അഞ്ച് മിനിറ്റ് വൃത്തിയാക്കലും നിലനിൽക്കുന്ന അറ്റകുറ്റപ്പണിയും തമ്മിലുള്ള വ്യത്യാസം.

പ്രസിദ്ധീകരിക്കുന്നയാളെയോ റെക്കോർഡിനെയോ ശരിയാക്കുക, പക്ഷേ ഏതെന്ന് അറിയുക

റെക്കോർഡ് ഡൈനാമിക് ആണെങ്കിൽ ആ ഇന്റർഫേസ് രജിസ്റ്റർ ചെയ്യുന്നത് തടയുകയാണ് ശാശ്വത പരിഹാരം. Windows ഓരോ ഇന്റർഫേസിനും രജിസ്ട്രേഷൻ ക്രമീകരണങ്ങൾ നൽകുന്നു, DNS ക്ലയന്റ് സേവനം അടുത്ത കണക്ഷനിലോ വിലാസ മാറ്റത്തിലോ വീണ്ടും പ്രസിദ്ധീകരിക്കുന്നു. ഡയൽ-ഇൻ അഡാപ്റ്ററിന്റെ രജിസ്ട്രേഷൻ ഓഫാക്കിയാൽ LAN അഡാപ്റ്ററിന്റെ രജിസ്ട്രേഷൻ അതേപടി നിൽക്കും, സാധാരണയായി അതാണ് ആവശ്യം.

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

റെക്കോർഡ് സ്റ്റാറ്റിക് ആണെങ്കിൽ, അത് ബോധപൂർവം അവിടെ സ്ഥാപിച്ചതാണ്, സംഭാഷണം അത് സ്ഥാപിച്ചയാളുമായാണ്. ഇന്ന് അസൗകര്യമാണെന്ന കാരണത്താൽ സ്റ്റാറ്റിക് റെക്കോർഡ് മായ്ക്കുന്നത് അത് എന്തുകൊണ്ട് നിലനിൽക്കുന്നു എന്നതിന്റെ ഏക തെളിവ് നീക്കം ചെയ്യുന്നു. രണ്ട് സന്ദർഭങ്ങളിലും പ്രസിദ്ധീകരിക്കുന്നയാളെ കൈകാര്യം ചെയ്ത ശേഷം മാത്രം പഴയ ഉത്തരം മായ്ക്കുക, എന്താണ് മാറ്റിയതെന്ന് രേഖപ്പെടുത്തുക, അടുത്ത വ്യക്തിക്ക് ബോധപൂർവമായ എൻട്രിയും അപകടവും വേർതിരിക്കാനാകും.

പരാജയപ്പെട്ട ക്ലയന്റ് നെറ്റ്വർക്കിൽ നിന്ന് പരിശോധിക്കുക

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

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

ആദ്യ കമാൻഡ് Windows റിസോൾവർ കാഷെ മായ്ക്കുന്നു, രണ്ടാമത്തേത് പേര് വീണ്ടും കാഷെ ചെയ്തോ ഏത് വിലാസം സംഭരിച്ചോ എന്ന് കാണിക്കുന്നു. സർവറിന്റെ സ്വയം കണക്ഷൻ വിജയിക്കുന്നത് LAN ക്ലയന്റിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല, അനാവശ്യ വിലാസത്തിലേക്കുള്ള റൂട്ട് നീക്കുന്നത് DNS പ്രസിദ്ധീകരിക്കുന്നത് ശരിയാക്കുന്നുമില്ല.

അവസാനമായി, മുമ്പ് വിലാസം കൊണ്ടുവന്നിരുന്ന സംഭവം ആവർത്തിക്കുക: VPN ക്ലയന്റ് വീണ്ടും കണക്ട് ചെയ്യുക, അല്ലെങ്കിൽ ഡയൽ-ഇൻ സെഷൻ പുതുക്കുക. ആ ജീവിതചക്ര മാറ്റത്തിന് ശേഷം പ്രസിദ്ധീകരിച്ച പേര് വീണ്ടും പരിശോധിക്കുക. അടുത്ത കണക്ഷൻ വരെ മാത്രം നിലനിൽക്കുന്ന അറ്റകുറ്റപ്പണി വൃത്തിയാക്കലാണ്, അറ്റകുറ്റപ്പണിയല്ല, ഏതാണ് ചെയ്തതെന്ന് അറിയുന്നതാണ് ടിക്കറ്റ് അടയ്ക്കുന്നതും അടുത്ത ആഴ്ച വീണ്ടും തുറക്കുന്നതും തമ്മിലുള്ള വ്യത്യാസം.