Cloud Run से ऑन-प्रिमाइसेस VPN: Direct VPC egress सेटअप

Cloud VPN टनल Cloud Run को नेटवर्क पर नहीं रखती. सेवा को सही सबनेट से जोड़ें, उसकी स्रोत रेंज रूट करें, फिर उसी रिवीज़न का परीक्षण करें.

टनल चालू है, एक VM ऑन-प्रिमाइसेस सर्वर तक पहुँचती है, और Cloud Run सेवा उसी होस्ट पर टाइम आउट हो जाती है। यह इस काम का सामान्य शुरुआती बिंदु है, और टनल ही शायद ही कभी गलत होती है। Cloud Run रिवीज़न डिफ़ॉल्ट रूप से आपके VPC में नहीं बैठता, और जब बैठता है, तो वह उस VM सबनेट के बजाय अपने ही स्रोत पते इस्तेमाल करता है जिसे आप पहले ही रूट कर चुके हैं। नीचे दिया गया रनबुक सेवा को जोड़ता है, उसकी वास्तविक स्रोत रेंज रूट करता है, और फिर उस रिवीज़न से रास्ता साबित करता है जिसने अनुरोध की सेवा की। इसे उसी क्रम में चलाएँ, क्योंकि पहला कदम छोड़ना ही वह कारण है कि ऐसे बहुत से मामले ऐसे VPN बदलाव पर खत्म होते हैं जो कुछ ठीक नहीं करता।

टनल को डीबग करने से पहले रिवीज़न जोड़ें

Cloud Run समर्थन करता है Direct VPC egress, जो Serverless VPC Access कनेक्टर के बिना सेवा के ट्रैफ़िक को आपके VPC के एक सबनेट पर रखता है। किसी मौजूदा सेवा के लिए अपडेट ऐसा दिखता है:

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

प्लेसहोल्डर बदलें, देखें कि डिप्लॉयमेंट लाइव ट्रैफ़िक के साथ क्या करता है, और सेवा के क्षेत्र में पर्याप्त पता क्षमता और सही नेटवर्क अनुमतियों वाला सबनेट चुनें।

गंतव्य से मेल खाता एग्रेस मोड चुनें

private-ranges-only उन गंतव्यों को VPC के माध्यम से भेजता है जिन्हें वह निजी के रूप में वर्गीकृत करता है। इसका मतलब «VPN से पहुँचने योग्य हर चीज़» नहीं है, और यह अंतर तब दिखता है जब ऑन-प्रिमाइसेस सेवा ऐसी रेंज में हो जिसे सेटिंग इस तरह वर्गीकृत नहीं करती। अगर गंतव्य कवर नहीं है, तो all-traffic दूसरा प्रलेखित मोड है, और यह सेवा की सार्वजनिक निर्भरताओं सहित सब कुछ VPC के माध्यम से भेजता है। जानबूझकर चुनें और परिणाम को परिवर्तन रिकॉर्ड में लिखें।

जो सेवा पहले से कनेक्टर इस्तेमाल करती है, उसे टॉगल नहीं बल्कि माइग्रेशन चाहिए, इसलिए दोनों कॉन्फ़िगर करने के बजाय उसकी योजना बनाएँ।

VM स्रोत नहीं, Cloud Run स्रोत रूट करें

Direct VPC egress चयनित सबनेट से अस्थायी पते आवंटित करता है, और ऑन-प्रिमाइसेस पक्ष को ट्रैफ़िक उस रेंज में लौटाना होता है। किसी दूसरे VM सबनेट के लिए लिखा गया रिटर्न रूट या फ़ायरवॉल अनुमति आरेख में सही दिखेगा और व्यवहार में विफल होगा। सबनेट CIDR को याद से नहीं, VPC से लें, फिर पुष्टि करें कि रिमोट डिवाइस का क्रिप्टो ACL या रूट टेबल उसे शामिल करता है।

