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

प्लेसहोल्डर बदला, डिप्लॉयमेंट थेट रहदारीवर काय करते ते तपासा, आणि सेवेच्या प्रदेशात पुरेशी पत्ता क्षमता व योग्य नेटवर्क परवानग्या असलेले सबनेट निवडा.

गंतव्याशी जुळणारा egress मोड निवडा

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 च्या दस्तऐवजी सुरुवातीच्या जोडणीतील विलंबाची अपेक्षा करा, आणि प्रत्येक कोल्ड स्टार्टचे तुटलेले टनेल म्हणून निदान करण्याऐवजी ग्राहकाला तयारी किंवा पुन्हा प्रयत्नाची रणनीती द्या.

रोलबॅक आणि हे काय करत नाही

रोलबॅक करण्यासाठी, सेवेची नेटवर्क व egress सेटिंग्ज त्यांच्या आधीच्या मूल्यांवर परत आणा आणि आधीचे रिव्हिजन अजूनही रहदारी पूर्ण करते याची खात्री करा. बदल नोंदीत gcloud आदेश ठेवा, कारण अंशतः बदलाचा उलटा सहा आठवड्यांनंतर स्पष्ट नसतो. VPC जोडणी काढल्यास सेवा तिच्या आधीच्या egress मार्गावर परत येते, जे घटनेच्या वेळी तुम्हाला हवे असलेलेच असू शकते.

हे रचना Cloud Run सुरू करते ती जोडणी आणि त्यांची उत्तरे व्यापते. ती ऑन-प्रिमाइसिस नेटवर्कला सेवेच्या आत पत्ता-योग्य सॉकेट देत नाही, कारण आतमधील उघडकी हा ingress निर्णय आहे.

संबंधित लेख