NAT के ज़रिए L2TP/IPsec: असल में क्या टूटता है और क्यों

यह दावा कि NAT, L2TP/IPsec को तोड़ता है, आधा सच है और इसलिए बेकार है। पता अनुवाद सामान्य है, NAT ट्रैवर्सल ठीक उससे बचने के लिए मौजूद है, और लाखों क्लाइंट हर दिन राउटर के पीछे से जुड़ते हैं। जो टूटता है वह किसी विशेष अदला-बदली का एक विशेष चरण है: IKE को कभी जवाब नहीं मिलता, एन्कैप्सुलेटेड टनल ऐसी नीति से गिरा दी जाती है जो केवल एक प्रोटोकॉल की अनुमति देती है, या टनल के निष्क्रिय रहते मैपिंग की अवधि खत्म हो जाती है। एक बार जान लें कि आप किस चरण में हैं, तो समाधान आम तौर पर एक नियम या keepalive होता है, नया VPN डिज़ाइन नहीं।

मिथक ही ग़लत सवाल है

उपयोगी सवाल यह नहीं है कि “क्या NAT इसे तोड़ता है”, बल्कि यह है कि “अदला-बदली का कौन-सा हिस्सा अनूदित होता है, और अनुवाद करने वाला उपकरण उसके साथ क्या करता है”। L2TP/IPsec परतों वाला प्रोटोकॉल है: IKE बातचीत करता है, ESP सुरक्षा देता है, और L2TP उस सुरक्षा के भीतर PPP ढोता है। पता अनुवाद हर परत के साथ अलग तरह से काम करता है, और विफलता के संकेत अलग पहचाने जा सकते हैं यदि आप त्रुटि संवाद की जगह बातचीत के चरण को देखें।

सफलतापूर्वक वेब ब्राउज़ करने वाला राउटर केवल यह सिद्ध करता है कि स्रोत पोर्ट अनुवाद के साथ TCP काम करता है। यह UDP 500, UDP 4500 या प्रोटोकॉल 50 के बारे में कुछ नहीं कहता, और यह परिनियोजन इन्हीं तीन चीज़ों पर निर्भर है।

चरण 1: IKE को जवाब तो मिलना ही चाहिए

पहली अदला-बदली UDP 500 पर उत्तरदाता की ओर जाती है। यदि कोई जवाब वापस न आए तो बाकी कुछ मायने नहीं रखता: पूर्व-साझा कुंजी, प्रस्ताव और क्रेडेंशियल सब अपठित रह जाते हैं। क्लाइंट के टाइमआउट से अनुमान लगाने के बजाय अनुरोध और जवाब पर नज़र रखें:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

जवाब के बिना अनुरोध का आम अर्थ है कि फ़ायरवॉल या ऊपर का कैरियर पैकेट गिरा रहा है, यह नहीं कि सर्वर ने उसे अस्वीकार किया। किसी प्रस्ताव या प्रमाणपत्र समस्या का नाम लेने वाले सूचना-पेलोड वाला जवाब इसका अर्थ है कि पैकेट पहुँच गए और बातचीत सामग्री पर विफल हुई, जो बिल्कुल अलग मरम्मत है।

जब दोनों पक्ष अनुवाद के पीछे हों, तो आरंभकर्ता को केवल उत्तरदाता तक पहुँचना होता है, इसलिए ज़्यादातर क्लाइंट-पक्षीय परिनियोजन चरण 1 से काम करते हैं। सर्वर-पक्षीय होस्टिंग वह जगह है जहाँ आवक समस्या शुरू होती है, और इसीलिए दोनों स्थितियों पर कभी एक जैसे चर्चा नहीं करनी चाहिए।

चरण 2: एन्कैप्सुलेशन बदल देता है कि फ़ायरवॉल क्या देखता है

ESP एक IP प्रोटोकॉल है, TCP या UDP पोर्ट नहीं, और साधारण पोर्ट पता अनुवाद में फिर से लिखने के लिए कोई पोर्ट फ़ील्ड नहीं होता। इसीलिए NAT ट्रैवर्सल संरक्षित पेलोड को UDP 4500 में ले जाता है: एन्कैप्सुलेशन अनुवाद करने वाले उपकरण को कुछ ऐसा देता है जिसे वह अनूदित करना जानता है। ऐसा होते ही, केवल UDP 500 के लिए लिखा गया फ़ायरवॉल नियम बातचीत की अनुमति देता है और टनल गिरा देता है, जिससे वह उलझाने वाला नतीजा आता है जहाँ लॉग सफल चरण 1 दिखाता है और कोई ट्रैफ़िक नहीं।

NAT पहचाने जाने के बाद IKE अदला-बदली खुद भी UDP 4500 पर जा सकती है, जो उन्हें चौंकाता है जिन्होंने 500 और कुछ नहीं खोला। पथ पर दोनों दिशाओं में दोनों पोर्ट की अनुमति दें, और याद रखें कि स्टेटफुल फ़ायरवॉल प्रवाह को तभी तक रख सकता है जब तक उसे ट्रैफ़िक दिखता है।

