एक प्रोफ़ाइल, दो मालिक: NetworkManager या systemd

.ovpn फ़ाइल के साथ तब तक कुछ नहीं होता जब तक कोई उसका मालिक न हो जाए। Pi डेस्कटॉप पर संभावित मालिक NetworkManager हैं, जो आयातित कनेक्शन को अपनी कीफ़ाइल में रखता है, और एक अलग सेवा यूनिट, जो किसी निर्देशिका से कॉन्फ़िगरेशन पढ़ती है। ये दो परिचालन मॉडल हैं जिनमें भंडारण, क्रेडेंशियल का व्यवहार और सक्रियण के नियम अलग हैं। किसी एक को जानबूझकर चुनना ही पूरा काम है; फ़ाइल को दोनों जगह कॉपी करना केवल चुनाव को आकस्मिक बना देता है।

दोनों एक ही मशीन पर काम कर सकते हैं, पर एक ही समय में एक ही टनल पर नहीं, और यह टकराव नेटवर्क की खराबी जैसा दिखता है, कॉन्फ़िगरेशन की नहीं।

एक ही टनल का मालिक होने के दो तरीके

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

ये एक ही चीज़ के दो रूप नहीं हैं। डाउनलोड की गई फ़ाइल संपादित करने से न NetworkManager का सहेजा हुआ बदलता है और न यूनिट का पढ़ा हुआ, और इनमें से कोई भी वह हो सकता है जिसने उस टनल को बनाया जिसे आपने अभी जाँचा है।

उस कनेक्शन का पीछा करें जो डेस्कटॉप वास्तव में उपयोग करता है

प्रलेखित आयात क्रिया, nmcli connection import type openvpn file office.ovpn, प्लगइन के ज़रिए कनेक्शन बनाती है। उसका UUID नोट करें और आगे वही पहचानकर्ता उपयोग करें, क्योंकि नाम संपादित होते हैं और दो कनेक्शन एक ही लेबल साझा कर सकते हैं। nmcli connection show सूची दिखाता है कि क्या मौजूद है, और कनेक्शन के अपने गुण पढ़ने से पता चलता है कि वह किस फ़ाइल से आया और क्या रखता है। अगर आप जो UUID संपादित कर रहे हैं वह वह नहीं है जिसे डेस्कटॉप सक्रिय करता है, तो आपके संपादन केवल सजावट हैं।

रहस्य मालिक के भंडार में रहते हैं। यह पता लगाने के लिए कि कौन सी प्रोफ़ाइल सक्रिय है, हर सहेजा गया रहस्य उँडेलना धीमा और जोखिम भरा है; इसके बजाय कनेक्शन ऑब्जेक्ट से पूछें, और निजी सामग्री वहीं रखें जहाँ मालिक उसकी अपेक्षा करता है।

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

यूनिट टेम्पलेट पर भरोसा करने से पहले उसे पढ़ें

जहाँ पैकेज अपस्ट्रीम शैली की क्लाइंट यूनिट देता है, वहाँ office नाम का इंस्टेंस यूनिट की कॉन्फ़िगर की गई निर्देशिका में %i.conf से मेल खाता है, और 2.6 टेम्पलेट के लिए वह /etc/openvpn/client है। किसी गाइड के उदाहरण पर भरोसा करने से पहले इंस्टॉल की गई यूनिट और कोई भी अतिरिक्त फ़ाइल पढ़ें, क्योंकि डिस्ट्रिब्यूशन पथ बदल देते हैं। टर्मिनल से हाथ से चलाना फ़ाइलों, रहस्यों या अनुमतियों के बारे में सेवा के दृष्टिकोण का कुछ भी साबित नहीं करता। डेस्कटॉप का पासवर्ड संवाद भी इस बात का प्रमाण नहीं है कि किसी गैर-इंटरैक्टिव यूनिट के पास वही पासवर्ड पाने का स्वीकृत तरीका है।

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

पहुँच खोए बिना डुप्लिकेट को हटाएँ

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

फिर वह जीवनचक्र लिखें जो आपने स्वीकार किया: हाथ से सक्रियण, लॉगिन, या बूट और पुनः कनेक्शन। सहेजा गया एंडपॉइंट, दूसरे पक्ष का प्रमाणीकरण और वह संसाधन जाँचें जहाँ टनल को पहुँचना है, क्योंकि डेस्कटॉप फिर से इंस्टॉल करना यह जानने का विकल्प नहीं है कि कौन सा कॉन्फ़िगरेशन चला था।