गतिशील रूटिंग के साथ, सत्यापित करें कि Cloud Router वास्तव में क्या घोषित करता है और VPC क्या आयात करता है, किसी भी कस्टम घोषणा नीति सहित। कंसोल में मौजूद पर इस गंतव्य के लिए चयनित न होने वाला रूट किसी रूट के न होने के बराबर है।

तीन शर्तें जो सभी पूरी होनी चाहिए

एक काम करने वाले मार्ग को निम्नलिखित सब चाहिए, और हर एक अपने तरीके से विफल होता है:

  • VPC में ऑन-प्रिमाइसेस प्रीफ़िक्स की ओर इच्छित Cloud VPN कनेक्शन के माध्यम से एक रूट।
  • Cloud Run सबनेट के लिए ऑन-प्रिमाइसेस पक्ष पर एक रिवर्स रूट।
  • स्रोत, गंतव्य और पोर्ट की अनुमति देने वाला फ़ायरवॉल और IPsec सुरक्षा दायरा।

गुम रूट आमतौर पर रिमोट पक्ष पर किसी सबूत के बिना टाइम आउट जैसा दिखता है। रिवर्स रूट की समस्या अनुरोध आने और जवाब गायब होने जैसी दिखती है। फ़ायरवॉल या सिलेक्टर की समस्या डिवाइस के अनुसार इनकार या शांत ड्रॉप जैसी दिख सकती है। यह पता लगाना कि तीनों में से कौन सी आपके पास है, अगला कमांड काफ़ी सीमित कर देता है।

एक भी अस्थायी Cloud Run पता अनुमत सूची में न डालें। सबनेट रेंज और एप्लिकेशन के अनुरूप प्राधिकरण डिज़ाइन इस्तेमाल करें।

उस रिवीज़न का परीक्षण करें जिसने अनुरोध की सेवा की

परीक्षण से पहले तैनात नेटवर्क सेटिंग्स और ट्रैफ़िक आवंटन की जाँच करें, क्योंकि अपडेट नया रिवीज़न बना सकता है जबकि अनुरोध अभी भी पुराने तक पहुँच रहे हों। फिर वही क्रिया करें जो उपयोगकर्ता का अनुरोध करता है, उसी रिवीज़न से। अगर गंतव्य निजी होस्टनाम है, तो उस वातावरण में उसका रिज़ॉल्यूशन और उससे बना पता जाँचें, क्योंकि आपके लैपटॉप का कॉर्पोरेट DNS उत्तर सेवा के नामस्थान के बारे में कुछ साबित नहीं करता। TLS होस्टनाम सत्यापन और रिमोट एप्लिकेशन का अपना प्रमाणीकरण बनाए रखें।

Direct VPC के प्रलेखित स्टार्टअप कनेक्शन विलंब की अपेक्षा रखें, और हर कोल्ड स्टार्ट को टूटी टनल के रूप में निदान करने के बजाय क्लाइंट को तैयारी या पुनः प्रयास रणनीति दें।

रोलबैक और यह क्या नहीं करता

रोलबैक करने के लिए, सेवा की नेटवर्क और एग्रेस सेटिंग्स उनके पिछले मानों पर लौटाएँ और पुष्टि करें कि पिछला रिवीज़न अभी भी ट्रैफ़िक की सेवा कर रहा है। परिवर्तन रिकॉर्ड में gcloud कमांड रखें, क्योंकि आंशिक बदलाव का उलटा छह सप्ताह बाद स्पष्ट नहीं होता। VPC जोड़ हटाने से सेवा अपने पिछले एग्रेस मार्ग पर लौट आती है, जो किसी घटना के दौरान बिल्कुल वही हो सकता है जो आप चाहते हैं।

यह डिज़ाइन उन कनेक्शनों को कवर करता है जो Cloud Run शुरू करता है और उनके उत्तरों को। यह ऑन-प्रिमाइसेस नेटवर्क को सेवा के भीतर पता-योग्य सॉकेट नहीं देता, क्योंकि भीतर की ओर एक्सपोज़र एक ingress निर्णय है।

संबंधित लेख