AWS NAT गेटवेमधून GRE आणि ESP का अयशस्वी होतात

टनेल अयशस्वी होते, सुरक्षा गट आधीच सर्व रहदारीला परवानगी देतो, आणि निष्कर्ष असा काढला जातो की AWS VPN अडवत आहे। ते काहीही अडवत नाही। व्यवस्थापित NAT गेटवे बाह्य प्रोटोकॉलचा दस्तऐवजीकृत संच पुढे पाठवते, आणि मूळ GRE किंवा मूळ ESP त्यात नाही, त्यामुळे तुम्ही जोडलेला कोणताही नियम गेटवेला ते वाहण्यास भाग पाडणार नाही। परवानगी नियम आणि वहन क्षमता या दोन वेगळ्या गोष्टी आहेत, आणि त्यापैकी फक्त एकच तुमच्या बदलण्याच्या हातात आहे।

नियमांचा संच प्रोटोकॉलचा संच नाही

सुरक्षा गट ठरवतो की कोणत्या रहदारीला इन्स्टन्स सोडण्याची परवानगी आहे। NAT गेटवे ठरवते की तो काय अनुवादित आणि पुढे पाठवू शकतो। जेव्हा दुसरी मर्यादा लागू होते, तेव्हा परवानगी देणारा नियम नेमके तेच लक्षण निर्माण करतो जे लोक फायरवॉल समस्या म्हणून चुकीचे वाचतात: पॅकेट इन्स्टन्स सोडतात, नियंत्रण देवाणघेवाण पूर्णही होऊ शकते, आणि साथीदाराकडे काहीही पोहोचत नाही।

AWS चे NAT गेटवे प्रोटोकॉल तपशील व्यवस्थापित सेवेसाठी TCP, UDP आणि ICMP ची यादी करते। हाच संपूर्ण समर्थित संच। दुसऱ्या IP प्रोटोकॉलसाठीचा परवानगी नियम तो वाढवू शकत नाही, कारण नियम गेटवेच्या पुढे पाठवण्याच्या मार्गापर्यंत पोहोचण्याच्या खूप आधी मूल्यांकन केला जातो।

हा फरक महत्त्वाचा आहे कारण दोन्ही अयशस्वीता क्लायंटच्या बाजूने सारख्याच दिसतात आणि त्यांची दुरुस्ती पूर्णपणे वेगळी आहे।

PPTP दाखवते की पोर्ट चाचणी का खोटे बोलते

काहीही सिद्ध न करणाऱ्या पोर्ट तपासणीचे PPTP हे सर्वात स्पष्ट जुने उदाहरण आहे। ते 1723 पोर्टवर TCP नियंत्रण जोडणी उघडते आणि नंतर टनेल डेटा GRE वरून वाहते, जो IP प्रोटोकॉल 47 आहे। प्रोटोकॉल 47 हा TCP पोर्ट 47 नाही, आणि या दोन संख्यांचा एकमेकांशी अंक सामायिक करण्याशिवाय काहीही संबंध नाही।

1723 वर कनेक्टिव्हिटी तपासून पूर्ण झालेला हातमिळवणी पाहणारा ऑपरेटर मार्ग काम करतो असा निष्कर्ष काढतो। त्यानंतर डेटा चॅनेल कधीही एकही पॅकेट पार करत नाही, कारण गेटवेकडे देण्यासाठी GRE आधार नाही। हे जुन्या प्रोटोकॉलच्या आवश्यकतांचे स्पष्टीकरण आहे, PPTP तैनात करण्याचा सल्ला नाही, जे वर्षानुवर्षे अप्रचलित आहे।

नियंत्रण चॅनेल TCP किंवा UDP असून डेटा मार्ग तसा नसलेल्या कोणत्याही प्रोटोकॉलला हाच तर्क लागू होतो।

IPsec फक्त UDP म्हणून टिकतो

IPsec ही अशी परिस्थिती आहे जिथे उत्तर सरळ नाही नसून सशर्त आहे। NAT गेटवेमधून IPsec साठी NAT ट्रॅव्हर्सल ही समर्थित व्यवस्था म्हणून AWS दस्तऐवजीकरण करते। NAT-T वर चर्चा झाल्यावर ESP UDP मध्ये एन्कॅप्स्युलेट होते आणि गेटवे प्रोटोकॉल 50 ऐवजी सामान्य UDP पाहते।

