സ്വകാര്യ എൻഡ്പോയിന്റ്, അതേ സർവർ നാമം: Azure SQL കണക്ഷൻ സ്ട്രിംഗുകൾ

Private Link ഒരു കണക്ഷൻ എവിടെ എത്തുന്നു എന്നത് മാറ്റുന്നു, കണക്ഷനെ എന്ത് വിളിക്കുന്നു എന്നതല്ല. Azure SQL Database-ന് ആ വ്യത്യാസമാണ് മുഴുവൻ ഡിസൈൻ: ലോജിക്കൽ സർവർ അതിന്റെ പേര് നിലനിർത്തുന്നു, സ്വകാര്യ എൻഡ്പോയിന്റ് പേര് പരിഹരിക്കപ്പെടുന്ന ഒരു നെറ്റ്വർക്ക് എൻട്രി നൽകുന്നു. പേര് ഒരു IP വിലാസം കൊണ്ട് മാറ്റിസ്ഥാപിക്കുന്നതാണ് TLS, ക്രെഡൻഷ്യലുകൾ, ടൂളുകൾ എന്നിവ ഒരുമിച്ച് തകർക്കുന്ന ഏക മാറ്റം. രണ്ട് കണക്ഷൻ സ്ട്രിംഗുകൾ തുല്യമായി തോന്നാം, പക്ഷേ തികച്ചും വ്യത്യസ്തമായി പ്രവർത്തിക്കാം.

orders-db.database.windows.net നിലനിർത്തി ക്ലയന്റിന് അതിനുള്ള സ്വകാര്യ ഉത്തരം നൽകുക.

പേരിനും വിലാസത്തിനും വ്യത്യസ്ത ജോലികളുണ്ട്

പേര് SQL സേവനത്തെ തിരിച്ചറിയുന്നു, സർട്ടിഫിക്കറ്റും ലോഗിനും പ്രതീക്ഷിക്കുന്നത് അതാണ്. സ്വകാര്യ വിലാസം ബന്ധിപ്പിച്ച വെർച്വൽ നെറ്റ്വർക്കിനുള്ളിൽ ഒരു നെറ്റ്വർക്ക് എൻട്രി നൽകുന്നു. ഒന്നിനെ മറ്റൊന്നുമായി കൂട്ടിക്കലർത്തിയാൽ എന്തിലെങ്കിലും എത്തുന്ന, എന്നാൽ ഒന്നിനോടും പ്രാമാണീകരിക്കാത്ത ഒരു കണക്ഷൻ ഉണ്ടാകുന്നു.

Azure SQL-നുള്ള Microsoft മാർഗനിർദേശം ക്ലയന്റുകളിൽ നിന്ന് സാധാരണ സർവർ നാമം ആവശ്യപ്പെടുന്നു. നേരിട്ടുള്ള IP, അതുപോലെ privatelink പ്രിഫിക്സുള്ള പേരും, പരസ്പരം മാറ്റാവുന്ന ലോഗിൻ ലക്ഷ്യമല്ല. IP സ്വീകരിക്കുന്ന ടൂളുകൾ അത് സ്വീകരിച്ച ശേഷം TLS-ലോ പ്രാമാണീകരണത്തിലോ പരാജയപ്പെടും, ഇത് യഥാർത്ഥ തെറ്റ് മറയ്ക്കുന്നു. ആ പരാജയങ്ങൾ പിശകിലെ ഹോസ്റ്റ്നെയിം കാണുന്നതുവരെ ക്രെഡൻഷ്യൽ പ്രശ്നങ്ങളായി വായിക്കപ്പെടുന്നു.

സ്വകാര്യ സോൺ യഥാർത്ഥത്തിൽ മാറ്റുന്നത്

സ്വകാര്യ DNS സോൺ privatelink നാമസ്ഥലത്തിനുള്ളിൽ സർവറിന് ഒരു വിലാസം രേഖപ്പെടുത്തുന്നു, സോൺ അത് ഉപയോഗിക്കേണ്ട വെർച്വൽ നെറ്റ്വർക്കുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു. പരിഹാരം നീങ്ങുന്നു; കണക്ഷൻ സ്ട്രിംഗ് നീങ്ങുന്നില്ല. താഴെയുള്ള രൂപം ഒരു ഉദാഹരണമാണ്, പൊതു സോണിൽ ഒട്ടിക്കാനുള്ള റെക്കോർഡല്ല.

Application name:        orders-db.database.windows.net
Private DNS zone:        privatelink.database.windows.net
Resolved private entry:  the approved private endpoint address

ആ റെക്കോർഡും അതിന്റെ സോൺ ലിങ്കും ഉടമയും അവലോകന തീയതിയും സഹിതം അടിസ്ഥാന സൗകര്യമായി പരിപാലിക്കുക.

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

Azure-ന് പുറത്തുള്ള ക്ലയന്റുകൾക്ക് ആ സോണിലേക്ക് ഒരു വഴി വേണം

