Linux पर IPsec के बिना L2TP: xl2tpd, pppd और NAT

सादा L2TP एक लिफ़ाफ़े में PPP है, और कुछ नहीं। यह आपके फ़्रेम ढोता है; उन्हें एन्क्रिप्ट नहीं करता और यह साबित नहीं करता कि दूसरे सिरे पर कौन बैठा है, इसीलिए लगभग हर तैनाती इसके नीचे IPsec डाल देती है। नंगी आवृत्ति चलाने की ईमानदार वजहें अब भी हैं: कोई लैब बेंच, कोई माइग्रेशन कदम, या ऐसी लिंक जो पहले से किसी दूसरे सुरक्षित रास्ते के भीतर है।

अगर आप आगे बढ़ते हैं, तो वह चेतावनी डिज़ाइन नोट में लिखें और वहीं रखें। आगे जो है वह Debian और RHEL परिवार के होस्ट पर मेरा चलाया हुआ परिचालन रास्ता है: कौन-सी फ़ाइल किसकी ज़िम्मेदार है, वह MTU जो क्लासिक अटकन रोकती है, और वे फ़ॉरवर्डिंग नियम जो टनल को क़ीमती बनाते हैं।

तीन फ़ाइलें काम बाँटती हैं

xl2tpd नियंत्रण कनेक्शन समाप्त करता है और हर सत्र PPP डेमॉन को सौंपता है, इसलिए कॉन्फ़िगरेशन दो प्रोग्रामों में बँटा रहता है जो कभी एक-दूसरे की फ़ाइलें नहीं पढ़ते। श्रोता /etc/xl2tpd/xl2tpd.conf में, [lns default] अनुभाग के भीतर रहता है, जो पता पूल को ip range से, सर्वर सिरे को local ip से और PPP को सौंपने को pppoptfile से नाम देता है। require authentication = yes चालू करें, length bit और flow bit सक्रिय रखें, और ऐसा पूल चुनें जिसे होस्ट पर और कुछ इस्तेमाल न करता हो।

PPP नीति उसी फ़ाइल की है जिसका नाम वह विकल्प बताता है, आम तौर पर /etc/ppp/options.xl2tpd: auth, pap, chap और mschap के लिए इनकार, require-mschap-v2, 1460 का MTU और MRU, और वह DNS पता जहाँ लिंक उठने के बाद क्लाइंट पहुँच सके। क्रेडेंशियल फिर तीसरी फ़ाइल हैं, /etc/ppp/chap-secrets, जहाँ दूसरा फ़ील्ड LNS अनुभाग के नाम से मेल खाना चाहिए और चौथा फ़ील्ड पूल से कोई ख़ास पता पिन कर सकता है।

टनल क्यों जुड़ती है और फिर अटकती है

1500 बाइट का Ethernet फ़्रेम ऐसे रास्ते में नहीं समाता जो पहले से अपने हेडरों पर बाइट ख़र्च करता है। बाहरी IPv4 हेडर 20 लेता है, UDP 8, और L2TP हेडर लगभग 12, जिससे PPP और उसके पेलोड के लिए 1460 बचता है। PPP में यही छोटा आंकड़ा घोषित करना बड़े पैकेटों को टुकड़ों में बँटने या बीच में कहीं चुपचाप गिर जाने से रोकता है।

लक्षण ऐसी टनल है जो असली ट्रैफ़िक आने तक स्वस्थ दिखती है: पिंग और नियंत्रण संदेश निकल जाते हैं, फ़ाइल कॉपी अटक जाती है, लॉग में कोई बात उसे समझाती नहीं। दोनों सिरों पर MTU और MRU साथ-साथ घटाएँ। सिर्फ़ क्लाइंट ठीक करने से आम तौर पर कड़ी अटकन रुक-रुक कर आने वाली समस्या बन जाती है, जो निदान के लिए और बुरी है।

