Cloud SQL Auth Proxy સામે ડેટાબેઝ સુધી સીધો VPN રૂટ
Auth Proxy અને સીધો VPN રૂટ એક જ સમસ્યાના અલગ અલગ અર્ધા ઉકેલે છે. પહેલા કનેક્ટર ઓથોરાઇઝેશન, પોર્ટ અને ડેટાબેઝ લોગિન સરખાવો.
VPN પરના લેપટોપથી ખાનગી Cloud SQL ઇન્સ્ટન્સ સુધી પહોંચવાના બે વ્યાજબી રસ્તા છે. એક છે તમારી પાસે પહેલેથી હાજર રૂટ દ્વારા ઇન્સ્ટન્સના ખાનગી સરનામા પર સીધું જોડાણ. બીજો છે Cloud SQL Auth Proxy, જે loopback પર સાંભળે છે અને Cloud SQL તરફનું જોડાણ જાતે ખોલે છે. આ બંને સ્પર્ધક ઉત્પાદનો કરતાં વધુ તો એ પ્રશ્નના બે અલગ જવાબો છે કે ઓળખપત્ર કોની પાસે છે અને રૂટ કોની પાસે છે. ખોટી પસંદગી સામાન્ય રીતે ઓથોરાઇઝેશન ભૂલ તરીકે દેખાય છે, જે નેટવર્ક ભૂલ જેવી વંચાય છે.
આ એ સરખામણી છે જે હું ટીમ સામે મૂકીશ, અને પછી એ ચકાસણીઓ જે ખરેખર નિર્ણય કરે છે.
એક જ ઇન્સ્ટન્સ સુધીના બે રસ્તા
સીધો રસ્તો તમારા નેટવર્કથી પ્રોજેક્ટના VPC સુધીના private-services-access રૂટનો ઉપયોગ કરે છે. તમારો ક્લાયન્ટ ઇન્સ્ટન્સના ખાનગી સરનામા સાથે PostgreSQL બોલે છે, અને જોડાણ રૂટિંગ, firewall નિયમો અને ડેટાબેઝ ઓળખપત્રો પર જીવે કે મરે છે.
પ્રોક્સી રસ્તો એ જ રૂટ વાપરે છે પણ સ્થાનિક પ્રક્રિયા ઉમેરે છે. પ્રોક્સી તમારી એપ્લિકેશનના default credentials સાથે Google API સામે પ્રમાણિત કરે છે, કનેક્ટર દ્વારા ઇન્સ્ટન્સ સાથે જોડાણ ખોલે છે અને loopback પોર્ટ આપે છે જેને તમારો ક્લાયન્ટ PostgreSQL તરીકે ગણે છે. બે કૂદકા ત્રણ થાય છે, અને વચ્ચેનો IAM ઓથોરાઇઝેશન ધરાવે છે. VPN રૂટ હજુ પણ તમારે જાળવવાનો છે, અને પ્રોક્સી તેને ક્યારેય એ ચકાસણીનો વિકલ્પ ગણતું નથી.
દરેક રસ્તો ખરેખર શું ઓથોરાઇઝ કરે છે
સૌથી મહત્ત્વનો ભેદ એ છે કે દરેક વિકલ્પ તમારા વતી શું ઓથોરાઇઝ કરી શકે છે:
| 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 |
પ્રોક્સીની IAM ચકાસણી અને ડેટાબેઝ લોગિન બે અલગ દરવાજા છે, અને એકમાંથી પસાર થવાથી બીજો ખૂલતો નથી. જે ટીમ પ્રોક્સી ચાલુ કરે અને ધારે કે એપ્લિકેશન એકાઉન્ટ હવે બિનજરૂરી છે, તે નેટવર્કિંગ સાથે કોઈ સંબંધ ન ધરાવતી પાસવર્ડ નિષ્ફળતાઓમાં બપોર પસાર કરશે.
પોર્ટ અને રૂટ, બાજુમાં બાજુ
પ્રોક્સીને API માટે બહાર જતા TCP 443 અને ઇન્સ્ટન્સ જોડાણ માટે TCP 3307 ની જરૂર છે, બંને Google ના Auth Proxy વિહંગાવલોકન માં વર્ણવેલા છે. તમારો VPN રૂટ બીજાને આવરી લે છે; પહેલો સામાન્ય રીતે સામાન્ય રસ્તે નીકળે છે.
સીધા જોડાણ માટે ઇન્સ્ટન્સનો PostgreSQL પોર્ટ ખાનગી રૂટ પર પહોંચી શકાય તેવો હોવો જરૂરી છે, જે સાવ અલગ firewall ચર્ચા છે. જો તમારી નેટવર્ક ટીમ ક્લાયન્ટ સબનેટમાંથી ફક્ત 443 બહાર જવાની મંજૂરી આપે, તો પ્રોક્સી કોઈ નિયમ બદલ્યા વિના ફિટ થાય અને સીધો રસ્તો નહીં. આ એક જ હકીકત કોઈ પણ આર્કિટેક્ચરલ પસંદગી કરતાં વધુ વખત નિર્ણય કરે છે.
બંનેમાંથી કોઈ રસ્તો ઇન્સ્ટન્સ પાસે જાહેર સરનામું હોવાની માંગ કરતો નથી, અને કોઈ એક ઉમેરવાનું વાજબી ઠેરવતો નથી.
જ્યાં પ્રોક્સી મદદ કરતું નથી
પ્રોક્સી ખૂટતો રૂટ સુધારતું નથી. જો private-services-access રૂટ ગેરહાજર હોય, અથવા VPN તેને વહન ન કરે, તો કનેક્ટર નિષ્ફળ જાય છે જ્યારે સ્થાનિક શ્રોતા હજુ પણ ત્યાં બેસીને સાંભળે છે, અને એ જ ગૂંચવણભર્યો ભાગ છે.
તે તમારી એપ્લિકેશન અને પ્રોક્સી વચ્ચેના ભાગનું રક્ષણ પણ કરતું નથી. એક લેપટોપ પર એ ભાગ loopback છે અને ઠીક છે. જો તમે સહકર્મી પહોંચી શકે તે માટે શ્રોતાને wildcard સરનામા સાથે બાંધો, તો તમે પ્રમાણીકરણ વગરનું ડેટાબેઝ ગેટવે બનાવ્યું છે અને તેને સુવિધા કહ્યું છે. તેને loopback પર રાખો અને સહકર્મીને પોતાનું ઓળખપત્ર લેવા દો.
અને તે Private Service Connect અને private services access ને એકબીજાના બદલે વાપરી શકાય તેવા બનાવતું નથી. PSC ઇન્સ્ટન્સને પોતાની DNS ગોઠવણી અને --private-ip સ્વરૂપને બદલે --psc કૉલની જરૂર છે.
પસંદ કરો, પછી બંને રીતે ચકાસો
જ્યારે તમે રૂટમાં IAM, ટૂંકા ગાળાના ઓળખપત્રો અને આવતા firewall માં કોઈ ફેરફાર ન ઈચ્છો ત્યારે પ્રોક્સી પસંદ કરો.
જ્યારે સમર્થિત ક્લાયન્ટ પાસે પહેલેથી મજબૂત ડેટાબેઝ ઓળખપત્રો હોય અને નેટવર્ક ટીમ પોર્ટ ખોલવામાં સહજ હોય ત્યારે સીધો રસ્તો પસંદ કરો. બંને રીતે, સફળ જોડાણને બદલે સાચી ક્વેરીથી ચકાસો: જોડાઓ, જાણીતા ટેબલ પર એક વાંચન ચલાવો અને જુઓ કે સર્વર તમારા સત્ર વિશે શું જુએ છે.
VPN ફરીથી જોડાયા પછી, સમાપ્ત થયેલા ઓળખપત્ર, ખૂટતા ખાનગી રૂટ અને ડેટાબેઝ લોગિનનો અસ્વીકાર ત્રણ અલગ નિષ્ફળતા તરીકે ગણો. તેમાંથી ફક્ત એક નેટવર્ક સમસ્યા છે, અને ફક્ત એક જ ક્યારેય firewall નિયમ બદલવા તરફ દોરી જવો જોઈએ.