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 नियम बदल्नतर्फ लैजानुपर्छ।