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 ठेगानाहरू प्रकाशित गर्छ, र API नामहरूका लागि तपाईंको DNS ले तिनै ठेगाना फर्काउनुपर्छ। दुवै साना प्रिफिक्स हुन् र कुनै पनि 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 रुचाउने क्लाइन्टबारे केही बताउँदैन।
Google को अन-प्रिमाइस Private Google Access सम्बन्धी मार्गदर्शिका ले DNS रेकर्ड र रुटिङ आवश्यकता सँगै समेट्छ, त्यसैले तपाईंको रिजोल्भर र घोषणा सेटिङ कुनै फोरम पोस्टसँग होइन, यसैसँग तुलना गर्नुहोस्। त्यसपछि त्यही अनुरोध फेरि चलाउनुहोस् र जवाफ तथा रुट त्यही टिकटमा टिप्नुहोस्।