UDP 4500 ला परवानगी दिल्याने एंडपॉइंट्स NAT ट्रॅव्हर्सल वापरू लागत नाहीत। पॅकेट आधीच त्या स्वरूपात असतील तरच ते त्यांना परवानगी देते। क्लायंटच्या स्वतःच्या चर्चेच्या आउटपुटवरून कोणते एन्कॅप्स्युलेशन निवडले गेले ते तपासा, आणि प्राप्त करणाऱ्या बाजूने साथीदाराने ते स्वीकारले याची खात्री करा। मूळ ESP साठी संरचित दोन एंडपॉइंट्स नियमांचा संच काहीही म्हणो, मूळ ESP पाठवत राहतील।

TCP किंवा UDP आधारित VPN दस्तऐवजीकृत वहन संचात बसते आणि तरीही मार्गनिर्देशन, गाळणी किंवा प्रमाणीकरणामुळे अयशस्वी होऊ शकते। संचात बसणे आवश्यक आहे, पुरेसे नाही।

धोरण वाढवण्यापूर्वी मार्ग तपासा

वर्कलोड सबनेटचा प्रत्यक्ष मार्ग आणि त्याच्या पुढील हॉपची ओळख प्रथम तपासा। थेट सार्वजनिक मार्ग, NAT इन्स्टन्स, व्यवस्थापित NAT गेटवे आणि ट्रान्झिट गेटवेमधून खाजगी मार्ग हे चार वेगळे आराखडे आहेत, आणि त्यापैकी फक्त एकच येथे वर्णन केलेली व्यवस्थापित सेवा आहे।

नंतर प्रयत्न केलेला एंडपॉइंट, पत्ता कुटुंब, बाह्य प्रोटोकॉल आणि प्रोटोकॉलला पोर्ट असल्यास तो पोर्ट नोंदवा। यशस्वी ब्राउझर विनंतीऐवजी क्लायंटचे निदान आणि नेटवर्क मालकाची प्रवाह निरीक्षणे वापरा, कारण ती फक्त TCP आणि UDP काम करतात हे सिद्ध करते। त्यानंतर, प्रवाहाच्या दोन्ही दिशांसाठी सुरक्षा गट, सबनेट ACL, अतिथी फायरवॉल आणि सेवा धोरणाचे पुनरावलोकन करा।

सेवा वाहू शकत नाही अशा वहनाची भरपाई करण्यासाठी सर्व रहदारी उघडू नका। नियम बदल ते दुरुस्त करणार नाही, आणि ते घटनेनंतरही टिकेल।

जेव्हा वहन बसत नाही

बाह्य प्रोटोकॉल समर्थित संचाबाहेर असल्यास, उपाय स्थापत्यविषयक आहे: मार्ग वाहू शकेल असे वहन निवडा, किंवा तुम्हाला आवश्यक असलेले वाहणाऱ्या गोष्टीकडे बहिर्गमन हलवा। OpenVPN UDP वर, WireGuard UDP वर आणि TLS आधारित टनेल सर्व दस्तऐवजीकृत संचात बसतात। विशिष्ट प्रोटोकॉल पार होणे आवश्यक असल्यास आणि ते चालवण्याचा खर्च स्वीकारार्ह असल्यास ग्राहक-व्यवस्थापित NAT इन्स्टन्स हा पर्याय आहे।

इनबाउंड VPN सर्व्हर होस्ट करणे ही वेगळ्या उत्तराची वेगळी समस्या आहे। NAT गेटवे बहिर्गामी अनुवाद देते आणि सामान्य इनबाउंड पोर्ट फॉरवर्डिंग देत नाही, म्हणून त्यामागील सर्व्हरला स्वतःच्या अटींवर रचलेला मंजूर सार्वजनिक प्रवेश आवश्यक आहे।

कामाचा क्रम: बाह्य प्रोटोकॉलचे नाव द्या, पुढील हॉपची खात्री करा, दस्तऐवजीकृत संचाशी तुलना करा, नंतर स्थापत्य किंवा वहन बदला। वेगळा पोर्ट क्रमांक GRE ला TCP करू शकत नाही, आणि आणखी एक परवानगी देणारा नियम पूर्ण झालेल्या नियंत्रण देवाणघेवाणीला कार्यरत डेटा चॅनेल करू शकत नाही।