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 पक्ष से और पीयर से जाँचें: हर रेंज का एक स्रोत दूसरे रेंज के गंतव्य तक पहुँचे, दोनों दिशाओं में। एक तरफ़ से एक पिंग एक ही सिलेक्टर साबित करता है।

फिर भूमिकाएँ लिखकर कनेक्शन का दस्तावेज़ अपडेट करें, ताकि अगले व्यक्ति को फिर से पता न लगाना पड़े कि लोकल का अर्थ आपका पक्ष है।