AWS Site-to-Site VPN से NAT Gateway: VGW बनाम 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 instance बिना परेशानी इंटरनेट तक पहुँचता है. इनमें से कोई भी अवलोकन टूटी दिशा की जाँच नहीं करता.

व्यवहार में पैकेट ऑन-प्रिमाइसेस नेटवर्क के स्रोत पते के साथ आता है और उसे अनुवादित करने वाला कोई समर्थित अगला hop नहीं मिलता. तालिकाओं के अनुसार इसे egress सीमा पर गिरा दिया जाता है, और चूँकि टनल UP रहती है जबकि उसी subnet का instance इंटरनेट तक पहुँचता है, विफलता ऑन-प्रिमाइसेस firewall समस्या के रूप में दर्ज होती है.

Virtual private gateway बनाम transit gateway

एक virtual private gateway एक ही VPC का होता है. यह VPN समाप्त करता है, उस VPC की route tables में routes डालता है और वहीं रुक जाता है. इसमें attachment मॉडल नहीं है, इसलिए यह दूसरे VPC या साझा egress खंड को ट्रैफ़िक नहीं दे सकता. यही एक-VPC दायरा पूरी सीमा है, और VPC के भीतर जोड़ा गया कोई route इसे नहीं बदलता.

Transit gateway एक क्षेत्रीय केंद्र है जहाँ VPN, हर spoke VPC और साझा सेवाओं का VPC—सब attachments के रूप में दिखते हैं. इसकी अपनी route tables हैं, जो तय करती हैं कि कौन-सा attachment कोई दिया गया prefix पाएगा.

यही केंद्र केंद्रीकृत egress संभव बनाता है: VPN एक attachment के रूप में उतरता है, egress VPC दूसरे के रूप में, और transit gateway की route table इंटरनेट की ओर के prefixes पहले से दूसरे तक भेजती है. virtual private gateway के साथ भेजने के लिए दूसरा attachment नहीं होता, इसलिए डिज़ाइन बाद में पैच करके नहीं बनाया जा सकता.

समर्थित egress पथ, क़दम दर क़दम

संदर्भ डिज़ाइन में पाँच hops हैं और हर तीर एक routing निर्णय है जो आपको कॉन्फ़िगर करना है. ट्रैफ़िक ऑन-प्रिमाइसेस नेटवर्क से Site-to-Site VPN attachment में निकलता है, transit gateway की route table उसे egress VPC attachment तक भेजती है, जहाँ subnet तालिका उसे public 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 public होना चाहिए, elastic IP और internet gateway तक route के साथ, क्योंकि private 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 के पीछे वास्तविक क्लाइंट से सत्यापित करें और देखें कि वह कौन-सा public स्रोत पता प्रस्तुत करता है. यदि वह NAT gateway का elastic IP है तो अनुवाद हो रहा है; यदि कुछ और है तो आप दूसरा egress माप रहे हैं.

इस विफलता के असममित रूप को जल्दी पहचानना चाहिए. जब एक Availability Zone की NAT subnet तालिका में क्लाइंट prefix तक वापसी route है और दूसरी में नहीं, तो नए कनेक्शन flow किस ज़ोन में गिरता है इसके अनुसार सफल या विफल होते हैं, और इस पैटर्न को ग़लती से अस्थिर इंटरनेट पढ़ा जाता है. टिकट जहाँ खुला था उस ज़ोन को ठीक करने के बजाय आप जिन ज़ोनों को सेवा देते हैं उनकी subnet तालिकाओं की तुलना करें, क्योंकि गायब route ही पूरा दोष है और दूसरी ओर कुछ बदलने की ज़रूरत नहीं.

कब स्पष्ट proxy बेहतर डिज़ाइन है

egress VPC के instance पर HTTP proxy वैध विकल्प है और अक्सर सस्ता भी. क्लाइंट उसे उपयोग करने के लिए कॉन्फ़िगर होते हैं, proxy अपना कनेक्शन बाहर खोलता है, और वापसी पथ सममित routing की पहेली नहीं बल्कि proxy की समस्या बन जाता है. कुछ ही अनुप्रयोगों के लिए यह transit gateway का अधिकांश काम हटा देता है. यह प्रति-उपयोगकर्ता लॉग भी देता है जो NAT gateway नहीं बना सकता.

पर यह पारदर्शी नहीं है. proxy सेटिंग्स की उपेक्षा करने वाला हर तत्व, और HTTP न होने वाला हर प्रोटोकॉल, इस पथ पर नहीं चलेगा.

चुनाव इस पर है कि आपके अनुप्रयोग वास्तव में क्या बोलते हैं और लॉग में कितनी पहचान चाहिए. जहाँ वे HTTP बोलते हैं वहाँ proxy अपनी जगह कमाता है; जहाँ मनमाने प्रोटोकॉल के लिए सामान्य egress चाहिए, वहाँ transit gateway डिज़ाइन वही है जिसका AWS समर्थन करता है. पहले से यह तय करना route tables बनने के बाद पता लगाने से सस्ता है.