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 वर प्रमाणित होते, कनेक्टरमार्फत इन्स्टन्सशी जोडणी उघडते आणि तुमचा क्लायंट PostgreSQL म्हणून वागवतो असे loopback पोर्ट देते. दोन उड्या तीन होतात, आणि मधली 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 नियम बदलण्याकडे नेले पाहिजे.