GCP BYOIP: सार्वजनिक घोषणा निजी मार्ग होइन
BYOIP प्रिफिक्सलाई साइट र क्लाउडबीच बाँड्न दुई योजना चाहिन्छ। सार्वजनिक घोषणा, प्रत्यायोजन र निजी अर्को हप अलग राख्नुहोस्।
सार्वजनिक ब्लकको एउटा भाग साइटमा रहन्छ र एउटा भाग Google Cloud मा जान्छ। त्यो वाक्यले एउटा होइन, दुई योजना वर्णन गर्छ: इन्टरनेट घोषणा योजना र निजी फर्वार्डिङ योजना। तिनलाई एउटै राउटिङ समस्या मान्नु नै BYOIP डिजाइनहरू गलत हुने ठाउँ हो।
संलग्न वस्तुहरू फरक प्रश्नको उत्तर दिन्छन्, र तीमध्ये एउटाले मात्र प्याकेट अब कहाँ जान्छ भन्ने विषयमा।
तीन वस्तु, तीन प्रश्न
सार्वजनिक रूपमा घोषित प्रिफिक्स भनेको Google ले तपाईंको तर्फबाट इन्टरनेटमा घोषणा गर्ने इकाइ हो। सार्वजनिक रूपमा प्रत्यायोजित प्रिफिक्स भनेको आयात गरिएको ठाउँ समर्थित Cloud स्रोतहरूमा कसरी वितरण गरिन्छ भन्ने हो। VPC मार्ग, VPN बाट Cloud Router मार्फत सिकिएको मार्ग सहित, निजी अर्को हप छान्छ। प्रत्येकको आफ्नै दायरा, आफ्नै API र आफ्नै त्रुटि सन्देश हुन्छ।
तालिका संस्करण छोटो छ।
| Object | Question it answers |
|---|---|
| Public advertised prefix | Which authorized range Google announces publicly |
| Public delegated prefix | How imported space is allocated to Cloud resources |
| VPN or Cloud Router route | Which private next hop carries a destination |
तेस्रो पङ्क्ति मात्र तपाईंको नेटवर्कभित्रको फर्वार्डिङबारे हो।
BYOIP ओभरल्याप चेतावनीले के समेट्छ
Google को BYOIP कागजात घोषित प्रिफिक्सलाई घोषणा इकाइ मान्छ र Google बाहिर घोषित उपप्रिफिक्स सहित ओभरल्याप हुने बाह्य घोषणाबारे चेतावनी दिन्छ। त्यो चेतावनी सार्वजनिक घोषणा योजनाबारे हो। यो तपाईंले थप्न सक्ने हरेक निजी मार्गबारेको कथन होइन।
आयात गरिएको प्रिफिक्सभित्र सानो बाँडफाँट प्रत्यायोजन गर्नु, आफैंमा, बाँकी अर्को स्रोतबाट घोषणा गर्ने अनुमति दिँदैन।
प्रश्न को के घोषणा गर्छ भन्ने दृष्टिकोणबाट सोध्नुहोस्। यदि Google ले पूरै आयात गरिएको प्रिफिक्स घोषणा गर्छ भने, उपप्रिफिक्स घोषणा गर्ने दोस्रो स्रोतले कागजातले चेतावनी दिने ठ्याक्कै त्यही ओभरल्याप सिर्जना गर्छ, तपाईंका VPC मार्ग जतिसुकै सफा देखिए पनि।
निजी मार्गले के निर्धारण गर्छ
VPN बाट सिकिएको प्रिफिक्स इन्टरनेट घोषणा होइन, र BGP को कुनै मात्राले त्यसलाई त्यस्तो बनाउँदैन। यो VPC मार्ग तालिकामा एउटा प्रविष्टि हो जसले त्यो गन्तव्यका लागि ट्राफिक कुन सुरुङ वा गेटवेले बोक्ने भन्ने बताउँछ। त्यो प्रविष्टि योग्य, छानिएको वा प्रयोगयोग्य छ कि छैन भन्ने VPC को आफ्नै राउटिङ नियममा निर्भर छ।
सबैभन्दा लामो प्रिफिक्स मिलान मार्ग तालिकाभित्र लागू हुन्छ, त्यसैले लामो VPN मार्गले सार्वजनिक किनारमा केही नबदली स्थानीय रूपमा जित्न सक्छ।
प्रिफिक्स बाँड्ने: पहिले आउने निर्णय
यदि वास्तुकलाले आधा ब्लक डेटा केन्द्रबाट र आधा Google बाट घोषणा गर्नुपर्ने माग गर्छ भने, केही पनि आयात गर्नुअघि घोषणा योजना टुङ्गो लगाउनुहोस्। Google ले कुन दायराहरू घोषणा गर्न सक्छ, कुन अन्तै घोषित रहन्छन्, र दुवै ओभरल्याप हुन्छन् कि भनी पुष्टि गर्नुहोस्। त्यसपछि प्रत्येक गन्तव्य र त्यसको फिर्ती मार्गका लागि निजी बाटो डिजाइन गर्नुहोस्। यदि प्रदायकहरूले तपाईंले चाहेको विभाजन समर्थन गर्दैनन् भने, लामो VPN प्रिफिक्सले सार्वजनिक किनारको निर्णय रद्द गर्छ भन्ने आशा गर्नुको सट्टा विभाजन नै बदल्नुहोस्।
त्यो क्रम महत्त्वपूर्ण छ किनभने दोस्रो योजनाले पहिलोलाई सुधार्न सक्दैन।
दुवै योजना अलग-अलग प्रमाणित गर्नुहोस्
सार्वजनिक पक्ष gcloud compute public-advertised-prefixes list बाट जाँच्नुहोस् र दायरा र तिनको स्थिति पुष्टि गर्नुहोस्। निजी पक्ष gcloud compute routes list र gcloud compute routers get-status बाट जाँच्नुहोस्, जसले BGP ले वास्तवमा के साटासाट गर्यो देखाउँछ।
आउटपुटको एउटा समूहले इन्टरनेटले के देख्छ भन्ने बताउँछ। अर्कोले तपाईंको ट्राफिक कहाँ जान्छ भन्ने बताउँछ। कुनै पनि अर्कोको ठाउँ लिँदैन।