एक प्रोफाइल, दोन मालक: NetworkManager किंवा systemd

.ovpn फाइलसोबत तोपर्यंत काहीही होत नाही जोपर्यंत काहीतरी तिचे मालक होत नाही। Pi डेस्कटॉपवर संभाव्य मालक NetworkManager आहेत, जो आयात केलेले कनेक्शन स्वतःच्या कीफाइलमध्ये साठवतो, आणि एक स्वतंत्र सेवा युनिट, जी डिरेक्टरीमधून कॉन्फिगरेशन वाचते। ही वेगळे साठवण, वेगळे क्रेडेन्शियल हाताळणी आणि वेगळे सक्रियकरण नियम असलेली दोन ऑपरेटिंग मॉडेल्स आहेत। यापैकी एक जाणूनबुजून निवडणे हेच संपूर्ण काम आहे; फाइल दोन्ही ठिकाणी कॉपी करणे निवड केवळ अपघाती करते।

दोन्ही एकाच मशीनवर चालू शकतात, पण एकाच वेळी एकाच टनेलवर नाही, आणि संघर्ष कॉन्फिगरेशनचा दोष नाही तर नेटवर्कचा दोष असे दिसतो।

एकाच टनेलचे मालक होण्याचे दोन मार्ग

NetworkManagerचा OpenVPN प्लगइन एक एडिटर आणि एक सेवा जोडतो जे तुमच्यासाठी कनेक्शन सांभाळतात, आणि OpenVPN प्रोग्राम इन्स्टॉल केल्याने ते एकत्रीकरण इन्स्टॉल होत नाही। स्वतंत्र युनिट ही उलटी रचना आहे: एडिटर नाही, डेस्कटॉप एकत्रीकरण नाही, एक कॉन्फिगरेशन फाइल आणि युनिट देत असलेले अधिकार। पहिले कनेक्शनची स्थिती स्वतःच्या डेटाबेसमध्ये ठेवते, दुसरे ती प्रोफाइल आणि युनिट सांगतात तिथे ठेवते। बहुतेक गोंधळ आयात केलेले प्रोफाइल आणि कॉपी केलेली फाइल एकच वस्तू आहेत या गृहीतकातून येतो।

ती एकाच गोष्टीची दोन दृश्ये नाहीत। डाउनलोड केलेली फाइल संपादित केल्याने NetworkManagerने साठवलेले किंवा युनिटने वाचलेले बदलत नाही, आणि तुम्ही नुकतीच तपासलेली टनेल यापैकी कोणीही बांधली असू शकते।

डेस्कटॉप प्रत्यक्षात वापरत असलेल्या कनेक्शनचा मागोवा घ्या

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

रहस्ये मालकाच्या साठवणीत राहतात। कोणते प्रोफाइल सक्रिय आहे हे कळण्यासाठी प्रत्येक साठवलेले रहस्य ओतणे संथ आणि धोकादायक आहे; त्याऐवजी कनेक्शन ऑब्जेक्टला विचारा, आणि खाजगी सामग्री मालक जिथे अपेक्षा करतो तिथेच ठेवा।

आयात केलेल्या कनेक्शनला चालण्यासाठी ग्राफिकल सत्राची गरज नाही, पण तिला क्रेडेन्शियलचा स्रोत तरीही लागू शकतो। ती देखरेखीशिवाय सुरू होईल का, हे तिच्या परवानग्या आणि रहस्यांवर अवलंबून आहे, डेस्कटॉप असण्यावर नाही।

युनिट टेम्प्लेटवर अवलंबून राहण्यापूर्वी ती वाचा

पॅकेज upstream शैलीची क्लायंट युनिट देत असल्यास, office नावाचे इन्स्टन्स युनिटच्या कॉन्फिगर केलेल्या डिरेक्टरीतील %i.conf फाइलशी जुळते, आणि 2.6 टेम्प्लेटसाठी ती /etc/openvpn/client आहे। मार्गदर्शकातील उदाहरणावर विश्वास ठेवण्यापूर्वी इन्स्टॉल केलेली युनिट आणि कोणत्याही अतिरिक्त फाइली वाचा, कारण वितरणे मार्ग हलवतात। टर्मिनलमधून हाताने सुरू करणे फाइली, रहस्ये किंवा परवानग्यांबद्दल सेवेचा दृष्टिकोन काहीही सिद्ध करत नाही। डेस्कटॉपचा पासवर्ड संवादही याचा पुरावा नाही की इंटरॅक्टिव्ह नसलेल्या युनिटकडे तोच पासवर्ड मिळवण्याचा मान्य मार्ग आहे।

युनिटला फक्त लागेल तेच द्या। एक संदर्भित फाइल वाचता येत नाही म्हणून संपूर्ण सेवा सँडबॉक्स सैल करणे लहान परवानगी-सुधारणा मोठ्या उघडकीसाठी बदलते, आणि त्रुटी सहसा लक्ष देण्याची गरज असलेल्या फाइलचे नाव सांगते।

प्रवेश न गमावता डुप्लिकेट मागे घ्या

दोन्ही मालक टनेल सुरू करू शकत असतील, तर शेवटी एक चुकीच्या क्षणी जिंकेल आणि हरलेल्याचे मार्ग व उपकरण मागे राहतील। अपघाती डुप्लिकेट त्याच्या स्वतःच्या मालकामार्फत काढा, पुनर्प्राप्तीचा मार्ग खुला ठेवा, आणि उरलेला मालक रीबूटनंतरही जोडतो याची खात्री करा। वेगळ्या राउटिंग धोरणांसह दोन जाणूनबुजून वेगळे VPN हा दुसरा डिझाइन प्रश्न आहे, एकाच कनेक्शनसाठी दोन सुरुवातीच्या मार्गांच्या स्पर्धेची परवानगी नाही।

नंतर तुम्ही स्वीकारलेले जीवनचक्र लिहा: हाताने सक्रियकरण, लॉगिन, किंवा बूट आणि पुन्हा कनेक्शन। साठवलेला एंडपॉइंट, दुसऱ्या बाजूचे प्रमाणीकरण आणि टनेलने पोहोचायचे असलेले संसाधन तपासा, कारण डेस्कटॉप पुन्हा इन्स्टॉल करणे कोणते कॉन्फिगरेशन चालले होते हे जाणण्याचा पर्याय नाही।