AWS VPN मा स्थानीय र टाढाको CIDR: कुन पक्ष कुन हो?

तपाईं Site-to-Site VPN का विकल्प खोल्नुहुन्छ, स्थानीय र टाढा भनी लेबल गरिएका दुई CIDR बाकस देख्नुहुन्छ, र तपाईं स्थानीय ठान्ने ठेगानातिर हात बढाउनुहुन्छ: VPC। यो API ले बुझाउने अर्थको उल्टो हो। जडान विकल्पहरूमा LocalIpv4NetworkCidr ग्राहक-गेटवे पक्षको नाम दिन्छ र RemoteIpv4NetworkCidr AWS पक्षको, किनकि जडान ग्राहक गेटवेबाट बन्छ। कन्सोलले यो कहिल्यै ठूलो स्वरमा भन्दैन, र विश्वसनीय देखिने अदलबदललाई कुनै कुराले अस्वीकार गर्दैन।

कन्सोलको लेबलबाट होइन, API कलबाट सुरु गर्नुहोस्

जडान विकल्पको सन्दर्भ एकपटक पूरै पढ्नुहोस् र ध्यान दिनुहोस् कि हरेक विकल्प ग्राहक गेटवेको दृष्टिकोणबाट लेखिएको छ। यो नामाकरणको संयोग होइन। टनेललाई तपाईंको पक्षमा यसलाई अन्त्य गर्ने उपकरणले देख्ने रूपमै वर्णन गरिन्छ, त्यसैले स्थानीय भन्नाले तपाईंको गेटवे पछाडिको नेटवर्क र टाढा भन्नाले AWS गेटवे पछाडिको नेटवर्क बुझिन्छ। IPv4 र IPv6 दुवै फिल्डले एउटै नियम पालना गर्छन्।

केही टाइप गर्नु अघि दुई लेबल टाँसिने कागजमा लेख्नुहोस्: ग्राहक पक्ष, AWS पक्ष। त्यसपछि आफ्ना ठेगाना तिनीहरूमा मिलाउनुहोस्।

भूमिकासहितको काम गरिएको उदाहरण

स्थानीय प्रिफिक्स 10.20.0.0/16 र VPC प्रिफिक्स 10.60.0.0/16 छ भनी मान्नुहोस्। विकल्पहरू भूमिकाले संकेत गरेझैँ पढिन्छन्, स्थानीय दायरा स्थानीय फिल्डमा:

{
  "LocalIpv4NetworkCidr": "10.20.0.0/16",
  "RemoteIpv4NetworkCidr": "10.60.0.0/16"
}

अब त्यही जोडी पिअर उपकरण मिलाउने व्यक्तिलाई दिनुहोस् र जाल कसरी काम गर्छ हेर्नुहोस्। धेरै फायरवालमा स्थानीय भन्नाले टनेल अन्त्य हुने इन्टरफेस र टाढा भन्नाले टाढाको छेउ बुझिन्छ, जुन AWS पक्षका लागि उल्टो म्यापिङ हो। दुवै जना सही हुन सक्छन् र तैपनि कहिल्यै पूरा नहुने टनेल बन्न सक्छ, किनकि दुई शब्दावलीले फरक अन्त्य बिन्दु वर्णन गर्छन्।

कुनै पनि उपकरण छुनु अघि पिअरको शब्दावलीमा कागजमा अभ्यास दोहोर्याउनुहोस्, दुवै CIDR र दुवै लेबलसहित।

पूर्वनिर्धारित मानहरू डिजाइन होइनन्

त्यही सन्दर्भले IPv4 का दुवै फिल्डका लागि पूर्वनिर्धारित रूपमा 0.0.0.0/0 दिन्छ, IPv6 का लागि समान मानसहित। कुनै विद्यमान जडानमा ती मान देख्नुको अर्थ फिल्ड कहिल्यै साँघुरो गरिएको थिएन भन्ने हो, इन्टरनेट इग्रेस मिलाइएको थियो भन्ने होइन। रुट वितरण, सबनेट रुट तालिका र सुरक्षा नियन्त्रणले कुन ट्राफिक साँच्चै पार हुन सक्छ भन्ने अझै तय गर्छन्; CIDR मानले टनेल कुन दायरा छान्न तयार छ भन्ने मात्र वर्णन गर्छ।

त्यसैले साँघुरो मानलाई पूर्वनिर्धारितले बदल्नु टनेल गलत व्यवहार गर्दा लगाउने कुनै अनुकूलता युक्ति होइन। यसले सिलेक्टर फराकिलो बनाउँछ र अरू हरेक तहलाई जस्ताको तस्तै छाड्छ।

पिअर उपकरणले अर्को दृष्टिकोण प्रयोग गर्छ

AWS पक्ष स्पष्ट भएपछि, बाँकी धेरैजसो अलमल पिअर कन्फिगरेसनमै हुन्छ। स्थानीय नेटवर्क र टाढाको नेटवर्क माग्ने उपकरणले आफ्नै इन्टरफेसलाई स्थानीय भन्छ, त्यसैले तपाईंको VPC दायरा त्यसको टाढाको फिल्डमा जान्छ र तपाईंको स्थानीय दायरा त्यसको स्थानीय फिल्डमा जान्छ। यदि यसले बरु ट्राफिक सिलेक्टर जोडीमा माग्छ भने, तपाईं दुवै दिशा स्पष्ट लेख्नुहुन्छ र लेबलभन्दा जोडी मिलाउनु बढी महत्त्वपूर्ण हुन्छ।

उपकरणको फिल्डको नाम होइन, फिल्डको सहायता पढ्नुहोस्। उत्पादकहरूले एही दुई शब्द तीन फरक अवधारणाका लागि पुनः प्रयोग गर्छन्।

त्यसपछि दुवै चरणका लागि टनेलको स्थिति जाँच्नुहोस्, किनकि नमिल्ने सिलेक्टर सामान्यतया दोस्रो चरणको असफलताका रूपमा देखिन्छ, जब पहिलो चरण शान्त रूपमा स्थापित रहन्छ।

विकल्पलाई कागजात होइन, परिवर्तनका रूपमा बदल्नुहोस्

चालु VPN मा जडान विकल्प सम्पादन गर्दा सेवा अवरुद्ध हुन सक्छ, त्यसैले यसलाई समय खिडकी, फर्काउने मान र कसलाई असर पर्छ भन्ने टिप्पणीसहितको मर्मत कार्य मान्नुहोस्। पहिले हालका विकल्प कैद गर्नुहोस्, दुवै CIDR फिल्ड र टनेल विकल्पसहित, ताकि फर्काउनु पुनर्निर्माण होइन, टाँस्नु होस्।

परिवर्तनपछि AWS पक्षबाट र पिअरबाट प्रमाणित गर्नुहोस्: हरेक दायराको एउटा स्रोत अर्कोको गन्तव्यमा पुग्छ, दुवै दिशामा। एउटा पक्षबाट एउटा पिङले एउटै सिलेक्टर प्रमाणित गर्छ।

त्यसपछि भूमिका लेखेर जडानको कागजात अद्यावधिक गर्नुहोस्, ताकि अर्को व्यक्तिले स्थानीय भन्नाले तपाईंको पक्ष हो भनी फेरि पत्ता लगाउनु नपरोस्।