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 के घोषित रूट में आवंटित सेवा रेंज जोड़ना।

जो विज्ञापन पहले से हैं उन्हें बनाए रखें। सेवा रेंज जोड़ने से वे VPC रूट हटने नहीं चाहिए जो वही BGP सत्र अन्य ट्रैफ़िक के लिए ले जाता है, और पूरी तरह बदला गया विज्ञापन सेट पहली समस्या के पीछे छिपी दूसरी रुकावट है। बाहरी डिवाइस पर प्रभावी रूट भी जाँचें, क्योंकि 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 पर उस तक पहुँचा ही नहीं जा सकता।