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 बाजूने आणि पीअरकडून तपासा: प्रत्येक श्रेणीतील एक स्रोत दुसऱ्यातील गंतव्यापर्यंत पोहोचतो, दोन्ही दिशांनी. एका बाजूने एक पिंग एकच सिलेक्टर सिद्ध करतो.

मग भूमिका लिहून कनेक्शनचे दस्तऐवज अद्ययावत करा, जेणेकरून पुढच्या व्यक्तीला स्थानिक म्हणजे तुमची बाजू हे पुन्हा शोधावे लागणार नाही.