एक मौजूदा Site-to-Site VPN 10.60.0.0/16 ले जाता है, उसी ऑन-प्रिमाइसेस गेटवे के पीछे 10.70.0.0/16 के रूप में एक नया सेवा नेटवर्क दिखाई देता है, और कोई पूछता है कि क्या प्रॉक्सी आवश्यक है। सामान्यतः नहीं: एक रूटेड पथ उपसर्ग ले जा सकता है, पर केवल तभी जब तीन चीज़ें मेल खाएँ, और कौन-सी तीन यह उस AWS आर्किटेक्चर पर निर्भर करता है जिसे आप पहले से चला रहे हैं। वर्चुअल प्राइवेट गेटवे की एक रूट-टेबल सीमा होती है; transit gateway दूसरी जोड़ता है। विज्ञापन सही और टेबल गलत होने पर ऐसा सत्र बनता है जो स्वस्थ दिखता है और कुछ भी नहीं पहुँचाता।

ऐसा उपसर्ग प्रकाशित करें जिसे गेटवे वास्तव में पहुँचा सके

किसी भी विज्ञापन का अर्थ होने से पहले ऑन-प्रिमाइसेस गेटवे को नए नेटवर्क की ओर आगे का रास्ता चाहिए। BGP के माध्यम से 10.70.0.0/16 का विज्ञापन AWS को बताता है कि उस रेंज के पैकेट कहाँ भेजने हैं; यह वह स्थानीय फ़ॉरवर्डिंग पथ नहीं बनाता जो रेंज को दूसरे छोर पर पहुँचने योग्य बनाता है। पुष्टि करें कि गेटवे के पास उपसर्ग के लिए एक रूट है जो उसे रखने वाले डिवाइस की ओर इंगित करता है, और डिवाइस उन पतों के लिए उत्तर देने के लिए कॉन्फ़िगर है। एक्सपोर्ट नीति और स्वीकृत उपसर्ग सीमाएँ अगली बाधा हैं, क्योंकि जिस उपसर्ग को सत्र फ़िल्टर कर देता है वह AWS तक पहुँचता ही नहीं।

एग्रीगेट और अधिक विशिष्ट रूट को जानबूझकर रखें। दो दिशाओं से आने वाले ओवरलैपिंग पथ एक डिज़ाइन निर्णय हैं, बाद में खोजने वाला विवरण नहीं।

पथ एक: वर्चुअल प्राइवेट गेटवे की सीमा

वर्चुअल प्राइवेट गेटवे के साथ, AWS VPN रूटिंग दस्तावेज़ दो वितरण मोड बताते हैं, स्थिर रूट और BGP विज्ञापन, और दोनों उस सबनेट रूट टेबल पर निर्भर हैं जिसका ऐप्लिकेशन वास्तव में उपयोग करता है। प्रोपेगेशन तब सुविधाजनक है जब आप पूरी रेंज नियंत्रित करते हैं, और स्पष्ट रूट के बारे में सोचना आसान है जब आप गंतव्य को लक्ष्य के पास सूचीबद्ध देखना चाहते हैं। किसी भी तरह, जाँच एक ही है: क्या विशिष्ट ऐप्लिकेशन सबनेट की टेबल में नए उपसर्ग के लिए VPN लक्ष्य तक कार्यशील पथ है, और क्या वह किसी अधिक विशिष्ट चीज़ के विरुद्ध जीतता है?

स्वस्थ BGP सत्र सिद्ध करता है कि चैनल मौजूद है। यह नहीं बताता कि किसी दी गई सबनेट टेबल ने रूट लिया या नहीं।

पथ दो: transit gateway एक टेबल जोड़ता है

transit gateway उस एक प्रश्न को दो में बाँटता है। VPC सबनेट को गंतव्य transit gateway अटैचमेंट पर भेजना होता है, और फिर transit gateway रूट टेबल को उसी उपसर्ग के लिए VPN अटैचमेंट चुनना होता है। एसोसिएशन और प्रोपेगेशन के चयन तय करते हैं कि कौन-से जुड़े नेटवर्क रूट पाते हैं, इसलिए कोई उपसर्ग VPN द्वारा सही ढंग से विज्ञापित होकर भी उस VPC तक कभी नहीं पहुँच सकता जिसकी टेबल कभी सही रूट टेबल से जोड़ी ही नहीं गई।

सामान्य विफलता यह है एक ऐसा रूट जो एक टेबल में है और दूसरी में नहीं, और हर टीम आश्वस्त है कि उसका पक्ष सही है। जब आप दोनों आर्किटेक्चर की तुलना करते हैं, तो यह अतिरिक्त सीमा ही पूरा अंतर है: देखने के लिए अधिक जगह, और इस पर अधिक सटीक नियंत्रण कि रूट किसे मिलेगा।

रूट प्रोपेगेशन भी हर अटैचमेंट को उपसर्ग नहीं देता। यह उसे उन टेबलों में वितरित करता है जो उसे प्राप्त करने के लिए कॉन्फ़िगर हैं।

वापसी पथ अपना अलग नीति निर्णय है

आने वाला ट्रैफ़िक आदान-प्रदान का केवल आधा है। नए ऑन-प्रिमाइसेस नेटवर्क को सही गेटवे के माध्यम से AWS स्रोत उपसर्गों तक वापसी रूट चाहिए, और दोनों सिरों की सुरक्षा नीति को उस स्रोत-गंतव्य जोड़ी की अनुमति देनी होगी। यदि टनल ट्रैफ़िक सेलेक्टर के साथ सुरक्षा दायरा तय करता है, तो नया उपसर्ग उसके भीतर होना चाहिए, अन्यथा पैकेट किसी भी रूट टेबल को देखे जाने से पहले गिरा दिया जाता है।

पता ओवरलैप दूसरा जाल है। अलग, स्पष्ट स्वामित्व वाली रेंज इसे सरल रखती हैं; ओवरलैपिंग रेंज का अर्थ अनुवाद या पुनर्डिज़ाइन है, और इनमें से कोई भी उसी विधि का विनिमेय रूप नहीं है।

नए नेटवर्क में स्रोत और ऐप्लिकेशन सबनेट में गंतव्य के साथ परीक्षण करें, फिर दूसरी दिशा में दोहराएँ। एकदिश परीक्षण केवल एक दिशा सिद्ध करता है।

कब प्रॉक्सी वास्तव में बेहतर सीमा है

प्रॉक्सी अपना स्थान तब कमाता है जब आवश्यकता संकीर्ण सेवा इंटरफ़ेस हो, जब ऐप्लिकेशन पहले से उस आर्किटेक्चर की अपेक्षा करता हो, या जब नेटवर्क पथ को उस अनुवाद के बिना उपसर्ग ले जाने के लिए बाध्य न किया जा सके जो आप नहीं चाहते। यह ऐसी रूट टेबल प्रविष्टि के लिए आरक्षित विकल्प नहीं है जिसे किसी ने जाँचा नहीं।

इस क्रम में निर्णय लें: स्थानीय फ़ॉरवर्डिंग, विज्ञापन, टेबल सीमा, वापसी नीति। जो पहला विफल हो उसे ठीक करें, और केवल तब पूछें कि क्या रूटेड पथ ही सही उत्तर है।

संबंधित लेख