SQL Server ബൂട്ട് സമയത്ത് ഇല്ലാത്ത VPN വിലാസത്തിലേക്ക് ബൈൻഡ് ചെയ്യുന്നു

സേവനം ഇപ്പോഴും പ്രവർത്തിക്കുമ്പോൾ പരാജയപ്പെട്ട ബൈൻഡിനെക്കുറിച്ചുള്ള SQL Server ലോഗ് വരി വായിക്കുക, അപ്പോൾ നിങ്ങൾ ക്രാഷല്ല, ബൂട്ട് ക്രമത്തിലുള്ള ആശ്രിതത്വം കണ്ടെത്തി. ആ കോമ്പിനേഷനാണ് സൂചന: എഞ്ചിൻ കേൾക്കാൻ നിർദ്ദേശിച്ച വിലാസം മെഷീനിൽ നിലനിൽക്കുന്നതിന് മുമ്പേ അത് ആരംഭിച്ചു. സൈൻ-ഇന് ശേഷം ഉയർന്നുവരുന്ന VPN അഡാപ്റ്റർ മേൽനോട്ടമില്ലാത്ത ഡാറ്റാബേസ് സേവനത്തിന് മോശം മുൻവ്യവസ്ഥയാണ്, അതിനാൽ എഞ്ചിൻ കാണുന്ന ക്രമത്തിൽ പരാജയം പിന്തുടരുക.

ക്ലയന്റിൽ നിന്നല്ല, സ്റ്റാർട്ടപ്പ് ലോഗിൽ നിന്ന് ആരംഭിക്കുക

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

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixOrigin
Get-Content 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\LOG\ERRORLOG' -Tail 40

ഇൻസ്റ്റൻസിന്റെ പാത നിങ്ങളുടെ ഇൻസ്റ്റാളേഷനുമായി യോജിപ്പിക്കുക, നിഗമനങ്ങളിൽ എത്തുന്നതിന് മുമ്പ് ഇന്റർഫേസ് പട്ടിക വായിക്കുക. നിലവിലുള്ളതെങ്കിലും തെറ്റായ അഡാപ്റ്ററുടേതായ വിലാസം ഇപ്പോഴും ഇല്ലാത്ത വിലാസത്തിൽ നിന്ന് വ്യത്യസ്ത പ്രശ്നമാണ്.

എഞ്ചിൻ യഥാർത്ഥത്തിൽ പിന്തുടരുന്ന ബൈൻഡ് ക്രമം നടക്കുക

എഞ്ചിൻ അതിന്റെ ശ്രോതാവ് കോൺഫിഗറേഷൻ വായിച്ച് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തോട് ബൈൻഡ് ചെയ്യാൻ ആവശ്യപ്പെടുന്നു. ആ നിമിഷം വിലാസം പ്രാദേശികമല്ലെങ്കിൽ ആ വിലാസത്തിന് ബൈൻഡ് പരാജയപ്പെടും, ബാക്കി ഇൻസ്റ്റൻസ് സാധാരണയായി തുടരാം. അതുകൊണ്ടാണ് മറ്റ് പ്രോട്ടോക്കോളുകൾക്കോ വിലാസങ്ങൾക്കോ ഇപ്പോഴും പ്രവർത്തിക്കാൻ കഴിയുന്നത്, അതുകൊണ്ടാണ് „SQL Server ഡൗൺ ആണ്“ തെറ്റായ സാരാംശമാകുന്നത്. ലോഗിൽ നിന്ന് കൃത്യമായ അന്തിമ പോയിന്റ് സൂക്ഷിക്കുക: വിലാസം, പോർട്ട്, പ്രോട്ടോക്കോൾ, കാരണം പരിഹാരം മൂന്നിൽ ഏതാണ് തെറ്റെന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.

അഡാപ്റ്റർ പ്രത്യക്ഷപ്പെട്ടതിന് ശേഷം സേവനം പുനരാരംഭിക്കുന്നത് സാധാരണയായി ശ്രോതാവിനെ വിജയിപ്പിക്കും, അതാണ് കെണി. അത് ആശ്രിതത്വം നീക്കുന്നതിന് പകരം തെളിയിക്കുന്നു, ടണൽ വീണ്ടും ബന്ധിപ്പിക്കുമ്പോഴെല്ലാം ബന്ധിപ്പിച്ചിരിക്കുന്ന ഓരോ ഉപയോക്താവിനെയും വിച്ഛേദിക്കുന്നു.

