VPN पर Google API: सिर्फ़ सबनेट नहीं, VIP पर रूट करें
VPC सबनेट तक का रूट API के VIP पतों को नहीं चुनता। सही नाम हल करें, VIP प्रीफ़िक्स का ऐलान करें, VPC में वापसी का रास्ता रखें, और फिर HTTPS जाँचें।
SSH से ऑन-प्रिमाइस सर्वर में जाएँ, टनल ऊपर लाएँ और निजी VM जवाब देता है; फिर Google API की पहली कॉल बिना रूट के विफल हो जाती है। VM का सबनेट और API के VIP अलग गंतव्य हैं, इसलिए एक के लिए रूट दूसरे को नहीं चुनता। निजी API कॉल काम करने से पहले तीन शर्तें पूरी होनी चाहिए। API का नाम VIP में हल होना चाहिए, VIP प्रीफ़िक्स टनल से होकर ऐलान होना चाहिए, और VPC को पता होना चाहिए कि जवाब कैसे वापस भेजना है। पिंग आपको इनमें से कुछ नहीं बताता, और सबनेट की मशीन तक काम करता SSH सत्र भी नहीं।
API के VIP अलग गंतव्य हैं
Google ऑन-प्रिमाइस नेटवर्क से API पहुँच के लिए समर्पित VIP प्रकाशित करता है, और वही पते हैं जो आपके DNS को API नामों के लिए लौटाने होते हैं। दोनों छोटे प्रीफ़िक्स हैं और कोई भी RFC 1918 स्पेस नहीं है:
| Record | Resolves to | What it does not give you |
|---|---|---|
| private.googleapis.com | 199.36.153.8/30, the general front door for Google APIs | not a bypass around a service perimeter |
| restricted.googleapis.com | 199.36.153.4/30, reachable only for services a perimeter allows | not the whole API surface, so some names stay out of reach |
सार्वजनिक दिखते पते का मतलब यह नहीं कि रूट को टनल छोड़नी चाहिए सामान्य इंटरनेट के लिए। प्रीफ़िक्स इसलिए हैं ताकि ऑन-प्रिमाइस क्लाइंट किसी मनमाने एग्रेस बिंदु के बजाय समर्थित रास्ते से Google के फ़्रंट एंड तक पहुँच सके। इन्हें टनल के गंतव्य मानें, जाँचने के होस्ट नहीं। इंटरनेट एग्रेस के लिए लिखा फ़ायरवॉल नियम इन्हें आमतौर पर गिरा देता है, और यही कॉल के शुरू होने से पहले विफल होने का एक आम कारण है।
किस एंडपॉइंट तक पहुँचते हैं, यह DNS तय करता है
चुने गए एंडपॉइंट के लिए Google जो रिकॉर्ड दस्तावेज़ करता है, उन पर स्थानीय रिज़ॉल्वर सेट करें, ताकि ऐप्लिकेशन को ज़रूरी नाम उसी VIP से जवाब दें। सिर्फ़ googleapis.com करना कोई इन्वेंटरी नहीं है: पैकेज रजिस्ट्रियाँ, कंटेनर रजिस्ट्रियाँ और माइग्रेशन कनेक्टर के अपने दस्तावेज़ी नाम हैं। प्रतिबंधित VIP भी हर सेवा नहीं ले जाता, इसलिए हल होने वाला नाम अब भी असमर्थित हो सकता है। रिज़ॉल्वर को छूने से पहले वे डोमेन लिख लें जिनसे ऐप्लिकेशन वाकई संपर्क करता है।
सेवा नाम की जगह VPC VM पता अनुमान लगाना कोई समाधान नहीं है, और यह आमतौर पर DNS के अंतराल को तब तक छिपाए रखता है जब तक कोई दूसरा क्लाइंट विफल न हो।
VIP प्रीफ़िक्स का ऐलान करें, बाकी रखें
BGP आधारित कनेक्शन में Cloud Router को चुना गया VIP प्रीफ़िक्स ऐलान करना होता है ताकि स्थानीय राउटर उस रेंज को इच्छित सत्र से सीख सके। सिर्फ़ VPC सबनेट का ऐलान उस रेंज को नहीं जोड़ता, और स्थानीय राउटर उन पतों के लिए अपना डिफ़ॉल्ट रास्ता इस्तेमाल करता रहता है। रूटिंग तालिका में मौजूद प्रीफ़िक्स ही एकमात्र सबूत है कि ऐलान सत्र पार कर गया।
नया जोड़ते समय मौजूदा ऐलान बनाए रखें, क्योंकि राउटर-स्तर और पीयर-स्तर के विकल्पों का दायरा अलग होता है, और सेट बदलने से वे नेटवर्क भी हट सकते हैं जो पहले से काम कर रहे थे। फिर पूरे राउटर पर नहीं, हर सत्र पर प्रभावी ऐलान जाँचें। गायब प्रीफ़िक्स और वापस लिया गया प्रीफ़िक्स स्थानीय तरफ़ से एक जैसे दिखते हैं, इसलिए सत्र का दृश्य ही छूट को रिग्रेशन से अलग करता है।
VPC पक्ष को अपना रूट और वापसी का रास्ता चाहिए
VPC के अंदर, VIP का रास्ता अगले हॉप के रूप में डिफ़ॉल्ट इंटरनेट गेटवे इस्तेमाल करना चाहिए, और नाम के बावजूद वह ट्रैफ़िक Google के नेटवर्क में ही रहता है। VPC को VPN से स्थानीय स्रोत तक वापसी का रूट भी चाहिए, जो ऐलान किए गए प्रीफ़िक्स से अलग ऑब्जेक्ट है। जब टनल और क्लाइंट एक ही क्षेत्र में न हों तो दस्तावेज़ी क्षेत्रीय रूटिंग आवश्यकताओं को ध्यान में रखें।
वापसी का रास्ता अलग से जाँचें, क्योंकि काम करती अनुरोध दिशा टूटी जवाब दिशा छिपा सकती है। दो दिशाएँ, दो रास्ते, और हर एक अपने लक्षण के साथ विफल होता है।
अनुरोध जाँचें, फिर अस्वीकृति पढ़ें
इन VIP से ICMP इको को कोई जवाब नहीं मिलता, इसलिए विफल पिंग कुछ साबित नहीं करता और सफल पिंग बहुत कम। असली क्लाइंट से नाम का जवाब और चुना गया रूट देखें, फिर जिस सेवा की आपको परवाह है उस पर अधिकृत HTTPS अनुरोध करें। अगर अनुरोध सेवा तक पहुँचकर अस्वीकार हो जाए, तो क्रेडेंशियल, IAM और लागू होने वाली सेवा परिधि नीति देखें।
निजी रूटिंग API प्राधिकरण नहीं देती और यह नहीं बदलती कि पहचान को क्या करने की अनुमति है। ट्रांसपोर्ट की सफलता और अधिकृत जवाब अलग परिणाम हैं, और आपको दोनों चाहिए। IPv6 का रास्ता भी स्पष्ट रखें, क्योंकि IPv4 प्रीफ़िक्स सेट करना IPv6 पसंद करने वाले क्लाइंट के बारे में कुछ नहीं कहता।
ऑन-प्रिमाइस नेटवर्क से Private Google Access पर Google की मार्गदर्शिका DNS रिकॉर्ड और रूटिंग आवश्यकताओं को साथ-साथ समझती है, इसलिए अपनी रिज़ॉल्वर और ऐलान सेटिंग्स की तुलना किसी फ़ोरम पोस्ट से नहीं, इससे करें। फिर वही अनुरोध दोबारा चलाएँ और जवाब तथा रूट उसी टिकट में दर्ज करें।