AWS Transit Gateway मा धेरै VPC का लागि एउटै साइट-देखि-साइट VPN

यस त्रैमासमा दुई VPC लाई कार्यालयको नेटवर्क चाहिन्छ, र दोस्रो सुरुङमै अनुमान भाँचिन्छ। AWS Transit Gateway ले साझा राउटिङ हबको रूपमा काम गर्न सक्छ: VPN एक पटक जोडिन्छ, र प्रत्येक VPC उही हबमा जोडिन्छ। त्यसपछि स्थानीय नेटवर्क एउटै जडानबाट जोडिएका सबै VPC सम्म पुग्छ। यसले राउटिङको निर्णय कसको हातमा छ भन्ने परिवर्तन गर्छ, र अधिकांश डिजाइनले यही भागमा गल्ती गर्छन्।

VPN जोडाइ र VPC जोडाइहरू एउटै गेटवेमा छुट्टाछुट्टै वस्तु हुन्, त्यसैले राउटिङ सम्बन्धहरू पछि बनाउनुपर्छ।

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

पियरिङ मानिसहरूले अपेक्षा गर्ने छोटो बाटो किन होइन

लोभलाग्दो विकल्प भनेको VPN लाई VPC A मा अन्त्य गरी VPC B लाई त्यसमा पियर गर्नु हो। साधारण VPC पियरिङले A को VPN जडान हुँदै छेउदेखि छेउसम्म ट्रान्जिट दिँदैन। पियरले पियरिङ आफैँले दिने ठेगानाहरूमा मात्र पुग्छ, र VPN छेउ तीमध्ये एक होइन। ट्रान्जिट हबले दिन्छ; पियरिङले तपाईंलाई एउटा जोडी दिन्छ।

त्यो सीमा पियरिङको विशेषता हो, बढाउन सकिने कोटा होइन।

सम्बन्ध र प्रसारले फरक काम गर्छन्

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

पूर्ण रूपमा जोडिएको सानो हब सजिलो अवस्था हो।

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

वर्कलोडका रुटहरू अन्यत्र बस्छन्

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

गतिशील वा स्थिर राउटिङ सचेत रूपमा छान्नुहोस्; पियरिङले दुवैमध्ये केही दिँदैन।

स्थानीय पहुँच नगुमाई स्पोकहरू अलग राख्नुहोस्

जब A र B दुवै कार्यालयसम्म पुग्न सक्छन् तर एकअर्कातर्फ राउट हुनुहुँदैन, तालिकाहरू विभाजन गर्नुहोस्। VPN जोडाइको सम्बन्धित तालिकामा VPC प्रिफिक्सहरू हुन्छन्। VPC जोडाइहरूको सम्बन्धित तालिकामा स्थानीय प्रिफिक्सहरू हुन्छन्, A लाई B सँग जोड्ने रुट बिना। प्रसारले नै त्यो सम्बन्ध उत्पन्न गर्छ, त्यसैले सबै पूर्वनिर्धारित सम्बन्ध स्वीकार्नु पर्दैन।

यो राउटिङ अलगाव हो, र यो अनुप्रयोग अनुमति होइन।

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

हबले सुधार्न नसक्ने कुरा

ठेगाना योजनाहरू अझै ओभरल्याप-रहित हुनुपर्छ, किनकि हबले एउटा प्रिफिक्सलाई दुई वर्कलोड पहिचान गर्न दिँदैन। प्रत्येक VPC जोडाइलाई यसका वर्कलोडले अपेक्षा गर्ने Availability Zone कभरेज चाहिन्छ। BGP सँग, ग्राहक उपकरणका प्रत्येक आवश्यक प्रिफिक्सतर्फ फर्कने रुटहरू डिजाइन र यसको आयात नीतिसँग मिल्नुपर्छ। हराएको घोषणा ठ्याक्कै भाँचिएको सुरुङजस्तै देखिन्छ।

VPN जडान र ट्रान्जिट गेटवे अब साझा पूर्वाधार हुन्।

सुरुङहरूको अनावश्यकता, उपकरण क्षमता, अनुगमन र मर्मतसम्भार सबै निर्भर VPC वरिपरि योजना गर्नुहोस्, प्रत्येकलाई स्वतन्त्र रूपमा जोडिएको मान्नुको सट्टा।

विद्यमान virtual private gateway व्यवस्थाबाट स्थानान्तरणले पनि त्यही स्पष्ट योजना दाबी गर्छ। जोडाइ र नीतिहरू निर्माण गर्नुहोस्, एउटा नियन्त्रित वर्कलोड मार्ग सार्नुहोस्, र पुरानो मार्ग हटाउनु अघि अनुमति दिइएका र अस्वीकार गरिएका सम्बन्धहरू पुष्टि गर्नुहोस्। केन्द्रीकरणले नेटवर्क टोलीलाई साझा जडान व्यवस्थापन गर्न एउटै ठाउँ दिँदा मद्दत गर्छ, र एउटा ठूलो तालिकापछाडि को कससम्म पुग्न सक्छ भनी लुकाउँदा हानि गर्छ।