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 नियम बदलने तक ले जाना चाहिए।