VPN ക്ലയന്റ് Azure-ന്റെ റിസോൾവറിന് പുറത്ത് ഇരിക്കുന്നു, അതിനാൽ സ്വകാര്യ സോൺ ഹൈബ്രിഡ് വഴിയിൽ നിന്ന് എത്താവുന്നതായിരിക്കണം. Azure DNS ഫോർവേർഡറോ Azure DNS Private Resolver-ഓ ആ നെറ്റ്വർക്കിലൂടെ വരുന്ന ക്വറികൾ സേവിക്കാം. Microsoft-ന്റെ മാർഗനിർദേശം, ക്ലയന്റുകൾ privatelink പേര് നേരിട്ട് ചോദ്യം ചെയ്യുന്നു എന്ന് അനുമാനിക്കുന്നതിന് പകരം ബന്ധപ്പെട്ട പൊതു സേവന സോൺ ആ ക്രമീകരണത്തിലൂടെ ഫോർവേർഡ് ചെയ്യുക എന്നതാണ്. സ്വകാര്യ ഉത്തരം പരിഹരിക്കാനാകാത്ത ക്ലയന്റുകൾ പരാതിയില്ലാതെ പൊതു ഉത്തരത്തിലേക്ക് മടങ്ങുന്നു.

ഫോർവേർഡിംഗ് പരിധി ബോധപൂർവ്വം നിലനിർത്തുക, കാരണം ഉപയോഗത്തിലുള്ള ഒരു പൊതു സോൺ മാറ്റിസ്ഥാപിക്കുന്നത് പകരം വയ്ക്കലിൽ ഇല്ലാത്ത പേരുകൾ തകർക്കുന്നു.

ഐഡന്റിറ്റി ഉറപ്പിച്ചു നിർത്തുന്ന ക്രമത്തിൽ നൽകുക

ഘട്ടങ്ങൾക്ക് വേർതിരിച്ച ഉടമകളുണ്ട്: എൻഡ്പോയിന്റ് സൃഷ്ടിച്ച് അംഗീകരിക്കുക, VPN റൂട്ട് നൽകുക, സ്വകാര്യ DNS സംയോജിപ്പിക്കുക, തുടർന്ന് ക്ലയന്റിനെ അതിന്റെ സാധാരണ സർവർ നാമത്തോടെ കോൺഫിഗർ ചെയ്യുക. റൂട്ടിന് മുമ്പ് DNS ചെയ്താൽ DNS പരാജയങ്ങൾ പോലെ തോന്നുന്ന സമയപരിധികൾ ഉണ്ടാകും. ക്ലയന്റിനെ അവസാനം ചെയ്താൽ ഒരു സമയത്ത് ഒരു വേരിയബിൾ മാത്രം ചലിക്കുന്നു. ഓരോ ഘട്ടത്തിനും നിരീക്ഷിക്കാവുന്ന ഫലമുണ്ട്, അതിനാൽ ഒന്നും ഊഹിച്ച് പരിശോധിക്കേണ്ടതില്ല.

ബന്ധിപ്പിച്ച VPN ഐക്കൺ തന്നെ സ്വകാര്യ ലക്ഷ്യം തിരഞ്ഞെടുക്കുന്നില്ല.

സ്വകാര്യ എൻഡ്പോയിന്റ് ഓഫ് ചെയ്യാത്തത്

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

സർവർ ഏത് കണക്ഷൻ നയം ഉപയോഗിക്കുന്നുവെന്നും പരിശോധിക്കുക.

Redirect പ്രാരംഭ ഗേറ്റ്വേ കണക്ഷന് ശേഷം ക്ലയന്റിനെ നോഡിലെ ഒരു പോർട്ടിലേക്ക് അയയ്ക്കുന്നു, ഇത് ക്ലയന്റ് നെറ്റ്വർക്ക് എന്ത് അനുവദിക്കണം എന്നത് മാറ്റുന്നു. Proxy ട്രാഫിക് ഗേറ്റ്വേയിൽ നിലനിർത്തുന്നു. ഒരു പോർട്ടിലെ വിജയകരമായ TCP ഹാൻഡ്ഷേക്ക് മുഴുവൻ ലോഗിൻ വർക്ക്ഫ്ലോയല്ല.

ഇത് Azure SQL Database ആണ്, സ്വന്തം കണക്റ്റിവിറ്റി മോഡലുള്ളതും തുല്യമായ സ്വകാര്യ എൻഡ്പോയിന്റ് കഥയില്ലാത്തതുമായ SQL Managed Instance അല്ല. രണ്ട് സാഹചര്യങ്ങളിലും മൂന്ന് കാര്യങ്ങൾ വെവ്വേറെ ലേബൽ ചെയ്ത് നിലനിർത്തുക: പേര്, നെറ്റ്വർക്ക് എൻട്രി, ക്രെഡൻഷ്യൽ. കണക്ഷൻ എവിടെ സഞ്ചരിക്കുന്നു എന്നത് മാറ്റുന്നത് ക്ലയന്റ് ഏത് സേവനത്തോട് സംസാരിക്കുന്നു എന്ന് കരുതുന്നതിനെ ഒരിക്കലും മാറ്റരുത്.