AWS VPN मा स्थानीय सबनेट थप्नुहोस्: VGW वा Transit Gateway

विद्यमान 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 स्रोत प्रिफिक्सतर्फ फिर्ती मार्ग चाहिन्छ, र दुवै छेउको सुरक्षा नीतिले त्यो स्रोत र गन्तव्य जोडीलाई अनुमति दिनुपर्छ। टनेलले ट्राफिक चयनकर्तासँग सुरक्षा दायरा वार्ता गरेमा नयाँ प्रिफिक्स त्यसभित्र हुनुपर्छ, नत्र कुनै पनि रुट टेबल हेर्नुअघि नै प्याकेट खारेज हुन्छ।

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

नयाँ सञ्जालमा स्रोत र अनुप्रयोग सबनेटमा गन्तव्य राखेर परीक्षण गर्नुहोस्, त्यसपछि विपरीत दिशामा दोहोर्‍याउनुहोस्। एकदिश परीक्षणले एउटा मात्र दिशा प्रमाणित गर्छ।

प्रोक्सी साँच्चै राम्रो सीमा कहिले हुन्छ

आवश्यकता साँघुरो सेवा इन्टरफेस हुँदा, अनुप्रयोगले पहिले नै त्यो आर्किटेक्चर अपेक्षा गर्दा, वा तपाईं नचाहनुभएको अनुवादबिना सञ्जाल मार्गले प्रिफिक्स बोक्न नसक्दा प्रोक्सीले आफ्नो स्थान कमाउँछ। कसैले जाँच नगरेको रुट टेबल प्रविष्टिका लागि यो वैकल्पिक उपाय होइन।

यो क्रममा निर्णय गर्नुहोस्: स्थानीय फर्वार्डिङ, घोषणा, टेबल सीमा, फिर्ती नीति। पहिलो असफल हुने सुधार्नुहोस्, र त्यसपछि मात्र रुट गरिएको मार्ग नै सही उत्तर हो कि भनी सोध्नुहोस्।