VPN വഴി SQL Server പേരിട്ട ഇൻസ്റ്റൻസ്: പോർട്ട് 1433 അല്ല, കണ്ടെത്തൽ

മിക്ക ആളുകളും SQL Server ഹോസ്റ്റ്നെയിമിനെ പൂർണ്ണ വിലാസമായും VPN-നെ അനുവദിച്ചതോ അല്ലാത്തതോ ആയ ഒന്നായും കാണുന്നു. യഥാർത്ഥത്തിൽ പേരിട്ട ഇൻസ്റ്റൻസ് ക്ലയന്റിനെ DNS-ന് ശേഷം രണ്ടാമത്തെ തിരയൽ നടത്താൻ നിർബന്ധിക്കുന്നു, ടണൽ ഏറ്റവും കൂടുതൽ തകർക്കുന്നത് ആ തിരയലാണ്. വ്യക്തമായ എൻഡ്പോയിന്റ് അത് ഒഴിവാക്കുന്നു, അതിനാൽ tcp:host,port പ്രവർത്തിക്കുമ്പോൾ host\INSTANCE സമയം കഴിയാം. വ്യത്യാസം സേവനം കണ്ടെത്തുന്നതിനും അത് ഉപയോഗിക്കാനുള്ള അനുമതി ലഭിക്കുന്നതിനും ഇടയിലാണ്.

മിഥ്യ: ഒരു ഹോസ്റ്റ്നെയിം എന്നാൽ ഒരു പോർട്ട്

ഹോസ്റ്റ്നെയിം ഒരു വിലാസമായി പരിഹരിക്കപ്പെടുന്നു, അവിടെ അതിന്റെ ജോലി അവസാനിക്കുന്നു. പേരിട്ട ഇൻസ്റ്റൻസ് സെർവർ TCP പോർട്ടിലേക്ക് വിവർത്തനം ചെയ്യേണ്ട ഇൻസ്റ്റൻസ് നാമം ചേർക്കുന്നു, ക്ലയന്റിന് അത് ഊഹിക്കാൻ കഴിയില്ല. പോർട്ട് 1433 ഡിഫോൾട്ട് ഇൻസ്റ്റൻസിന്റെ ഡിഫോൾട്ടാണ്, മെഷീനിലെ ഓരോ ഇൻസ്റ്റൻസിന്റെയും സ്വത്തല്ല. രണ്ടും ഒരേ കാര്യമായി കാണുമ്പോൾ ക്ലാസിക് ലക്ഷണം ഉണ്ടാകുന്നു: ping പ്രവർത്തിക്കുന്നു, DNS പ്രവർത്തിക്കുന്നു, 1433 സ്കാൻ ഒന്നും കാണിക്കുന്നില്ല, ഒപ്പം നെറ്റ്വർക്ക് SQL തടയുന്നു എന്നതാണ് നിഗമനം.

രണ്ടാമത്തെ അനുമാനവും അതേ രീതിയിൽ പരാജയപ്പെടുന്നു: TCP 1433 തുറന്നാൽ മതി എന്നത്. ഇൻസ്റ്റൻസ് മറ്റെവിടെയെങ്കിലും കേൾക്കുന്നെങ്കിൽ, തുറന്ന 1433 അവിടെ മറ്റെന്തോ ഉണ്ടെന്ന് മാത്രം തെളിയിക്കുന്നു. പോർട്ട് ശ്രോതാവുമായി പൊരുത്തപ്പെടണം, ശ്രോതാവ് സെർവർ ഭാഗത്തെ കോൺഫിഗറേഷൻ വിശദാംശമാണ് എന്ന് ഇത് ഊഹിക്കുന്നതിന് പകരം ചോദിക്കണം.

ക്ലയന്റ് പേരിട്ട ഇൻസ്റ്റൻസിനൊപ്പം യഥാർത്ഥത്തിൽ എന്ത് ചെയ്യുന്നു

