VPC में VPN काम करता है, पर प्रबंधित सेवा का समय समाप्त हो जाता है
सुरंग आपके किनारे पर समाप्त होती है, प्रदाता के सामने वाले दरवाज़े पर नहीं। मार्ग बदलने से पहले लक्ष्य को VM पर होस्ट किया गया, VPC से जुड़ा या केवल सार्वजनिक के रूप में वर्गीकृत करें।
VPN के ज़रिए किसी प्रबंधित डेटाबेस तक पहुँचना आम तौर पर एक ऐसे कारण से विफल होता है जिसे किसी ने रनबुक में नहीं लिखा: सुरंग आपके नेटवर्क के किनारे पर समाप्त होती है, जबकि सेवा कभी उसके आपकी ओर नहीं थी। मार्ग तालिका सही दिखती है, सुरंग चालू होने की सूचना देती है, और कनेक्शन फिर भी समय समाप्त कर देता है। नीचे दी गई चार जाँचें क्रम से करें और पहली ऐसी जाँच पर रुकें जिसकी सफलता की शर्त पूरी नहीं होती, क्योंकि उसके बाद की हर जाँच मानती है कि पहले वाली पूरी हुई हैं।
जाँच एक: अंतिम बिंदु वास्तव में कहाँ रहता है?
VPN गेटवे उन दो नेटवर्क को जोड़ता है जिनका एड्रेसिंग आप नियंत्रित करते हैं। प्रबंधित सेवा प्रदाता के अपने सामने वाले दरवाज़े के पीछे चलाई जाती है, और वह दरवाज़ा उत्पाद के अनुसार तीन में से एक आकार लेता है। अगर आप नहीं जानते कि किस आकार से सामना है, तो कोई भी मार्ग-कार्य मदद नहीं करेगा, क्योंकि विफलता शायद मार्ग की विफलता ही न हो।
| Shape | What it means | Pass condition |
|---|---|---|
| Software on your VM | Ordinary subnet addressing | Route and security group permit the client |
| Attached to your VPC | Private, but only inside that VPC | Endpoint associated, source allowed, route present |
| Provider-hosted, public endpoint | Optional private link, not private by default | A private endpoint exists and DNS points at it |
ज़्यादातर बर्बाद दोपहरें इस वर्गीकरण को छोड़कर सीधे मार्ग तालिका पर जाने से बनती हैं। प्रदाता द्वारा होस्ट की गई सेवा जिसका अंतिम बिंदु सार्वजनिक है, आरेख चाहे जो कहे आपकी सुरंग के पीछे नहीं है, और VPC से जुड़ी सेवा कभी किसी सार्वजनिक DNS उत्तर में नहीं दिखेगी।
जाँच दो: VPC से जुड़ी सेवा, जैसे ElastiCache
इस तरह के कैश अपने ही VPC के भीतर पते पाते हैं और उनका इंटरनेट की ओर कोई श्रोता नहीं होता। उसी VPC में समाप्त होने वाला क्लाइंट VPN उन तक पहुँच सकता है, पर केवल तब जब तीन शर्तें एक साथ बैठें। कैश का अंतिम बिंदु ऐसे सबनेट से जुड़ा होना चाहिए जिन्हें आपकी सुरंग देख सके, उसका सुरक्षा समूह उस पते को अनुमति दे जहाँ से आपके क्लाइंट आते हैं, और क्लाइंट पक्ष को कैश सबनेट को ढकने वाला मार्ग चाहिए।
आम गलती यह मानना है कि पास में कहीं का कनेक्शन गिना जाता है। VPN को किसी दूसरे VPC से जोड़ना, या केवल peering पर निर्भर रहना, कैश के सुरक्षा समूह या उसके सबनेट की मार्ग तालिका को आपके क्लाइंट तक नहीं बढ़ाता। जब मौजूदा सुरंग कहीं और समाप्त होती है, तो उस VPC के भीतर रखा जंप होस्ट या VPN सर्वर सामान्य विकल्प होता है। वह विकल्प डिज़ाइन नहीं बल्कि एक चक्कर है, और रनबुक में उसे वैसा ही चिह्नित करना चाहिए।
जाँच तीन: सार्वजनिक नाम वाला PaaS अंतिम बिंदु
Azure Database for PostgreSQL एक सार्वजनिक सर्वर नाम प्रस्तुत करता है। यह आपको ऐसा निजी पता नहीं देता जिसे आप hosts फ़ाइल में पिन करके गेटवे से रूट कर सकें। वर्चुअल नेटवर्क सेवा अंतिम बिंदु यह सीमित करते हैं कि कौन से सबनेट किसी संसाधन तक पहुँच सकते हैं; वे VPN से आने वाले स्थानीय क्लाइंट को अधिकृत नहीं करते।
निजी पहुँच पाने का अर्थ है निजी अंतिम बिंदु या निजी लिंक डिज़ाइन लाना, फिर निजी DNS ज़ोन जोड़ना ताकि सार्वजनिक नाम इंटरनेट के बजाय उस अंतिम बिंदु से उत्तर दे। सेवा अंतिम बिंदु नियम के साथ जोड़ा गया VPN एक अलग आर्किटेक्चर है जो केवल आरेख में समान दिखता है। App Service उसी तर्क को विपरीत दिशा से अपनाता है: VNet एकीकरण ऐप को VNet में बाहर जाने वाली कॉल करने देता है, और यह आपकी सुरंग से अंदर आने वाला निजी मार्ग नहीं बनाता। इसलिए अंदर आने वाली निजी पहुँच के लिए निजी अंतिम बिंदु, App Service पर्यावरण या ऐप के आगे रखा गेटवे चाहिए, और इनमें से क्या इस्तेमाल कर सकते हैं यह योजना पर निर्भर है।
जाँच चार: अपना सामने का दरवाज़ा रखने वाले उत्पाद
Firebase Hosting को Cloud VPN से नहीं जोड़ा जा सकता, क्योंकि होस्टिंग परत एक वैश्विक फ्रंटएंड है, किसी प्रोजेक्ट VPC के भीतर की चीज़ नहीं। प्रलेखित विकल्प यह है कि नियंत्रित प्रवेश बिंदु आप स्वयं बनाएँ, किसी प्रॉक्सी इंस्टेंस या बकेट पर टिके लोड बैलेंसर के साथ। किसी भी तरह साइट शुद्ध होस्टिंग उत्पाद रहना छोड़ देती है और ऐसी अवसंरचना बन जाती है जिसे अब आप चलाते हैं। इस सौदे को नाम देना उचित है इससे पहले कि कोई वादा करे कि सुरंग इसे ढक लेगी।
Private API Gateway VPC सेवा पक्ष के अधिक निकट है: interface प्रकार का VPC अंतिम बिंदु ऐसा होस्टनाम प्रकाशित करता है जिसके उत्तर निजी पते होते हैं, और आपके परिसर से ट्रैफ़िक सुरंग या समर्पित इंटरकनेक्ट से आता है। अंतिम बिंदु API से जुड़ा होना चाहिए, और प्रमाणपत्र तथा होस्टनाम उस कस्टम डोमेन से मेल खाने चाहिए जिसे कॉल करने वाले उपयोग करते हैं।
Google Cloud VPN सुरंगें सहकर्मी IP पतों से बंधती हैं, नामों से नहीं। DNS अग्रेषण अलग से कॉन्फ़िगर होता है, इसलिए सुरंग पूरी तरह स्वस्थ हो सकती है जबकि दूरस्थ निजी ज़ोन में खोजें अब भी विफल हों।
फिर सीमा का पता लगाएँ
VPC के भीतर किसी VM से वही कनेक्शन चलाएँ। जब वहाँ सफल हो और VPN क्लाइंट से विफल हो, तो अंतर क्लाइंट पथ और सेवा अंतिम बिंदु के बीच है: कोई मार्ग, सुरक्षा समूह, अंतिम बिंदु नीति या नाम। जब दोनों प्रयास विफल हों, तो उस नेटवर्क में कुछ भी सेवा तक नहीं पहुँच सकता, और VPN कभी बाधा नहीं था।
getent hosts db.internal.example
nc -vz db.internal.example 5432नाम की खोज और पोर्ट जाँच अलग-अलग करें, क्योंकि वे अलग-अलग कारणों से विफल होते हैं और यह जोड़ी बताती है कि पथ का कौन-सा आधा टूटा है। सार्वजनिक पते में हल होने वाला नाम आपको बताता है कि निजी DNS ज़ोन लागू नहीं है।