एउटा प्रोफाइल, दुई मालिक: 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 अर्को डिजाइन प्रश्न हो, एउटै जडानका लागि दुई सुरु बाटो प्रतिस्पर्धा गर्ने अनुमति होइन।

त्यसपछि तपाईंले स्वीकार गर्नुभएको जीवनचक्र लेख्नुहोस्: हातले सक्रियता, लगइन, वा बुट र पुनःजडान। सुरक्षित एन्डपोइन्ट, अर्को पक्षको प्रमाणीकरण र टनेलले पुग्नुपर्ने स्रोत जाँच्नुहोस्, किनकि डेस्कटप पुनः स्थापना गर्नु कुन कन्फिगरेसन चलेको थियो भन्ने जान्नको विकल्प होइन।