नेटवर्क संवाद में L2TP विकल्प गायब: क्या इंस्टॉल करें

आप एक VPN कनेक्शन जोड़ते हैं, सूची में L2TP/IPsec ढूँढते हैं, और वह वहाँ नहीं है। या वह वहाँ है, प्रोफ़ाइल सहेजा जाता है, और कनेक्शन प्लगइन के बारे में संदेश के साथ मर जाता है। दोनों लक्षण ऐसे पैकेजों के ढेर की ओर इशारा करते हैं जो स्वतंत्र रूप से इंस्टॉल होते हैं, और संवाद आपको केवल उसका अंत दिखाता है। कुछ भी इंस्टॉल करने से पहले टुकड़ों का नक्शा बनाएँ।

मेन्यू से नहीं, ढेर से शुरू करें

विकल्प तब दिखता है जब प्रबंधक को ऐसा प्लगइन मिलता है जो उस VPN प्रकार का प्रचार करता है। उस प्लगइन को बदले में चलने के समय L2TP डेमॉन और IPsec कार्यान्वयन चाहिए, साथ ही कड़ी के लिए PPP मॉड्यूल भी। इनमें से हर एक अपनी निर्भरता-श्रृंखला वाला अलग पैकेज है, और कोई वितरण इन्हें ऐसे संयोजनों में भेज सकता है जो केवल आंशिक रूप से पूर्ण हों। अकेले IPsec डेमॉन इंस्टॉल करने से सूची में कुछ नहीं जुड़ता, क्योंकि प्रबंधक उसे नहीं ढूँढ रहा है। पहले इंस्टॉल किए गए प्लगइन पढ़ें, फिर नीचे की ओर बढ़ें।

मेन्यू में गायब प्रविष्टि पैकेजिंग का सवाल है। यह लगभग कभी कॉन्फ़िगरेशन का सवाल नहीं होता, चाहे कितना भी वैसा लगे।

संपादन और चलाना अलग पैकेज हैं

सेवा प्लगइन कनेक्शन स्थापित करता है, और संपादक घटक वह है जो डेस्कटॉप सेटिंग्स विंडो को प्रोटोकॉल विकल्प दिखाने और सहेजने देता है। इन्हें अलग पैकेज किया जाता है, और कुछ वितरण एक को दूसरे के बिना भेजते हैं। नतीजा एक ऐसा कनेक्शन है जो मौजूद है, कमांड लाइन से शुरू हो सकता है, और ग्राफ़िकल उपकरण में संपादित नहीं हो सकता।

पैकेज का नाम चुनने से पहले चालू डेस्कटॉप वातावरण देखें। GNOME का संपादन घटक KDE फ़्रंटएंड जैसा पैकेज नहीं है, और वितरण दोनों में से किसी का नाम बदल सकता है। नाम उस रिलीज़ की अपनी पैकेज सूची से लें।

PPP प्लगइन संस्करण वाले पथ पर रहता है

L2TP PPP पर चलता है, और सेवा जो प्लगइन लोड करती है वह किसी विशेष PPP संस्करण के विरुद्ध बना होता है, इसलिए वह उस संस्करण के नाम वाली निर्देशिका के नीचे रहता है। जो विधि पुराने पथ को कठोरता से लिखती है वह उसी मशीन का वर्णन करती है जिस पर वह लिखी गई थी। अगर यहाँ संस्करण अलग है, तो कमांड कितनी भी सावधानी से कॉपी की गई हो, प्लगइन नहीं मिलेगा।

कॉपी किए गए बिल्ड के मुकाबले वितरण के पैकेज के पक्ष में यह सबसे मज़बूत तर्क है। पैकेज अनुरक्षक इस पथ पर नज़र रखते हैं; कॉपी की गई configure पंक्ति ऐसा नहीं करती।

बातचीत की विफलता इंस्टॉलेशन की विफलता नहीं है

एक बार विकल्प मौजूद हो और प्रोफ़ाइल सहेजा जाए, तो अगली विफलता दूसरे वर्ग की समस्या है। साथी द्वारा प्रमाणीकरण अस्वीकार करना IPsec बैकएंड है जो आपको कुछ विशिष्ट बता रहा है।

कुछ भी दोबारा इंस्टॉल करने से पहले बैकएंड का अपना लॉग पढ़ें। प्रबंधक का जर्नल दिखाता है कि प्लगइन सौंप रहा है और IPsec डेमॉन बता रहा है कि वह क्यों रुका, और वे दो पंक्तियाँ मिलकर तय करती हैं कि किस पक्ष ने मना किया। संपादक दोबारा इंस्टॉल करने से अस्वीकृत पूर्व-साझा कुंजी ठीक नहीं होती, और प्लगइन दोबारा इंस्टॉल करने से वह सर्वर ठीक नहीं होता जो अलग प्रस्तावों की अपेक्षा करता है। पैकेज को छूने से पहले अपने नोट्स में परतें अलग करें।

दो रहस्य, दो फ़ील्ड

IPsec प्रमाणीकरण और उपयोगकर्ता का PPP लॉगिन ऐसे असंबंधित रहस्य हैं जो संयोग से एक ही संवाद में बैठे हैं। एक मशीनों को प्रमाणित करता है, दूसरा व्यक्ति को L2TP सेवा के सामने प्रमाणित करता है, और सर्वर एक स्वीकार कर सकता है जबकि दूसरा अस्वीकार कर सकता है।

खाते का पासवर्ड PPP फ़ील्ड में और साझा रहस्य IPsec फ़ील्ड में रखें, फिर जाँचें कि लॉग ने किसकी शिकायत की। दोनों इनपुट मास्क होने के कारण पासवर्ड को साझा-रहस्य बॉक्स में कॉपी करना एक आम और पूरी तरह खामोश गलती है। जिन पैकेज संस्करणों के साथ आप समाप्त हुए उन्हें लिख लें, क्योंकि अगली मशीन को वही संयोजन चाहिए और संवाद किसी को नहीं बताएगा कि वह क्या है।