VPN വഴി SQL: നേരിട്ടുള്ള ക്ലയന്റ് അതോ ആന്തരിക വർക്ക്സ്റ്റേഷൻ അതോ?

ടീമുകൾക്ക് അവരുടെ ലാപ്ടോപ്പുകളിൽ SSMS വേണം, വേഗത്തിലുള്ള പരിഹാരം SQL പോർട്ട് VPN പൂളിൽ പ്രസിദ്ധീകരിക്കുകയാണ്. മന്ദഗതിയിലുള്ള ഉത്തരം ക്ലയന്റ് പ്രക്രിയ എവിടെ പ്രവർത്തിക്കണം എന്ന് ചോദിക്കുന്നു, കാരണം നേരിട്ടുള്ള ആക്സസും ആന്തരിക വർക്ക്സ്റ്റേഷനും വ്യത്യസ്ത സ്രോതസ്സ് വിലാസങ്ങളും എൻഡ്പോയിന്റ് വിശ്വാസവും ഡാറ്റാ പാതകളും സൃഷ്ടിക്കുന്നു. രണ്ടും സ്വയമേവ സുരക്ഷിതമല്ല, കേവലം VPN അംഗത്വം ഒന്നും തീരുമാനിക്കുന്നില്ല. അനുമതി നിയമം നിലവിൽ വരുന്നതിന് മുമ്പ് രൂപകൽപ്പനകൾ താരതമ്യം ചെയ്യുക.

രണ്ട് പാതകൾ, രണ്ട് സ്രോതസ്സ് വിലാസങ്ങൾ

നേരിട്ടുള്ള ആക്സസിൽ ലാപ്ടോപ്പ് ക്ലയന്റ് കോൺഫിഗറേഷൻ വഹിക്കുകയും ഡാറ്റാബേസ് കണക്ഷൻ സ്വയം തുറക്കുകയും ചെയ്യുന്നു. റിമോട്ട് വർക്ക്സ്റ്റേഷനിൽ ലാപ്ടോപ്പ് ഒരു ഡെസ്ക്ടോപ്പ് സെഷൻ തുറക്കുന്നു, വർക്ക്സ്റ്റേഷൻ സ്വന്തം വിലാസത്തിൽ നിന്ന് SQL കണക്ഷൻ നടത്തുന്നു. അതിനാൽ ആദ്യ രൂപകൽപ്പനയിൽ ഡാറ്റാബേസ് VPN പൂളോ വിവർത്തനം ചെയ്ത ഗേറ്റ്വേയോ കാണുന്നു, രണ്ടാമത്തേതിൽ വർക്ക്സ്റ്റേഷന്റെ വിലാസം കാണുന്നു. ഈ വ്യത്യാസമാണ് ഏത് ഫയർവാൾ നിയമവും ഏത് SQL അനുമതിയും യഥാർത്ഥത്തിൽ ബാധകമാകുന്നു എന്ന് തീരുമാനിക്കുന്നത്.

ലാപ്ടോപ്പ് ഇപ്പോഴും റിമോട്ട് സെഷൻ നിയന്ത്രിക്കുന്നു, അതിനാൽ വർക്ക്സ്റ്റേഷൻ ഉപയോക്തൃ പ്രാമാണീകരണത്തിനോ സെഷൻ നയത്തിനോ പകരമല്ല.

ഡാറ്റാബേസ് യഥാർത്ഥത്തിൽ എന്ത് കാണുന്നു എന്ന് പരിശോധിക്കുക

സ്രോതസ്സ് വിലാസം അളക്കേണ്ട കാര്യമാണ്, ഡയഗ്രത്തിൽ നിന്ന് അനുമാനിക്കേണ്ടതല്ല. സജീവ കണക്ഷന്റെ സർവർ വശത്തുനിന്ന് അത് വായിക്കുക.

Test-NetConnection sql.example.com -Port 1433
sqlcmd -S tcp:sql.example.com,1433 -N -d appdb -Q "select SUSER_SNAME() as login_name, DB_NAME() as db"

