L2TP/IPsec को IPsec के साथ UDP 1701 की भी आवश्यकता क्यों है

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

दो प्रोटोकॉल, दो पोर्ट सेट

L2TP/IPsec कनेक्शन UDP 500 पर IKE, जहाँ अनुवाद होता है वहाँ UDP 4500 पर NAT ट्रैवर्सल, और जहाँ नहीं होता वहाँ IP प्रोटोकॉल 50 के रूप में ESP का उपयोग करता है। L2TP स्वयं UDP 1701 पर एक सुरंग प्रोटोकॉल है, और यह IPsec द्वारा सहकर्मी को प्रमाणित करने के बाद चलता है। दोनों आधे अलग-अलग तरह से विफल होते हैं, और उनकी रिपोर्ट करने वाली लॉग पंक्तियाँ अलग-अलग घटकों से आती हैं। केवल पहले आधे को कवर करने वाला नियम सेट ऐसा कनेक्शन बनाता है जो बातचीत करता है और फिर सुरंग चरण में मर जाता है।

पोर्ट नंबर परिवहन के अंतिम बिंदुओं का वर्णन करते हैं, और ESP बिल्कुल भी पोर्ट नहीं है। इसी कारण केवल TCP और UDP नियम देने वाला फ़ायरवॉल इंटरफ़ेस पूरी IPsec नीति व्यक्त नहीं कर सकता। प्रोटोकॉल 50 को प्रोटोकॉल के रूप में अनुमति देनी होगी, और केवल UDP का उल्लेख करने वाला नियम उससे कभी मेल नहीं खाएगा।

आवरण ही पोर्ट की व्याख्या करता है

तार पर, L2TP/IPsec कनेक्शन सामान्यतः 500 पर IKE और 4500 पर लिपटा ESP दिखाता है। UDP 1701 हेडर संरक्षित पेलोड के भीतर बैठता है, इसलिए बाहरी इंटरफ़ेस पर कैप्चर उसे नहीं दिखाता। स्थानीय होस्ट को वह डेटाग्राम अब भी L2TP डेमन तक पहुँचाना पड़ता है, और पहुँचाना डीकैप्सुलेशन के बाद होता है। इसलिए 1701 नियम एंडपॉइंट के अपने फ़ायरवॉल का है, तब भी जब कोई मध्यवर्ती बॉक्स वह पोर्ट कभी नहीं देखता।

प्रोसेसिंग का क्रम अधिकांश भ्रम समझाता है। यदि स्टैक होस्ट फ़िल्टर से पहले IPsec नीति लागू करता है, तो डीकैप्सुलेटेड L2TP पैकेट UDP 1701 के रूप में मिलान होता है; यदि क्रम उलटा है, तो नियम सेट बाहरी पोर्ट ही देखता है। दोनों व्यवहार व्यवहार में मौजूद हैं, इसलिए वही नियम सेट एक प्लेटफ़ॉर्म पर काम करता और दूसरे पर विफल होता दिखता है।

क्रम से पथ जाँचें

पहले बाहरी इंटरफ़ेस पर कैप्चर करें और पुष्टि करें कि IKE और लिपटा ESP दोनों दिशाओं में चल रहे हैं। फिर डीकैप्सुलेटेड ट्रैफ़िक के लिए स्थानीय फ़ायरवॉल काउंटर देखें। क्रम मायने रखता है, क्योंकि कुछ भी न दिखाने वाला कैप्चर का अर्थ है कि समस्या होस्ट के ऊपर है।

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

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

पोर्ट स्कैन क्या नहीं दिखा सकता

सही ढंग से कॉन्फ़िगर किए गए सर्वर के विरुद्ध UDP 1701 का बाहरी स्कैन सामान्यतः कुछ नहीं बताता, और यही अपेक्षित परिणाम है। पोर्ट इंटरनेट पर उजागर नहीं है; उस तक केवल तब पहुँचा जाता है जब IPsec सहकर्मी को प्रमाणित कर चुका हो। बंद परिणाम को खराबी मानने से ऐसा पोर्ट खुल जाता है जो बंद ही रहना चाहिए। स्कैन सुरंग के भीतर उतना ही नहीं देख सकता जितना वह एप्लिकेशन ट्रैफ़िक नहीं देख सकता।

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