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 आफैंमा होइन।