കണക്ടിവിറ്റി പരിശോധന ആ നെറ്റ്വർക്കിൽ നിന്ന് ലിസണർ TCP സ്വീകരിക്കുന്നു എന്ന് തെളിയിക്കുന്നു, അതേസമയം ക്വറി സെഷൻ ഏത് ലോഗിനിലും ഡാറ്റാബേസിലും എത്തി എന്ന് തെളിയിക്കുന്നു. സർവർ രേഖപ്പെടുത്തിയ വിലാസം കാണാൻ നിലവിലെ സെഷനായി sys.dm_exec_connections ക്വറി ചെയ്യുക; ഇത് ഏതെങ്കിലും വിവർത്തനത്തിന് ശേഷം ക്ലയന്റ് വിലാസം നൽകുന്നു. ആ മൂല്യം ലാപ്ടോപ്പല്ല ഗേറ്റ്വേയാണെങ്കിൽ, ഓരോ ഉപയോക്താവിനുമുള്ള ഹോസ്റ്റ് നിയമത്തിന് ഡാറ്റാബേസ് മെഷീനിൽ പ്രവർത്തിക്കാനാവില്ല. നിരീക്ഷിച്ച മൂല്യം തിരഞ്ഞെടുത്ത രൂപകൽപ്പനയുടെ അടുത്ത് എഴുതുക, കാരണം വീണ്ടും കണക്ട് ചെയ്യലും പൂൾ മാറ്റങ്ങളും അത് നീക്കുന്നു.

ലിസണർ തുറക്കുക, അധികമൊന്നുമല്ല

വിന്യാസത്തിന് ആവശ്യമായ സേവനം മാത്രം തുറക്കുക. പരിചിതമായ 1433 ഡിഫോൾട്ട് ഇൻസ്റ്റൻസിന്റെ പോർട്ടാണ്, സാർവത്രിക സ്ഥിരാങ്കമല്ല.

Get-NetTCPConnection -State Listen -LocalPort 1433

പേരുള്ള ഇൻസ്റ്റൻസുകൾ പലപ്പോഴും ചലനാത്മക പോർട്ടിൽ കേൾക്കുന്നു, SQL Server Browser UDP 1434-ൽ കണ്ടെത്തലിന് മറുപടി നൽകുന്നു, ഈ ആശ്രിതത്വം ന്യായീകരിക്കേണ്ട വേറിട്ട എക്സ്പോഷറാണ്. ഇൻസ്റ്റൻസിന് സ്ഥിര പോർട്ട് പിൻ ചെയ്യുന്നത് Browser-ന്റെ ആവശ്യകത ഒഴിവാക്കുകയും ഫയർവാൾ നിയമങ്ങൾ സ്ഥിരമാക്കുകയും ചെയ്യുന്നു. പരിശോധന പാസാകാൻ ക്ലയന്റ് ഇപ്പോൾ ചെയ്യുന്ന എൻക്രിപ്ഷനും സർട്ടിഫിക്കറ്റ് പരിശോധനയും ഓഫാക്കാതെ നിലനിർത്തുക. തുടർന്ന് മുഴുവൻ VPN ഗ്രൂപ്പും സർവർ റോളിൽ ചേർക്കുന്നതിന് പകരം വർക്ക്ലോഡിന് ഡാറ്റാബേസ് റോളുകൾ നൽകുക.

അനുവദിച്ച പാതയും നിരസിച്ച പാതയും തെളിയിക്കുക

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

ക്ലയന്റ് എവിടെ പ്രവർത്തിച്ചു, ഡാറ്റാബേസ് ഏത് സ്രോതസ്സ് നിരീക്ഷിച്ചു, ഏത് നിയമം അനുവദിച്ചു എന്നിവ രേഖപ്പെടുത്തുക. അടുത്ത അവലോകനം ആവശ്യപ്പെടുന്ന തെളിവ് അതാണ്.