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 वह मामला है जहाँ उत्तर सपाट ना नहीं बल्कि सशर्त है। AWS, NAT गेटवे के माध्यम से IPsec के लिए NAT ट्रैवर्सल को समर्थित व्यवस्था के रूप में प्रलेखित करता है। 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 नहीं बना सकती, और एक और अनुमतिपूर्ण नियम पूर्ण नियंत्रण विनिमय को काम करने वाले डेटा चैनल में नहीं बदल सकता।