ഹോസ്റ്റ് പരിഹരിച്ച ശേഷം ക്ലയന്റ് UDP 1434-ൽ SQL Server Browser-ന് കണ്ടെത്തൽ അഭ്യർത്ഥന അയച്ച് പേരിട്ട ഇൻസ്റ്റൻസ് ഏത് പോർട്ട് ഉപയോഗിക്കുന്നു എന്ന് ചോദിക്കുന്നു. ബ്രൗസർ സേവനം സെർവറിന്റെ സ്വന്തം രജിസ്ട്രിയിൽ നിന്ന് ഉത്തരം നൽകുന്നു, തുടർന്ന് ക്ലയന്റ് ആ പോർട്ടിലേക്ക് TCP കണക്ഷൻ തുറക്കുന്നു. ലോഗിൻ ശ്രമിക്കുന്നതിന് മുൻപ് തന്നെ രണ്ട് പ്രോട്ടോക്കോളുകളും രണ്ട് പോർട്ടുകളും ഉൾപ്പെടുന്നു.

nslookup sqlhost.corp.example
nc -vzu sqlhost.corp.example 1434
Get-Service -Name SQLBrowser

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

ബ്രൗസർ സേവനം കണ്ടെത്തലിനുള്ള സൗകര്യമാണ്, ഡാറ്റാബേസല്ല. അത് നിർത്തിയാൽ എഞ്ചിൻ നിൽക്കില്ല, തുടങ്ങിയാൽ ഇൻസ്റ്റൻസിന്റെ TCP പോർട്ട് തുറക്കുകയുമില്ല.

പേര് പ്രവർത്തിക്കാത്തപ്പോൾ വ്യക്തമായ എൻഡ്പോയിന്റ് എന്തുകൊണ്ട് പ്രവർത്തിക്കുന്നു

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

sqlcmd -S "tcp:sqlhost.corp.example,51433" -U app_login -Q "SELECT @@SERVERNAME"
Test-NetConnection sqlhost.corp.example -Port 51433

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

ഏത് രൂപവും പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ, പ്രശ്നം കണ്ടെത്തലിന് മേലെയാണ്. ബ്രൗസർ സേവനത്തെ കുറ്റപ്പെടുത്തുന്നതിന് മുൻപ് ശ്രോതാവ്, റൂട്ട്, ഇൻസ്റ്റൻസ് യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന പോർട്ടിന്റെ ആക്സസ് നിയമം എന്നിവ പരിശോധിക്കുക.

കണ്ടെത്തലിന് ശേഷം: പ്രാമാണീകരണവും ഐഡന്റിറ്റിയും വെവ്വേറെ

ലോഗിൻ പരാജയം സമയപരിധിയിൽ നിന്ന് വ്യത്യസ്ത സംഭവമാണ്, ടണൽ ഉള്ളതിനാൽ VPN ഐഡന്റിറ്റി SQL ലോഗിൻ ആകുന്നില്ല. ക്ലയന്റ് ശരിയായ പോർട്ടിൽ എത്തിയാൽ, ഡാറ്റാബേസ് എഞ്ചിൻ അതിന്റേതായ പ്രാമാണീകരണവും അനുമതികളും പ്രയോഗിക്കുന്നു. രണ്ട് ഘട്ടങ്ങൾ ഒരു ടിക്കറ്റിൽ കലർത്തുന്നതാണ് കണ്ടെത്തൽ പ്രശ്നം തെറ്റായ ടീമിന് നൽകുന്ന വഴി. എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് പിശക് നമ്പർ വായിക്കുക.

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

ഉപേക്ഷിക്കേണ്ട മിഥ്യ SQL Server ഹോസ്റ്റ്നെയിം ഒരു പൂർണ്ണ വിലാസമാണ് എന്നതാണ്. അത് ഒരു ഹോസ്റ്റാണ്, പേരിട്ട ഇൻസ്റ്റൻസിന് ടണൽ കൊണ്ടുപോയെന്ന് വരാത്ത ഒരു തിരയൽ കൂടി ചേരുന്നു. പോർട്ട് പേരിടുക, കണ്ടെത്തൽ പാത പേരിടുക, അടുത്ത പരാജയം ഏത് പാളി ശരിയാക്കണം എന്ന് പറയും.