Ubuntu 22.04 मा L2TP समय-सकिने समस्या: xl2tpd टनेल बग

डेस्कटपले चलिरहेको जडान देखाउँछ, IPsec सफलताको जानकारी दिन्छ, तर PPP इन्टरफेस कहिल्यै देखिँदैन। सिस्टम लगमा उही टनेल नम्बर UDP 1701 मा प्रयासको समय सकिएसम्म दोहोरिन्छ। पूर्व-साझा कुञ्जी वा सर्भर कन्फिगरेसन सम्पादन गर्नुअघि यो आकार चिन्नुहोस्: Ubuntu 22.04 मा यो सामान्यतया xl2tpd मा प्याकेजिङ रिग्रेसन हो, र सर्भर सधैं सही थियो।

दोहोरिने लग जोडीले तपाईंलाई के भन्छ

असफल सत्रले नियमित अन्तरालमा दुई लाइन छाप्छ: डेमनले आउँदो नियन्त्रण सन्देशका लागि टनेल भेट्टाउँदैन, त्यसपछि पाएका कल र टनेल पहिचानहरू फाल्छ। पछि पुनः प्रयास काउन्टर आफ्नो सीमामा पुग्छ र जडान पोर्ट 1701 समय-सकिएर बन्द हुन्छ। ठेगाना र पहिचान संयोग हुन्; आकार नै महत्त्वपूर्ण हो। IKE पूरा भयो, L2TP नियन्त्रण ट्राफिक आयो, र डेमनले त्यसलाई पहिले नै बनाएको टनेलसँग जोड्न सकेन।

त्यसैले खराबी L2TP नियन्त्रण र PPP बीचमा छ। गोप्य कुञ्जी, PPP विकल्प वा टाढाको सबनेटबारे अझै केही पनि परीक्षण गरिएको छैन।

IPsec साँच्चै सफल भयो भनी पुष्टि गर्नुहोस्

दुई जाँचले यसलाई प्रमाण-पत्र समस्याबाट अलग गर्छ, र दुवै कुनै पनि प्याकेज परिवर्तनअघि गर्नुपर्छ।

ipsec status
journalctl -u strongswan --since "5 min ago" | grep -i "shared key"

स्थिति आउटपुटले जडान र त्यसको अवस्था सूचीबद्ध गर्छ, र स्थापित टनेलको अर्थ पहिलो र दोस्रो चरण पूरा भएको हो। हराएको साझा कुञ्जीबारेको लग लाइनले गोप्य कुञ्जीलाई मात्र संकेत गर्छ, त्यसैले रोक्नुहोस् र पहिले त्यही सुधार्नुहोस्। IPsec स्थापित हुँदा र L2TP समय-सकिने समस्या अझै देखिँदा, डेमन नै बाँकी शंकास्पद हो। दिनभरिको पुनः प्रयासको सट्टा एउटा प्रयासका ठ्याक्कै लाइनहरू राख्नुहोस्।

xl2tpd को बिल्ड जाँच्नुहोस्, रिलिजको नाम होइन

Ubuntu को jammy बिल्डले xl2tpd 1.3.16 का लागि लिङ्क-टाइम अप्टिमाइजेसन सक्षम गर्यो, जसले सर्भरको SCCRP प्रतिक्रियामा टनेल पहिचानको पार्सिङ तोड्यो। त्यसपछि डेमनले आफैं बनाएको टनेलका लागि नियन्त्रण प्याकेट फाल्छ। संस्करण स्ट्रिङ वितरणको नामभन्दा बढी महत्त्वपूर्ण छ।

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

सुधारिएको प्याकेज 1.3.16-1ubuntu0.1 हो, त्यसैले त्यो प्रत्ययबिनाको बिल्ड सुधारअघिको हो। नीति आउटपुटले अपग्रेडले कुन उम्मेदवार स्थापना गर्ने देखाउँछ, र होल्ड सूचीले सुधार किन आएन भन्ने व्याख्या गर्छ। जहाँ प्याकेज उपलब्ध छ, त्यहाँ अपग्रेड गर्नुहोस् र हातले फाइल सम्पादन गर्नुको सट्टा सामान्य प्रोफाइलबाट फेरि जोड्नुहोस्। पुरानो बिल्ड स्थापित रहेसम्म मोड्युल पुनः नबनाउनुहोस् र गोप्य कुञ्जी नबदल्नुहोस्।

परिवर्तनपछि PPP प्रमाणित गर्नुहोस्

सफल अपग्रेड त्यही तहमा प्रमाणित हुन्छ जो बिग्रिएको थियो। आइकन बदलियो कि भनेर मात्र होइन, PPP माथि आयो कि भनेर जाँच्नुहोस्।

ip -4 addr show ppp0
ip route | grep ppp

इन्टरफेस सूचीमा स्थानीय र सहकर्मी ठेगाना देखिनुपर्छ, र रुट तालिकाले टनेलका प्रिफिक्स बोक्नुपर्छ। सिस्टम लगमा टनेल स्वीकारिएको र pppd ले दुवै ठेगाना जनाएको देखिनुपर्छ, टनेल-नभेटिएका लाइन दोहोरिनुहुँदैन। PPP माथि भएर पनि ट्राफिक असफल हुँदा, त्यसपछि राउटिङ वा MTU हेर्नुहोस्, किनकि L2TP चरणले आफ्नो काम सकिसकेको छ। काम गर्ने प्याकेज संस्करण मेसिनको टिप्पणीमा लेख्नुहोस्, ताकि भविष्यको पुनःस्थापनाले बिग्रिएको बिल्ड फर्काउन नपरोस्।

जहाँ सुधारिएको प्याकेज उपलब्ध छैन, त्यहाँ अभिलेखित विकल्पहरू 1.3.16 वा 1.3.17 को स्थानीय स्रोत बिल्ड, kl2tpd मा स्विच, वा पिन गरिएको डाउनग्रेड हुन्। प्रत्येकमा लेख्न लायक मर्मत लागत हुन्छ।