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

बाँकी सबै, रुट स्थापनादेखि पुनः जडानको व्यवहारसम्म, त्यो पहिलो निर्णयबाट आउँछ।

किरिङ नै त्यो फरक हो जसको कसैले उल्लेख गर्दैन

जब NetworkManager सँग VPN प्रोफाइल हुन्छ, पासवर्ड लगइन किरिङमा रहन सक्छ, जुन प्रयोगकर्ता साइन इन गर्दा खुल्छ। ल्यापटपमा त्यो राम्रोसँग काम गर्छ: व्यक्ति उपस्थित हुन्छ, किरिङ खुल्छ, टनेल माथि आउँछ। निगरानीबिना बुट हुने सर्भरमा केही खोल्ने कोही हुँदैन, त्यसैले प्रोफाइल कहिल्यै नआउने रहस्यको प्रतीक्षा गर्छ। जडान कन्फिगर गरिएको देखिन्छ र कहिल्यै सक्रिय हुँदैन।

systemd उदाहरण डिस्कबाट प्रमाणपत्र फाइल पढेर त्यो समस्या टार्छ, जसले फाइललाई तपाईंले सुरक्षित गर्ने वस्तु बनाउँछ। chmod 400 र root को स्वामित्व न्यूनतम हो, र फाइल तपाईंले नियन्त्रण नगर्ने ब्याकअप र इमेज टेम्प्लेटबाट बाहिर रहनुपर्छ।

VPN लाई जडानसँग जोड्नु बुटको ग्यारेन्टी होइन

nm-connection-editor मा, VPN को सट्टा तारयुक्त वा ताररहित जडान छान्नुहोस्, General ट्याब खोल्नुहोस्, स्वतः VPN मा जडान हुने विकल्प टिक गर्नुहोस् र प्रोफाइललाई नाम दिनुहोस्। त्यसपछि प्राथमिक जडान जोडिएको अवस्थामा पुग्दा NetworkManager ले VPN लाई दोस्रो कनेक्सनको रूपमा सक्रिय गर्छ। यो निर्भरता हो, फायरवाल नियम होइन। टनेल माथि आउनुअघिका सेकेन्डहरूमा प्याकेटहरू अझै बाहिर जान सक्छन्, र खोल्न नसकिएको भण्डारण गरिएको रहस्यले मेसिनलाई त्यसबिना अनलाइन राख्छ।

यदि आवश्यकता टनेलबिना केही बाहिर नजाओस् भन्ने हो भने, त्यो भन्नुहोस् र किल स्विच बनाउनुहोस्, किनकि यो सेटिङले एउटा पनि दिँदैन। सस्पेन्ड र रिजुम पनि परीक्षण गर्नुहोस्, किनकि फर्कने बाटोमा दोस्रो कनेक्सन पुनः मूल्याङ्कन गरिन्छ।

systemd उदाहरणलाई मिल्ने फाइलनाम चाहिन्छ

प्रोफाइललाई प्याकेजले अपेक्षा गर्ने क्लाइन्ट डाइरेक्टरीमा राख्नुहोस्, जस्तै /etc/openvpn/client/office.conf, र भित्रबाट प्रमाणपत्र फाइललाई auth-user-pass office.cred ले सन्दर्भ गर्नुहोस्। उदाहरणको नाम प्रत्ययबिनाको फाइलनाम हो, त्यसैले openvpn-client@office ले फाइल office.conf पढ्छ। यसलाई sudo systemctl enable --now openvpn-client@office ले सक्षम गर्नुहोस् र ब्लगको उदाहरणमा भरोसा गर्नुको सट्टा systemctl cat openvpn-client@office ले मिलान पुष्टि गर्नुहोस्।

प्रोफाइलभित्रका बाटोहरू प्रोफाइलसँग होइन, युनिटको कार्य डाइरेक्टरीसँग सापेक्ष रूपमा समाधान गरिन्छ, त्यसैले सापेक्ष ca वा auth-user-pass लाइन हातले परीक्षण गर्दा काम गरे पनि बुट हुँदा असफल हुन सक्छ। युनिटले भेट्टाउनुपर्ने सबैका लागि निरपेक्ष बाटो प्रयोग गर्नुहोस्। त्यसपछि वास्तविक बुटपछि journalctl -u openvpn-client@office -b पढ्नुहोस्; टनेलबिना सक्रिय भएको जनाउने युनिटले सामान्यतया त्यो लगमा हराएको फाइलको नाम दिन्छ।

पुराना प्याकेजहरू फरक टेम्प्लेट नाम दिन्छन्, त्यसैले systemctl list-unit-files 'openvpn*' ले यो होस्टमा कुन छ भनेर तय गर्छ।

पुनः जडानको व्यवहार छुट्टै निर्णय हो

ping-restart भएको प्रोफाइलले टनेल खस्नपछि पुनः बनाउँछ, र रिस्टार्ट निर्देशन भएको युनिटले सेवा तहमा त्यस्तै केही गर्छ। ती तपाईंले छान्ने नीतिहरू हुन्, वंशानुगत रूपमा पाइने पूर्वनिर्धारित मान होइनन्। यदि जडान मागअनुसार मात्र माथि आउनुपर्छ भने, रिस्टार्ट व्यवहार जानाजान हटाउनुहोस् र किन भनेर लेख्नुहोस्। यदि युनिट नेटवर्क प्रयोगयोग्य हुनुअघि सुरु हुन्छ भने, यसलाई पुनः प्रयास नीति चाहिन्छ, किनकि बुट हुँदा एक असफल प्रयास आफै दोहोरिँदैन।

रोक्नु पनि त्यत्तिकै शाब्दिक छ: sudo systemctl disable --now openvpn-client@office ले चलिरहेको उदाहरण रोक्छ र बुट लिङ्क हटाउँछ। केवल अक्षम गर्दा टनेल अर्को रिबुटसम्म चलिरहन्छ, जसले अक्षम गरेर परीक्षण गर्ने र इन्टरफेस माथि नै रहेको देख्ने जो कोहीलाई अचम्मित पार्छ।

रिबुट गर्नुहोस्, त्यसपछि चार कुरा क्रममा जाँच्नुहोस्

सेवा रिस्टार्ट गर्नुले सेवा जाँच्छ; मेसिन रिबुट गर्नुले बुट मार्ग जाँच्छ। रिबुटपछि युनिट माथि आयो, त्यसपछि टाढाको सबनेटका लागि रुट छ, त्यसपछि मेसिनले इन्टरनेटलाई कुन ठेगाना देखाउँछ, र अन्तमा नामहरू टनेलबाट समाधान हुन्छन् भनी पुष्टि गर्नुहोस्। केही गडबड भएमा ती चार जाँच त्यही क्रममा असफल हुन्छन्, जसले पहिलो असफलतालाई उपयोगी बनाउँछ।

रुटबिना सक्रिय युनिटको सामान्य अर्थ प्रोफाइल जोडियो तर सर्भरले कुनै रुट धकेलेन, वा रुट पछि हराएको इन्टरफेसमा स्थापना भयो भन्ने हो। नाम खोजी काम नगर्ने रुटले टनेललाई होइन, DNS कन्फिगरेसनलाई सङ्केत गर्छ।

टनेल माथि आउन नसक्दा के हुनुपर्छ भन्ने अग्रिम निर्णय गर्नुहोस्। सामान्य जडानमा फर्किनु एक नीति हो, र त्यो पहिले सुरु हुने जुनसुकै प्रबन्धकलाई छोड्नुको सट्टा लेखेर राख्नुपर्छ।

सम्बन्धित लेखहरू