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 इन्स्टन्स अडचणीशिवाय इंटरनेटपर्यंत पोहोचते. या दोन्ही निरीक्षणांपैकी कोणीही तुटलेली दिशा तपासत नाही.

प्रत्यक्षात पॅकेट ऑन-प्रिमाइसेस स्रोत पत्त्यासह येते आणि त्याचे भाषांतर करणारा समर्थित पुढील hop सापडत नाही. तक्त्यांनुसार ते egress सीमेवर टाकले जाते, आणि टनेल UP राहत असल्याने व त्याच subnet मधील इन्स्टन्स इंटरनेटपर्यंत पोहोचत असल्याने अपयश ऑन-प्रिमाइसेस 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 सर्व 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 बांधल्यानंतर शोधण्यापेक्षा स्वस्त आहे.