Ubuntu 24.04 मा L2TP बिग्रियो: xl2tpd कि go-l2tp डेमन?

Ubuntu 24.04 ले NetworkManager को L2TP प्लगइन पछाडिको डेमन चुपचाप बदल्यो। पुरानो बाटोले xl2tpd प्रयोग गर्थ्यो; नयाँ प्याकेजिङले kl2tpd नामको डेमन बनाउने Go कार्यान्वयन ल्याउँछ। प्लगइनले जुन स्थापित छ त्यही सुरु गर्छ, त्यसैले अपग्रेडले तपाईंको प्रोफाइल वा प्रमाणहरू नछोई डेमन बदल्न सक्छ। यही नै सम्पूर्ण खराबी हो: नयाँ डेमनले नचिन्ने नियन्त्रण सन्देश।

प्लगइनले IPsec, L2TP र PPP समन्वय गर्छ, त्यसपछि बनेको इन्टरफेस NetworkManager लाई दिन्छ। यसले आफैं L2TP लागू गर्दैन।

प्लगइन समन्वयक हो, डेमन होइन

network-manager-l2tp ले IPsec सहायक, L2TP डेमन र PPP चलाउँछ र इन्टरफेसलाई डेस्कटपको जडान व्यवस्थापनसँग जोड्छ। वर्षौंसम्म डेमन xl2tpd थियो, र यसको कन्फिगरेसन उल्लेख गर्ने हरेक ट्युटोरियलले त्यही अनुमान पाएको थियो। पछि Debian प्याकेजिङले दुईमध्ये जुनसुकै कार्यान्वयन स्वीकार गर्यो, र 24.04 ले kl2tpd दिने Go संस्करण स्थापना गर्छ। प्रोफाइलमा पहिले कुन डेमन चलेको थियो भन्ने कुनै फिल्डले अभिलेख गर्दैन, त्यसैले सन्देश अस्वीकार नहुँदासम्म परिवर्तन अदृश्य रहन्छ।

दुवै प्याकेज भएको मेसिनले पनि तपाईंले अपेक्षा गरेको चलाउन सक्दैन। छनोट प्लगइनको निर्णय हो, तपाईंले पछ्याएको निर्देशिकाको होइन।

मर्मत छान्नुअघि चरण पढ्नुहोस्

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd _COMM=charon _COMM=pluto

डेस्कटप सूचनामा भर पर्नुको सट्टा एउटा प्रयासलाई सहायकहरूभरि सहसम्बन्ध गर्नुहोस्। त्यो क्वेरीले क्रम कहाँ रोकियो देखाउँछ, र dpkg -l ले कुन कार्यान्वयन स्थापित छ देखाउँछ। IPsec सहकर्मी स्थापित भएपछि देखिने र नियन्त्रण सन्देश वा अपरिचित विशेषता उल्लेख गर्ने असफलता डेमनतर्फ संकेत गर्छ। सुरुङ बन्नुअघिको असफलता भन्नु डेमनसम्म कहिल्यै नपुगेको हो।

पूर्व-साझा कुञ्जी नमिल्ने कुरा IPsec चरणमा टुंगिन्छ र सहकर्मीलाई नाम दिन्छ। सुरुङ उठेपछि PPP प्रमाणको समस्या देखिन्छ र सामान्यतया पढ्न सकिने CHAP वा MS-CHAP अस्वीकृति बोक्छ। दुवै एउटै क्वेरीमा देखिन्छन्, र ती फरक समस्या हुन्।

दुई बाटो, र ती मिसिँदैनन्

sudo apt install xl2tpd
sudo apt purge go-l2tp

त्यो जोडीले xl2tpd राख्छ र त्यसपछि Go डेमन हटाउँछ, प्लगइनलाई गेटवेले बोल्ने बोलीको कार्यान्वयन छान्न दिन्छ। क्रम महत्त्वपूर्ण छ: प्लगइन एउटा वा अर्को कार्यान्वयनमा निर्भर छ, त्यसैले Go प्याकेज पहिले हटाउँदा प्लगइन पनि खस्छ। दोस्रो बाटोले Go डेमन राख्छ र सन्देश बुझ्ने नयाँ बिल्डमा जान्छ, जसको अर्थ सामान्यतया अभिलेख संस्करणको सट्टा मर्मतकर्ताको PPA हो। व्यवस्थापित फ्लीटमा PPA पिन गर्नु प्रयोगकर्तालाई प्याकेज हटाउन सिकाउनुभन्दा सजिलै न्यायोचित हुन्छ।

दुवैलाई एउटै परिवर्तनमा नमिसाउनुहोस्। त्यसपछि पछिको असफलताले कुन आधा भागले मद्दत गर्यो भन्न दिँदैन, र भविष्यको अपग्रेडले भर्खरै हटाएको प्याकेज फर्काउन सक्छ।

टिकटमा डेमनको बाइनरी, यसको संस्करण र ठ्याक्कै सन्देश राख्नुहोस्। रिलिजपछि L2TP बिग्रियो भनेर मात्र भन्ने रिपोर्ट कसैले पुनः उत्पादन गर्न सक्दैन, तर नाम दिइएको विशेषता र प्याकेज संस्करणले उनीहरूलाई सुरुवात दिन्छ।

यो होइन भन्ने तीन कुरा

यो प्रोफाइलको समस्या होइन, किनकि त्यही प्रोफाइल 22.04 मा त्यही गेटवेसँग चलेको थियो। यो हराएको मार्ग वा फायरवाल परिवर्तन पनि होइन, किनकि ती अन्तै फरक प्रमाणसँग असफल हुन्छन्। प्लगइन पुनः स्थापना गर्दा पनि सुधार्दैन, किनकि त्यही डेमन फेरि छानिन्छ। उपयोगी विवरणले डेमन र यसले अस्वीकार गरेको सन्देश नाम दिन्छ।

गेटवे पक्षको सुधार अर्को वैध परिणाम हो। विशेषता पठाउन छाड्ने फर्मवेयर हरेक क्लाइन्ट अपग्रेड जोगिन्छ, तर पिन गरिएको प्याकेज अर्को वितरण रिलिज जोगिन्छ मात्र यदि कसैले यो किन पिन गरिएको हो सम्झन्छ।

दुई बाटोको तुलना गति होइन, मर्मत लागतमा गर्नुहोस्। दुवै काम गर्न सक्छन्; बोलीको असमझदारी हटाउने एउटा मात्र हो।