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 मध्ये नाही।