VPN मार्फत Cloud SQL को निजी IP: कसैले निर्यात नगर्ने मार्ग

धेरै टोलीहरू Cloud SQL को निजी IP VPC भित्रबाट मात्र काम गर्छ भन्ने विश्वास गर्छन्, र त्यो विश्वास टिक्छ किनकि असफलता डेटाबेसको समस्या जस्तो देखिन्छ। Google ले Cloud VPN वा Cloud Interconnect मार्फत जोडिएका नेटवर्कबाट पहुँचको दस्तावेजीकरण गर्छ। ती नेटवर्कलाई विशेष डेटाबेस सुविधा चाहिँदैन, बरु आधा कन्फिगर गरेर छोड्न सजिलो दुई मार्ग आदानप्रदान चाहिन्छ। टनेल माथि आउँछ, कम्प्युट इन्स्टेन्सहरू जवाफ दिन्छन्, र डेटाबेस जडान समय सीमा नाघ्छ — मानिसहरूलाई गलत कन्सोलमा पठाउने ठ्याक्कै त्यही संयोजन।

भ्रम: निजी IP भन्नाले VPC का लागि निजी

निजी सेवाहरूमा पहुँच भनेको तपाईंको नेटवर्क र Google को स्वामित्वमा रहेको उत्पादक नेटवर्कबीचको VPC पियरिङ हो। सेवाका लागि छुट्याइएको दायरा उत्पादकको पट्टि रहन्छ, र इन्स्टेन्सको ठेगाना त्यसभित्र हुन्छ। यही पियरिङका कारण तपाईंको प्रोजेक्टको डेटाबेस तपाईंको VPC ले मार्ग पुर्याउने ठेगानामा बस्न सक्छ, जबकि तपाईंको कुनै पनि स्पष्ट सबनेटमा त्यो हुँदैन।

यो पियरिङ भएकाले यसमा पियरिङ व्यवहार पनि छ, जसमा कस्टम मार्गहरू स्वतः नाघ्दैनन् भन्ने भाग पनि पर्छ।

भ्रम: चल्ने टनेलले डेटाबेस मार्ग साथै लैजान्छ

दुई दायराले यो यात्रा सहनुपर्छ। पहिलो क्लाइन्ट प्रिफिक्स हो: तपाईंको स्थानीय नेटवर्क ठोस प्रिफिक्ससहित Cloud Router लाई ज्ञात हुनुपर्छ, किनकि पूर्वनिर्धारित मार्गले उत्पादक नेटवर्कलाई फर्कने बाटोका लागि चाहिने आयात दिन सक्दैन। दोस्रो छुट्याइएको सेवा दायरा हो, जुन बाहिरी पक्षले सिक्नुपर्छ ताकि डेटाबेसतर्फका त्यसका प्याकेटलाई जाने ठाउँ होस्। यी फरक सीमामा राखिने फरक मार्ग हुन्, र एउटा सुधार्दा अर्को बिग्रिएको रहन्छ।

Google को पट्टि यसको अर्थ सम्बन्धित पियरिङ जडानहरूमा Export custom routes सक्षम गर्नु र टनेलका लागि Cloud Router का घोषित मार्गहरूमा छुट्याइएको सेवा दायरा थप्नु हो।

पहिले नै भएका विज्ञापनहरू राख्नुहोस्। सेवा दायरा थप्दा त्यही BGP सत्रले अन्य ट्राफिकका लागि बोकेका VPC मार्गहरू हटाउनु हुँदैन, र पूरै प्रतिस्थापित विज्ञापन सेट पहिलोको पछाडि लुकेको दोस्रो अवरोध हो। बाह्य यन्त्रमा प्रभावकारी मार्गहरू पनि जाँच्नुहोस्, किनकि VPN गेटवे वा अर्को सबनेटमा पुग्नुले यातायात मात्र प्रमाणित गर्छ।

भ्रम: Cloud SQL Auth Proxy ले नेटवर्क समाधान गर्छ

The Auth Proxy ले तपाईंको एप्लिकेसन र इन्स्टेन्सबीच समर्थित प्रमाणीकरण र इन्क्रिप्टेड यातायात उपलब्ध गराउँछ। यसले मार्ग बनाउँदैन। निजी नेटवर्कसम्म बाटो नभएको होस्टमा सुरु गरिएको प्रोक्सी ठ्याक्कै सिधा जडानजस्तै असफल हुन्छ, र त्यसका लगहरू कारणबारे कम उपयोगी हुन्छन्। प्रोक्सीलाई जडान भएको होस्टमा सार्दा मार्गको कुन भाग काम गर्नुपर्ने हो त्यो बदलिन्छ, र त्यो उपाय होइन, वास्तविक डिजाइन निर्णय हो।

यसले नगर्ने कुरा भनेको डिस्कनेक्ट भएको ल्यापटपलाई निजी मात्र इन्स्टेन्ससम्म पुग्न दिनु हो।

भ्रम: Private Service Connect एउटै नियमहरू पछ्याउँछ

Private Service Connect ले तपाईंको आफ्नै सबनेटमा endpoint र तपाईंले नियन्त्रण गर्ने DNS व्यवस्था प्रयोग गर्छ, त्यसैले त्यहाँसम्मको मार्ग तपाईंको स्वामित्वको ठेगानासम्मको सामान्य मार्ग हो। पियरिङ निर्यात सेटिङहरू त्यो डिजाइनमा लागू हुँदैनन्, र पियरिङ परिवर्तनहरू PSC तैनाथीमा प्रतिलिपि गर्दा पहुँच नबढाई जोखिम बढ्छ।

दुवैले तपाईंलाई निजी ठेगाना दिन्छन्; समानता त्यहीँ टुंगिन्छ।

मार्गलाई सही क्रममा परीक्षण गर्नुहोस्

बाह्य क्लाइन्टबाट पहिले डेटाबेसको TCP endpoint परीक्षण गर्नुहोस्। पूरा भएको TCP ह्यान्डशेक भन्नाले मार्गनिर्देशन, फायरवाल र श्रोता सबै ठाउँमा छन्, र अर्को परीक्षण अनुमत प्रमाणीकृत कार्य हो। त्यस क्षणमा प्रमाणीकरण अस्वीकार हुनु वास्तवमा राम्रो समाचार हो, किनकि डेटाबेस श्रोताले जवाफ दिएको प्रमाणित गर्छ। ICMP समय सीमाले डेटाबेस पहुँचबारे लगभग केही भन्दैन, किनकि धेरै मार्गले TCP सहजै अगाडि पठाउँदा त्यसलाई फ्याँक्छन्।

यदि तपाईंका क्लाइन्ट दायराहरू RFC 1918 बाहिर छन् भने, डिजाइन असमर्थित छ भन्ने निष्कर्षमा पुग्नुअघि थप मार्ग-निर्यात र नेटवर्क-अधिकार आवश्यकताहरू समीक्षा गर्नुहोस्।

जडानसँगै चार वस्तुहरू अभिलेख गर्नुहोस्: बाह्य प्रिफिक्स, छुट्याइएको सेवा दायरा, संलग्न पियरिङ जडानहरू र विज्ञापन गर्ने राउटर। ती चारले सम्पूर्ण निजी मार्ग व्याख्या गर्छन्, र Cloud SQL लाई सधैं प्रोक्सी चाहिन्छ वा VPN बाट पटक्कै पुग्न सकिँदैन भन्ने कथा उनीहरूले प्रतिस्थापित गर्छन्।