Cloud SQL Auth Proxy vs ഡാറ്റാബേസിലേക്കുള്ള നേരിട്ടുള്ള VPN റൂട്ട്
Auth Proxy-ഉം നേരിട്ടുള്ള VPN റൂട്ടും ഒരേ പ്രശ്നത്തിന്റെ വ്യത്യസ്ത പകുതികൾ പരിഹരിക്കുന്നു. ആദ്യം കണക്ടർ അധികാരം, പോർട്ടുകൾ, ഡാറ്റാബേസ് ലോഗിൻ എന്നിവ താരതമ്യം ചെയ്യുക.
VPN-ൽ ഉള്ള ലാപ്ടോപ്പിൽ നിന്ന് സ്വകാര്യ Cloud SQL ഇൻസ്റ്റൻസിലേക്ക് എത്താൻ രണ്ട് ന്യായയുക്തമായ വഴികളുണ്ട്. ഒന്ന്, നിങ്ങൾക്ക് ഇപ്പോൾ ഉള്ള റൂട്ടിലൂടെ ഇൻസ്റ്റൻസിന്റെ സ്വകാര്യ വിലാസത്തിലേക്കുള്ള നേരിട്ടുള്ള കണക്ഷൻ. മറ്റൊന്ന് Cloud SQL Auth Proxy ആണ്, അത് loopback-ൽ കേൾക്കുന്നു, Cloud SQL-ലേക്കുള്ള കണക്ഷൻ സ്വയം തുറക്കുന്നു. ഇവ മത്സരിക്കുന്ന ഉൽപ്പന്നങ്ങളേക്കാൾ, ക്രെഡൻഷ്യൽ ആരുടെ കൈവശമാണ്, റൂട്ട് ആരുടെ കൈവശമാണ് എന്ന ചോദ്യത്തിനുള്ള രണ്ട് വ്യത്യസ്ത ഉത്തരങ്ങളാണ്. തെറ്റായ തിരഞ്ഞെടുപ്പ് സാധാരണയായി നെറ്റ്വർക്ക് പിശകായി വായിക്കുന്ന അധികാര പിശകായി പ്രത്യക്ഷപ്പെടുന്നു.
ഒരു ടീമിന് മുന്നിൽ വെക്കുന്ന താരതമ്യം ഇതാ, അതിന് ശേഷം അത് യഥാർത്ഥത്തിൽ തീരുമാനിക്കുന്ന പരിശോധനകൾ.
ഒരേ ഇൻസ്റ്റൻസിലേക്കുള്ള രണ്ട് വഴികൾ
നേരിട്ടുള്ള വഴി നിങ്ങളുടെ നെറ്റ്വർക്കിൽ നിന്ന് പ്രോജക്റ്റിന്റെ VPC-യിലേക്കുള്ള private-services-access റൂട്ട് ഉപയോഗിക്കുന്നു. നിങ്ങളുടെ ക്ലയന്റ് ഇൻസ്റ്റൻസിന്റെ സ്വകാര്യ വിലാസവുമായി PostgreSQL സംസാരിക്കുന്നു, കണക്ഷൻ റൂട്ടിംഗ്, firewall നിയമങ്ങൾ, ഡാറ്റാബേസ് ക്രെഡൻഷ്യലുകൾ എന്നിവയിൽ ജീവിക്കുന്നു അല്ലെങ്കിൽ മരിക്കുന്നു.
proxy വഴി അതേ റൂട്ട് ഉപയോഗിക്കുന്നു, പക്ഷേ ഒരു പ്രാദേശിക പ്രോസസ്സ് കൂട്ടിച്ചേർക്കുന്നു. proxy നിങ്ങളുടെ ആപ്ലിക്കേഷന്റെ default credentials ഉപയോഗിച്ച് Google API-യിൽ പ്രാമാണീകരിക്കുന്നു, കണക്ടറിലൂടെ ഇൻസ്റ്റൻസിലേക്ക് കണക്ഷൻ തുറക്കുന്നു, നിങ്ങളുടെ ക്ലയന്റ് PostgreSQL ആയി കണക്കാക്കുന്ന ഒരു loopback പോർട്ട് നൽകുന്നു. രണ്ട് ചാട്ടങ്ങൾ മൂന്നാകുന്നു, നടുവിലുള്ളത് IAM അധികാരം വഹിക്കുന്നു. VPN റൂട്ട് ഇപ്പോഴും നിങ്ങളുടെ പരിപാലനമാണ്, proxy അതിനെ ആ പരിശോധനയുടെ പകരക്കാരനായി ഒരിക്കലും കാണുന്നില്ല.
ഓരോ വഴിയും യഥാർത്ഥത്തിൽ എന്ത് അധികാരപ്പെടുത്തുന്നു
ഏറ്റവും പ്രധാന വ്യത്യാസം, ഓരോ ഓപ്ഷനും നിങ്ങൾക്ക് വേണ്ടി എന്ത് അധികാരപ്പെടുത്താൻ കഴിയും എന്നതാണ്:
| Question | Direct private IP | Auth Proxy |
|---|---|---|
| Who proves identity to the network | Your client, through the VPN and a database login | The proxy, through IAM to Google's API |
| IAM role needed for the connector | None | Cloud SQL Client or equivalent |
| Database user authentication | Always required | Still required unless IAM database authentication is enabled |
| Shape of the local leg | Client to instance | Client to loopback, proxy to instance |
proxy-യുടെ IAM പരിശോധനയും ഡാറ്റാബേസ് ലോഗിനും വെവ്വേറെ ഗേറ്റുകളാണ്, ഒന്നിലൂടെ കടന്നാൽ മറ്റൊന്ന് തുറക്കുന്നില്ല. proxy ഓൺ ചെയ്ത് ആപ്ലിക്കേഷൻ അക്കൗണ്ട് ഇനി ആവശ്യമില്ലെന്ന് കരുതുന്ന ടീം, നെറ്റ്വർക്കിംഗുമായി യാതൊരു ബന്ധവുമില്ലാത്ത പാസ്വേഡ് പരാജയങ്ങളിൽ ഒരു ഉച്ചയ്ക്ക് ശേഷം ചെലവിടും.
പോർട്ടുകളും റൂട്ടുകളും, അരികിൽ
proxy-യ്ക്ക് API-യ്ക്കായി പുറത്തേക്കുള്ള TCP 443-ഉം ഇൻസ്റ്റൻസ് കണക്ഷനായി TCP 3307-ഉം വേണം, രണ്ടും Google-ന്റെ Auth Proxy അവലോകനത്തിൽ വിവരിച്ചിരിക്കുന്നു. നിങ്ങളുടെ VPN റൂട്ട് രണ്ടാമത്തേത് ഉൾക്കൊള്ളുന്നു; ആദ്യത്തേത് സാധാരണയായി സാധാരണ വഴിയിലൂടെ പുറത്തുപോകുന്നു.
നേരിട്ടുള്ള കണക്ഷന് ഇൻസ്റ്റൻസിന്റെ PostgreSQL പോർട്ട് സ്വകാര്യ റൂട്ടിലൂടെ എത്താവുന്നതാകണം, അത് തികച്ചും വ്യത്യസ്തമായ ഒരു firewall സംഭാഷണമാണ്. നിങ്ങളുടെ നെറ്റ്വർക്ക് ടീം ക്ലയന്റ് സബ്നെറ്റുകളിൽ നിന്ന് പുറത്തേക്ക് 443 മാത്രം അനുവദിക്കുന്നുവെങ്കിൽ, proxy ഒരു നിയമവും മാറ്റാതെ ഇണങ്ങും, നേരിട്ടുള്ള വഴി ഇണങ്ങില്ല. ഈ ഒരു വസ്തുത ഏതൊരു ആർക്കിടെക്ചർ മുൻഗണനയേക്കാളും കൂടുതൽ തവണ തിരഞ്ഞെടുപ്പ് തീരുമാനിക്കുന്നു.
റൂട്ടുകളിൽ ഒന്നും ഇൻസ്റ്റൻസിന് പൊതു വിലാസം ഉണ്ടായിരിക്കണമെന്ന് ആവശ്യപ്പെടുന്നില്ല, ഒന്നും അത് ചേർക്കുന്നത് ന്യായീകരിക്കുന്നുമില്ല.
proxy സഹായിക്കാത്തിടത്ത്
proxy കാണാത്ത റൂട്ട് നന്നാക്കുന്നില്ല. private-services-access റൂട്ട് ഇല്ലെങ്കിൽ, അല്ലെങ്കിൽ VPN അത് കൊണ്ടുപോകുന്നില്ലെങ്കിൽ, കണക്ടർ പരാജയപ്പെടുന്നു, പ്രാദേശിക ശ്രോതാവ് ഇപ്പോഴും അവിടെ ഇരുന്ന് കേൾക്കുന്നു, ആശയക്കുഴപ്പമുള്ള ഭാഗം അതാണ്.
നിങ്ങളുടെ ആപ്ലിക്കേഷനും proxy-യും തമ്മിലുള്ള ഭാഗവും അത് സംരക്ഷിക്കുന്നില്ല. ഒരു ലാപ്ടോപ്പിൽ ആ ഭാഗം loopback ആണ്, കുഴപ്പമില്ല. സഹപ്രവർത്തകന് എത്താൻ കഴിയാൻ ശ്രോതാവിനെ wildcard വിലാസത്തിൽ ബന്ധിച്ചാൽ, നിങ്ങൾ പ്രാമാണീകരണമില്ലാത്ത ഒരു ഡാറ്റാബേസ് ഗേറ്റ്വേ നിർമ്മിച്ച് അതിനെ സൗകര്യം എന്ന് വിളിച്ചു. അത് loopback-ൽ തന്നെ നിർത്തി സഹപ്രവർത്തകനെ സ്വന്തം ക്രെഡൻഷ്യൽ നേടാൻ അനുവദിക്കുക.
കൂടാതെ അത് Private Service Connect-നെയും private services access-നെയും പരസ്പരം മാറ്റാവുന്നതാക്കുന്നില്ല. PSC ഇൻസ്റ്റൻസിന് സ്വന്തം DNS ക്രമീകരണവും --private-ip രൂപത്തിന് പകരം --psc വിളിയും വേണം.
തിരഞ്ഞെടുത്ത്, പിന്നീട് ഏത് വിധേനയും പരിശോധിക്കുക
വഴിയിൽ IAM, ഹ്രസ്വകാല ക്രെഡൻഷ്യലുകൾ, ഇൻബൗണ്ട് firewall-ൽ മാറ്റമില്ല എന്നിവ വേണമെങ്കിൽ proxy തിരഞ്ഞെടുക്കുക.
പിന്തുണയുള്ള ക്ലയന്റിന് ഇതിനകം ശക്തമായ ഡാറ്റാബേസ് ക്രെഡൻഷ്യലുകൾ ഉണ്ടെങ്കിലും നെറ്റ്വർക്ക് ടീം പോർട്ട് തുറക്കാൻ സൗകര്യപ്പെടുന്നുവെങ്കിലും നേരിട്ടുള്ള റൂട്ട് തിരഞ്ഞെടുക്കുക. ഏത് വിധേനയും വിജയകരമായ കണക്ഷനല്ല, യഥാർത്ഥ ക്വറിയാണ് ഉപയോഗിച്ച് പരിശോധിക്കേണ്ടത്: കണക്ട് ചെയ്യുക, അറിയപ്പെടുന്ന ഒരു ടേബിളിൽ ഒരു വായന പ്രവർത്തിപ്പിക്കുക, നിങ്ങളുടെ സെഷനെക്കുറിച്ച് സർവർ എന്ത് കാണുന്നുവെന്ന് പരിശോധിക്കുക.
VPN വീണ്ടും കണക്ട് ചെയ്ത ശേഷം, കാലഹരണപ്പെട്ട ക്രെഡൻഷ്യൽ, കാണാത്ത സ്വകാര്യ റൂട്ട്, ഡാറ്റാബേസ് ലോഗിൻ നിരസിക്കൽ എന്നിവയെ മൂന്ന് വ്യത്യസ്ത പരാജയങ്ങളായി കാണുക. അവയിൽ ഒന്ന് മാത്രമാണ് നെറ്റ്വർക്ക് പ്രശ്നം, ഒന്ന് മാത്രമാണ് ഒരിക്കലും firewall നിയമം മാറ്റുന്നതിലേക്ക് നയിക്കേണ്ടത്.