AWS Site-to-Site VPN बाट NAT Gateway: VGW vs Transit Gateway

पहिलो पटक सबैले उही रेखाचित्र बनाउँछन्: VPC मा VPN, त्यसपछि NAT gateway बाट इन्टरनेट, सकियो। तर VPN virtual private gateway मा अन्त्य हुँदा AWS त्यो मार्ग समर्थन गर्दैन, र असफलता यति शान्त छ कि टिमहरूले यसलाई एकभन्दा बढी पटक पुनर्निर्माण गर्छन्। काम गर्ने डिजाइनलाई transit gateway चाहिन्छ, जसले दुवै तर्फ gateway र route tables परिवर्तन गर्छ। केही बनाउनु अघि दुवै आकार तुलना गर्नुहोस्।

स्पष्ट देखिने तर समर्थित नहुने टोपोलोजी

AWS को NAT gateway कागजात एउटा रेखा तान्छ जसले एकल VPC डिजाइन मात्र बनाएकालाई अचम्मित बनाउँछ: Site-to-Site VPN जडानको ट्राफिक virtual private gateway मार्फत NAT gateway मा रुट गर्न सकिँदैन। VPN कुन प्रकारको gateway मा अन्त्य हुन्छ भन्नेले अनुवाद मार्ग नै छ कि छैन भन्ने निर्धारण गर्छ। गल्ती टिकिरहन्छ किनकि टनेलको स्थिति UP छ र त्यही subnet को EC2 इन्स्टेन्स समस्या बिना इन्टरनेट पुग्छ। यी दुई अवलोकनमध्ये कुनैले पनि बिग्रिएको दिशा जाँच्दैन।

व्यवहारमा प्याकेट अन-प्रिमाइसेस स्रोत ठेगानासहित आउँछ र त्यसको अनुवाद गर्ने समर्थित अर्को hop भेटिँदैन। तालिकाअनुसार यसलाई egress सीमामा फालिन्छ, र टनेल UP रहँदा त्यही subnet को इन्स्टेन्स इन्टरनेट पुग्ने हुँदा असफलता अन-प्रिमाइसेस firewall समस्या रूपमा रिपोर्ट गरिन्छ।

Virtual private gateway vs transit gateway

एउटा virtual private gateway एउटै VPC को हुन्छ। यसले VPN अन्त्य गर्छ, त्यो VPC का route tables मा routes राख्छ र त्यहीँ रोकिन्छ। यसमा attachment मोडेल छैन, त्यसैले अर्को VPC वा साझा egress खण्डमा ट्राफिक दिन सक्दैन। यही एकल VPC दायरा पूरै सीमा हो, र VPC भित्र थपिएको कुनै route ले यसलाई बदल्दैन।

Transit gateway क्षेत्रीय केन्द्र हो जहाँ VPN, प्रत्येक spoke VPC र साझा सेवाहरूको VPC सबै attachment का रूपमा देखिन्छन्। यसका आफ्नै route tables छन्, जसले कुन attachment ले दिइएको prefix पाउने निर्धारण गर्छन्।

यही केन्द्रले केन्द्रीकृत egress सम्भव बनाउँछ: VPN एउटा attachment का रूपमा अवतरण हुन्छ, egress VPC अर्कोका रूपमा, र transit gateway को route table ले इन्टरनेटतर्फका prefixes पहिलोबाट दोस्रोमा पठाउँछ। virtual private gateway सँग पठाउन दोस्रो attachment हुँदैन, त्यसैले डिजाइन पछि प्याच गरेर बनाउन सकिँदैन।

समर्थित egress मार्ग, पाइला पाइला

सन्दर्भ डिजाइनमा पाँच hops छन् र प्रत्येक वाण तपाईंले कन्फिगर गर्नुपर्ने route निर्णय हो। ट्राफिक अन-प्रिमाइसेस नेटवर्कबाट Site-to-Site VPN attachment मा जान्छ, transit gateway को route table ले यसलाई egress VPC attachment मा पठाउँछ, जहाँ subnet तालिकाले यसलाई सार्वजनिक NAT gateway मा पठाउँछ। NAT gateway ले स्रोत अनुवाद गर्छ र internet gateway ले प्याकेट बाहिर लैजान्छ।

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

अन्तिम hops काम गर्ने वा नगर्ने दुई कुराले निर्धारण गर्छ। NAT gateway सार्वजनिक हुनुपर्छ, elastic IP र internet gateway तर्फ route सहित, किनकि निजी NAT gateway ले नेटवर्कबीच अनुवाद गर्छ र कहिल्यै इन्टरनेट निकास बन्दैन।