प्रोटोकॉल 50 बिना अनुवाद वाले पथों पर और ऐसे पथों पर जहाँ बीच का बॉक्स उसे अनुमति देने के लिए कॉन्फ़िगर है, अब भी मायने रखता है। यदि आप हटाकर निदान करते हैं, तो नियम ढेर में जोड़ने के बजाय परिकल्पना बंद करें: 500, 4500 और ESP की अनुमति दें, पुष्टि करें कि टनल ऊपर आती है, फिर जो अनावश्यक निकले उसे हटाएँ। जिस नियम को कोई समझा न सके, वह ऐसा नियम है जिसे अगली बाधा का कारण बनने पर कोई हटाएगा नहीं। संकुचन को परिवर्तन-रिकॉर्ड में उस चरण के साथ लिखें जिसे उसने ठीक किया, ताकि अगला इंजीनियर उसी अंगूठा-नियम से नहीं, आपके प्रमाणों से शुरू करे।

चरण 3: मैपिंग खत्म होती है और टनल मर जाती है

अनुवाद करने वाला उपकरण जिन प्रवाहों को आगे भेजता है उनके लिए स्थिति रखता है, और उस स्थिति की उम्र होती है। जब कोई उसका उपयोग नहीं करता तो L2TP/IPsec टनल बहुत कम ट्रैफ़िक ढोती है, इसलिए निष्क्रिय टनल अपनी मैपिंग से अधिक जी सकती है और वापसी ट्रैफ़िक पाना बंद कर सकती है। क्लाइंट को भरोसा रहता है कि वह जुड़ा है, सर्वर को कुछ दिखता नहीं, और पहला लक्षण आम तौर पर किसी ऐप्लिकेशन का टाइमआउट होता है, VPN त्रुटि नहीं।

डेड पीयर डिटेक्शन और NAT keepalive इसी के लिए हैं, और दोनों सिरों को उन्हें भेजने के लिए तैयार होना चाहिए। यदि आपका सर्वर अनुवाद के पीछे है, तो Windows पक्ष की आवश्यकता एक प्रलेखित रजिस्ट्री सेटिंग है जो सर्वर को अपने आउटबाउंड पैकेट के लिए UDP एन्कैप्सुलेशन मानने पर मजबूर करती है; इसके बिना उत्तरदाता ESP भेजता है जिसे अनुवाद करने वाला उपकरण वापस मैप नहीं कर सकता। यह सर्वर कॉन्फ़िगरेशन का मामला है, क्लाइंट का नहीं।

WAN पता बदलने से दूसरी दिशा से वही नतीजा आता है: मैपिंग नए पते के इर्द-गिर्द फिर से बनती है, और पुराना सुरक्षा संगठन अब ऐसी टपल की ओर इशारा करता है जो अब मौजूद नहीं है। पुनःकनेक्शन का व्यवहार क्लाइंट कार्यान्वयन का हिस्सा है, इसीलिए “राउटर रीबूट के बाद फिर जुड़ें” एक क्लाइंट पर काम करता है और दूसरे पर हाथ से टॉगल चाहिए।

कैरियर-ग्रेड NAT के पीछे होस्टिंग एक अलग समस्या है

यदि आप घर पर L2TP/IPsec सर्वर होस्ट करके बाहर से उस तक पहुँचना चाहते हैं, तो आवश्यकता बिना माँगी आवक पहुँच है, और NAT ट्रैवर्सल यह नहीं देता। आपके राउटर के सामने कैरियर-ग्रेड NAT का अर्थ है कि ऐसा कोई पोर्ट नहीं जिसे आप फ़ॉरवर्ड करके पहुँचने योग्य बन सकें, क्योंकि सार्वजनिक पता साझा है और मैपिंग केवल आउटबाउंड है।

कोई भी IPsec पास-थ्रू चेकबॉक्स इसे नहीं बदलता, और कोई भी क्लाइंट कॉन्फ़िगरेशन इसकी भरपाई नहीं करता। समर्थित उत्तर हैं वास्तव में पहुँचने योग्य पता, होस्ट किया गया अंतिम बिंदु, या ऐसी संरचना जिसमें हर सहभागी आउटबाउंड कनेक्शन बनाता है। UDP एन्कैप्सुलेशन विनिर्देश मौजूद प्रवाहों के लिए अनुवाद की समस्या हल करता है; जहाँ कैरियर नहीं देता वहाँ यह आवक मार्ग नहीं बनाता।

इसलिए अनुमान लगाने के बजाय नेटवर्क की तुलना करें। वही उपकरण और प्रोफ़ाइल दूसरे अनुमत नेटवर्क पर ले जाएँ और देखें वहाँ कौन-सा चरण विफल होता है। यदि कहीं और काम करे, तो अंतर पथ में है, और यह खोज को पूरे कॉन्फ़िगरेशन के बजाय ऊपर के तीन चरणों तक सीमित कर देता है।