एक पोर्ट दो बातचीत ढोता है

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

ठीक उसी क्रम में कैप्चर पढ़ने से पता चलता है कौन-सा चरण विफल हुआ, और PPP प्रमाणीकरण की विफलता xl2tpd संपादित करके ठीक नहीं होगी। साझा पोर्ट एक और आम विफलता समझाता है: जो नियम प्रवाह के सिर्फ़ पहले पैकेटों की अनुमति देता है, वह सत्र स्थापित होने देता है और फिर स्थानांतरण रोक देता है। पूरी बातचीत के लिए 1701, दोनों दिशाओं में अनुमति दें।

टनल को काम का बनाना: फ़ॉर्वर्डिंग और NAT

सत्र अपने आप में सिर्फ़ सर्वर तक पहुँचता है। क्लाइंट की इंटरनेट पहुँच के लिए फ़ॉरवर्डिंग, अपलिंक पर पूल के लिए NAT नियम, और ऐसा DNS चाहिए जिसे लिंक उठने के बाद क्लाइंट सचमुच पूछ सके। पूल को LAN श्रेणी से बाहर भी रहना चाहिए, वरना क्लाइंटों को भेजे गए जवाब टनल में वापस धकेलने के बजाय स्थानीय रूप से पहुँचा दिए जाते हैं।

सर्वर पर sysctl -w net.ipv4.ip_forward=1 से फ़ॉरवर्डिंग चालू करें, iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE से पूल का अनुवाद करें, फिर -i ppp0 -o eth0 के लिए FORWARD नियम से बाहर जाता टनल ट्रैफ़िक और दर्पण नियम के साथ -m state --state RELATED,ESTABLISHED से लौटता ट्रैफ़िक स्वीकारें। इन नियमों को रीबूट के पार टिकाऊ रखें, क्योंकि इनके बिना लौटने वाला सर्वर ठीक टूटे L2TP कॉन्फ़िगरेशन जैसा दिखता है।

सर्वर के अपने LAN तक पहुँचना दूसरा काम है: LAN राउटर पर पूल के लिए वापसी मार्ग जोड़ें, या सर्वर पर proxy ARP चलाएँ। जब LAN के भीतर की कोई चीज़ क्लाइंटों को सीधे संबोधित करनी हो, तब उन्हें NAT के पीछे छिपाना बस बाद के लिए दूसरा डिबगिंग सत्र तय करता है।

नंगा स्टैक क्या नहीं करता, और कैसे जाँचें

इस स्टैक का कोई हिस्सा PPP फ़्रेमों को एन्क्रिप्ट नहीं करता, और इसमें कुछ भी दूर के सिरे को उसी सर्वर के रूप में प्रमाणित नहीं करता जिसे आपने सचमुच चुना था। MS-CHAPv2 क्रेडेंशियल की अदला-बदली को सिर्फ़ देखने वाले श्रोता से बचाता है, फिर भी रास्ते में बैठा हमलावर सत्र में दख़ल कर सकता है। Windows का मूल क्लाइंट L2TP सिर्फ़ IPsec के साथ देता है, इसलिए Linux, राउटर फ़र्मवेयर और तीसरे पक्ष के क्लाइंटों को अपने साथी मानें। नंगे कॉन्फ़िगरेशन को निदान की सीढ़ी मानें, कभी रुकने की जगह नहीं।

तय क्रम में जाँचें: xl2tpd -D को अग्रभूमि में चलाएँ, PPP चरण के लिए जर्नल देखें, दोनों सिरों पर ip addr से दिया गया पता पढ़ें, फिर सत्र उठने के बाद डेटा बहता है यह पुष्टि करने के लिए UDP 1701 कैप्चर करें। अगर चारों मेल खाते हैं और ट्रैफ़िक फिर भी विफल होता है, तो दोष राउटिंग, NAT या MTU में है, ख़ुद L2TP में नहीं।