तपाईं सेवा दिन चाहनुभएको प्रत्येक Availability Zone का लागि एउटा NAT gateway योजना गर्नुहोस् र प्रत्येक subnet तालिका स्थानीयतर्फ देखाओस्। तपाईंका नोटमा transit gateway तालिका र VPC तालिकाहरू अलग वस्तुका रूपमा राख्नुहोस्, किनकि एउटाले attachment र अर्कोले VPC भित्रको स्रोत छान्छ। एउटैमा मात्र default route भए आधा मार्ग अपरिभाषित रहन्छ र पहिचान गर्न सबैभन्दा कठिन आंशिक असफलता उत्पन्न हुन्छ।

यी डिजाइन फर्कने मार्गमै असफल हुन्छन्

NAT gateway पहिले देखेका flows का लागि stateful छ, त्यसैले बाहिर जाने जडानका उत्तर नयाँ inbound नियम बिना फर्कन्छन्। त्यो गुणले कुनै अन-प्रिमाइसेस सेवा इन्टरनेटमा प्रकाशित गर्दैन, र त्यस्तो मान्नु भनेको टिमले कहिल्यै स्थापित नहुने जडान डिबग गर्दै एक दिन बिताउनु हो। ग्राहकबाट सुरु हुने ट्राफिकका लागि चार routes मिल्नुपर्छ: अन-प्रिमाइसेस नीति, transit gateway तालिका, egress subnet तालिका र NAT subnet तालिका। अन्तिम छुट्यो भने अनुरोध भवन छोड्छ र उत्तर AWS भित्रै मर्छ।

VPN पछाडिको वास्तविक ग्राहकसँग प्रमाणित गर्नुहोस् र उसले कुन सार्वजनिक स्रोत ठेगाना प्रस्तुत गर्छ हेर्नुहोस्। त्यो NAT gateway को elastic IP भए अनुवाद भइरहेको छ; अरू केही भए तपाईं अर्को egress नापिरहनुभएको छ।

यो असफलताको असममित रूप चाँडै चिन्नुपर्छ। जब एउटा Availability Zone को NAT subnet तालिकामा ग्राहक prefix तर्फ फर्कने route हुन्छ र अर्कोमा हुँदैन, नयाँ जडान flow कुन क्षेत्रमा पर्छ त्यसअनुसार सफल वा असफल हुन्छन्, र यो ढाँचालाई गलत रूपमा अस्थिर इन्टरनेट भनेर पढिन्छ। टिकट खुलेको क्षेत्र सुधार्नुको सट्टा तपाईं सेवा दिने प्रत्येक क्षेत्रको subnet तालिका तुलना गर्नुहोस्, किनकि हराएको route नै सम्पूर्ण दोष हो र अर्को तर्फ केही बदल्नु पर्दैन।

कहिले स्पष्ट proxy राम्रो डिजाइन हो

egress VPC को इन्स्टेन्समा HTTP proxy वैध विकल्प हो र प्रायः सस्तो। ग्राहकहरू यसलाई प्रयोग गर्न कन्फिगर हुन्छन्, proxy ले आफ्नै जडान बाहिर खोल्छ, र फर्कने मार्ग सममित routing को पहेली नभई proxy को समस्या बन्छ। थोरै अनुप्रयोगका लागि यसले transit gateway को अधिकांश काम हटाउँछ। यसले NAT gateway ले उत्पादन गर्न नसक्ने प्रयोगकर्ता-आधारित लग पनि दिन्छ।

तर यो पारदर्शी छैन। proxy सेटिङ उपेक्षा गर्ने जुनसुकै कुरा, र HTTP नभएको प्रत्येक प्रोटोकल, त्यो मार्गमा जाँदैन।

छनोट तपाईंका अनुप्रयोगले वास्तवमा के बोल्छन् र लगमा कति पहिचान चाहिन्छ भन्नेमा निर्भर छ। तिनीहरूले HTTP बोल्ने ठाउँमा proxy ले आफ्नो स्थान कमाउँछ; स्वेच्छाचारी प्रोटोकलका लागि सामान्य egress चाहिने ठाउँमा AWS ले समर्थन गर्ने डिजाइन transit gateway हो। यो अग्रिम निर्णय गर्नु route tables बनेपछि पत्ता लगाउनुभन्दा सस्तो छ।