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 वरून अजिबात पोहोचता येत नाही अशी आख्यायिका त्या बदलतात.