എഞ്ചിൻ വായിക്കുന്നതുപോലെ ശ്രോതാവിനെ വായിക്കുക

SQL Server Configuration Manager-ൽ ഇൻസ്റ്റൻസിന്റെ TCP/IP ഗുണങ്ങൾ തുറന്ന് വ്യക്തിഗത വിലാസങ്ങൾ തിരുത്തുന്നതിന് മുമ്പ് Listen All ക്രമീകരണം ശ്രദ്ധിക്കുക. Listen All Yes ആകുമ്പോൾ ഓരോ വിലാസത്തിന്റെയും Enabled മൂല്യങ്ങൾ അവഗണിക്കപ്പെടും, അതിനാൽ അവ തിരുത്തുന്നത് ശ്രോതാവ് ഉപയോഗിക്കുന്ന ഒന്നും മാറ്റില്ല. ക്രമത്തിൽ മൂന്ന് കാര്യങ്ങൾ രേഖപ്പെടുത്തുക: നിങ്ങൾ സേവിക്കാൻ ഉദ്ദേശിക്കുന്ന വിലാസം, പോർട്ട്, ശ്രോതാവ് എല്ലാ വിലാസങ്ങളും അതോ ഒന്ന് മാത്രമോ ഉൾക്കൊള്ളണമോ. തുടർന്ന് പിന്തുണയ്ക്കുന്ന പുനരാരംഭ നടപടിക്രമത്തിലൂടെ മാറ്റം പ്രയോഗിച്ച്, എഞ്ചിൻ നിങ്ങൾ ആവശ്യപ്പെട്ടത് ബൈൻഡ് ചെയ്തുവെന്ന് സ്ഥിരീകരിക്കാൻ അടുത്ത സ്റ്റാർട്ടപ്പ് ലോഗ് വായിക്കുക.

എല്ലാ വിലാസത്തിലും കേൾക്കുന്നത് ആക്സസ് നിയന്ത്രണമല്ല. ശരിക്കും വിശാലമായ ശ്രോതാവ് ആവശ്യമെങ്കിൽ, ഓരോ എത്തിച്ചേരാവുന്ന ഇന്റർഫേസിനും സ്വന്തം ഫയർവാൾ, ഡാറ്റാബേസ് അനുമതി തീരുമാനം വേണം, ഇന്റർനെറ്റിന് അഭിമുഖമായ ഏത് ഇന്റർഫേസും ഉൾപ്പെടെ.

ക്ലയന്റിന് സ്ഥിരമായ ലക്ഷ്യം നൽകുക

ഡാറ്റാബേസ് ഹോസ്റ്റ് പൂൾ വിലാസം ധരിക്കേണ്ടതില്ല. റൂട്ട് ചെയ്ത രൂപകൽപ്പനയിൽ സർവർ അതിന്റെ സ്ഥിരമായ സ്വകാര്യ വിലാസത്തിൽ കേൾക്കുമ്പോൾ VPN ഗേറ്റ്വേ ക്ലയന്റിന്റെ ട്രാഫിക് അതിലേക്ക് കൈമാറി മറുപടി തിരികെ കൊണ്ടുവരുന്നു.

Test-NetConnection -ComputerName 10.80.0.15 -Port 1433
tracert -d 10.80.0.15

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

ക്ലയന്റ് ഉപയോഗിച്ച അന്തിമ പോയിന്റ് പരിശോധിക്കുക

പോർട്ട് പരിശോധനയ്ക്ക് പകരം ആപ്ലിക്കേഷൻ തലത്തിലുള്ള പരിശോധനയോടെ അവസാനിക്കുക. ആപ്ലിക്കേഷൻ ഉപയോഗിക്കുന്ന അക്കൗണ്ടുമായി ക്ലയന്റിൽ നിന്ന് ബന്ധിപ്പിച്ച് സർവർ വശത്തെ കണക്ഷൻ വിശദാംശങ്ങൾ വായിക്കുക, നിങ്ങളുടെ സെഷൻ എത്തിയ പ്രാദേശിക വിലാസം അവ കാണിക്കുന്നു.

sqlcmd -S tcp:10.80.0.15,1433 -Q "SELECT local_net_address, local_tcp_port FROM sys.dm_exec_connections WHERE session_id = @@SPID"

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