App Engine तपाईंको VPN डेटाबेससम्म पुग्न सक्छ: के मिल्नुपर्छ

App Engine Standard Cloud VPN मार्फत निजी डेटाबेससम्म पुग्न सक्दैन भन्ने दाबी प्लेटफर्मको अघिल्लो पुस्ताको अवशेष हो। Standard इन्स्ट्यान्सहरूले केही अन्य रनटाइमजस्तै VPC-मूल ठेगाना पाउँदैनन्, तर तिनीहरूले तपाईंको नेटवर्कमा रहेको Serverless VPC Access कनेक्टरमार्फत egress पठाउन सक्छन्। त्यो मार्ग भएपछि, Cloud VPN र टाढाको फायरवालले कनेक्टरको ट्राफिकलाई अन्य कुनै स्रोतजस्तै देख्छन्। असफल हुने कुरा विरलै क्षमता आफैं हो। यो कहिल्यै नमिलाइएका तीन सेटिङमध्ये एक हो।

पुरानो उत्तर कहाँबाट आयो

कनेक्टरहरू अस्तित्वमा आउनुअघि, व्यावहारिक उत्तर साँच्चै यही थियो कि Standard ले सार्वजनिक एन्डपोइन्टसँग मात्र कुरा गर्न सक्छ, र टोलीहरू यसलाई छल्न प्रोक्सी VM वा अर्को रनटाइममा सरे। प्लेटफर्म बदलियो, लोककथा बदलिएन। अनलाइनका धेरै सल्लाहहरू अझै पनि egress विकल्प नै नभएको युगलाई प्रतिबिम्बित गर्छन्।

सुधार सुनिनेभन्दा साँघुरो छ। Standard निजी नेटवर्कसम्म पुग्न सक्छ, तर समर्थित egress एकीकरणमार्फत मात्र, र त्यो एकीकरणले वास्तवमै समात्ने गन्तव्यहरूका लागि मात्र।

पहिले egress मार्ग छान्नुहोस्

सेवामा जोडिएको कनेक्टरले त्यसको ट्राफिक VPC मा राख्छ। कनेक्टरको कागजातले क्षेत्रीय पूर्वशर्त र egress सेटिङहरू सूचीबद्ध गर्छ; कनेक्टर सेवाको क्षेत्रमा हुनुपर्छ र तैनाथ गर्ने पहिचानले प्रयोग गर्न सक्नुपर्छ।

vpc_access_connector:
  name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
  egress_setting: private-ranges-only

private-ranges-only निजी गन्तव्यहरूलाई VPC मा पठाउँछ र बाँकी सबै सामान्य इन्टरनेट मार्गमा छोड्छ, जुन सामान्यतया डेटाबेस जडानलाई चाहिन्छ। all-traffic बाहिर जाने ट्राफिकलाई VPC मार्फत व्यापक रूपमा धकेल्छ, त्यसैले सामान्य इन्टरनेट कलहरूले पनि VPC को NAT र फायरवाल अवस्था उत्तराधिकारमा पाउँछन्।

फाइल स्थानीय रूपमा सम्पादन गर्दा तैनाथ नगरेसम्म केही बदलिँदैन। चलिरहेको संस्करणले बनाइएको कन्फिगरेसन राख्छ।

स्रोत ठेगाना कनेक्टर हो, तपाईंको ल्यापटप होइन

धेरैजसो डिबगिङ समय यहीँ जान्छ। टाढाको VPN गेटवे र डेटाबेस फायरवालले VPC भित्र कनेक्टरलाई तोकिएको दायरा स्वीकार्नुपर्छ, तपाईंको कार्यालयको ठेगाना होइन र सेवाको सार्वजनिक egress ठेगाना होइन। एक नियम पनि लेख्नुअघि त्यो दायरा कन्सोलमा खोज्नुहोस्।

अझै दुई ठाउँ मिल्नुपर्छ। VPC रुट टेबललाई टाढाको डेटाबेस नेटवर्कतर्फ मार्ग चाहिन्छ, र टाढाको पक्षलाई कनेक्टर दायराका लागि फिर्ती मार्ग चाहिन्छ। यदि टनेलले ट्राफिक चयनकर्ता प्रयोग गर्छ भने, कनेक्टर दायरा वार्ता गरिएको दायराभित्र छ भनी पुष्टि गर्नुहोस्। टाढाबाट स्थानीय दिशामा मात्र रहेको मार्ग सामान्य चुक हो, र यसले पिङहरू पास गराउँछ तर TCP ह्यान्डसेक कहिल्यै पूरा गर्दैन।

केवल VM सबनेट स्वीकार्ने टनेलले कनेक्टरका प्याकेटहरू उपयोगी त्रुटि सन्देशबिना फ्याँक्छ, त्यसैले डेटाबेसको टाइमआउट क्रेडेन्सियल समस्याजस्तो देखिन्छ।

DNS अर्को मार्गबाट यात्रा गर्छ

निजी डेटाबेस होस्टनाम कनेक्टर पुग्ने नेटवर्कभित्र समाधान हुनुपर्छ, Cloud DNS पियरिङ वा VPC ले प्रयोग गर्न सक्ने फर्वार्डिङ जोनमार्फत। तपाईंको वर्कस्टेशनमा यसलाई समाधान गर्नु तैनाथ सेवाबारे केही पनि प्रमाणित गर्दैन, किनकि तपाईंको ल्यापटपले त्यो रिजोल्भर प्रयोग गर्दैन।

यदि नाम VPC भित्रबाट सार्वजनिक ठेगानामा समाधान हुन्छ भने, तपाईं गलत फायरवाल डिबग गर्न लाग्दै हुनुहुन्छ।

URL Fetch ले कनेक्टर प्रयोग गर्दैन

egress सेटिङले रनटाइमका सामान्य बाहिर जाने सकेटहरू समेट्छ, र पुरानो URL Fetch सेवा त्यो मार्गको भाग होइन। urlfetch मार्फत जारी गरिएको अनुरोधले कन्फिगरेसनले जे भने पनि कनेक्टरलाई बेवास्ता गर्छ। जब असफल कल URL Fetch अझै प्रयोग गर्ने पुरानो लाइब्रेरीमा हुन्छ, समाधान त्यो कललाई मानक HTTP क्लाइन्टमा सार्नु हो।

डेटाबेस ड्राइभरका लागि यो विरलै समस्या हुन्छ, तर एउटै सेवाबाट एउटा एन्डपोइन्ट काम गर्ने र अर्को नगर्ने यो क्लासिक कारण हो।

एउटा साँघुरो क्वेरीले प्रमाणित गर्नुहोस्

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

VPC भित्रको VM बाट सफल क्वेरीले मार्ग अवस्थित छ भनी प्रमाणित गर्छ। सेवाले त्यसलाई छान्यो भनी प्रमाणित गर्दैन।