Ubuntu 24.04 में L2TP टूटा: xl2tpd या go-l2tp डेमॉन?

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

प्लगइन IPsec, L2TP और PPP का समन्वय करता है, फिर परिणामी इंटरफ़ेस NetworkManager को सौंपता है। यह स्वयं L2TP लागू नहीं करता।

प्लगइन एक समन्वयक है, डेमॉन नहीं

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

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

मरम्मत चुनने से पहले चरण पढ़ें

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 पर उसी गेटवे के साथ काम करती थी। यह गुम रास्ता या फ़ायरवॉल बदलाव भी नहीं है, क्योंकि वे कहीं और अलग साक्ष्य के साथ विफल होते हैं। प्लगइन दोबारा इंस्टॉल करने से भी यह ठीक नहीं होता, क्योंकि वही डेमॉन फिर चुना जाता है। उपयोगी विवरण डेमॉन का नाम और उसके द्वारा अस्वीकार किया गया संदेश बताता है।

गेटवे की ओर से सुधार दूसरा वैध परिणाम है। जो फ़र्मवेयर विशेषता भेजना बंद कर देता है वह हर क्लाइंट अपग्रेड में टिकता है, जबकि पिन किया गया पैकेज अगली डिस्ट्रीब्यूशन रिलीज़ में तभी टिकता है जब किसी को याद हो कि वह क्यों पिन है।

दोनों रास्तों की तुलना गति के बजाय रखरखाव लागत पर करें। दोनों काम कर सकते हैं; केवल एक ही बोली की असंगति हटाता है।