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 रेकॉर्ड आणि राउटिंग आवश्यकता एकत्र समाविष्ट करते, त्यामुळे तुमच्या रिझोल्व्हर आणि जाहिरात सेटिंग्जची तुलना फोरम पोस्टशी नाही, त्याच्याशी करा. नंतर तीच विनंती पुन्हा चालवा आणि उत्तर व मार्ग त्याच तिकिटात नोंदवा.