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

पत्ता आच्छादन हा दुसरा सापळा आहे. वेगळ्या, स्पष्ट मालकीच्या श्रेणी या गोष्टी सोप्या ठेवतात; आच्छादित श्रेणींचा अर्थ भाषांतर किंवा पुनर्रचना, आणि यापैकी कोणतेही त्याच पाककृतीचे अदलाबदल करण्यायोग्य स्वरूप नाही.

नवीन नेटवर्कमधील स्रोत आणि अनुप्रयोग सबनेटमधील गंतव्यासह चाचणी करा, नंतर उलट दिशेने पुनरावृत्ती करा. एकदिश चाचणी फक्त एकच दिशा सिद्ध करते.

प्रॉक्सी खरोखरच चांगली सीमा कधी असते

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

या क्रमाने ठरवा: स्थानिक फॉरवर्डिंग, जाहिरात, टेबल सीमा, परतीचे धोरण. जे प्रथम अपयशी होते ते दुरुस्त करा, आणि त्यानंतरच राउटेड मार्ग हेच योग्य उत्तर आहे का ते विचारा.