OpenVPN ले active (exited) भन्छ? तपाईंले सुरु गरेको इन्स्टेन्स खोज्नुहोस्

तपाईं टनेल जाँच्नुहुन्छ, systemctl status openvpn चलाउनुहुन्छ र Main PID बिना तथा खाली प्रक्रिया सूचीका साथ active (exited) पाउनुहुन्छ। सेवा सुरु भई मर्यो भन्ने स्वाभाविक पाठ हो, त्यसैले तपाईं unit खोल्नुहुन्छ, /bin/true भेट्टाउनुहुन्छ र प्याकेज बिग्रिएको निष्कर्ष निकाल्नुहुन्छ। Debian प्याकेजिङमा त्यो अवस्था डिजाइन अनुसार काम गर्ने wrapper हो, र टनेल यसले सुरु गर्ने instance unit मध्ये एकमा बस्छ। समग्र unit ले कुन इन्स्टेन्सले यो बनायो कहिल्यै भन्दैन।

यो unit मा active (exited) ले वास्तवमा के बुझाउँछ

प्याकेज गरिएको unit एक-पटकको काम हो: यसको ExecStart /bin/true हो, र पूरा भएको unit लाई active (exited) रूपमा रिपोर्ट गरिरहने कुरा RemainAfterExit=yes हो। त्यो निर्देश हटाउनुभयो भने त्यही सफल /bin/true काम inactive (dead) मा टुंगिन्छ, जो मानिसहरूले अपेक्षा गर्ने र विपरीत दिशामा गलत पढ्ने ठ्याक्कै त्यही अवस्था हो। आदेश केवल ठाउँ भर्ने हो, र unit ले अरू unit ले गर्ने कामको रिपोर्ट दिन्छ। यो व्यवस्थामा केही पनि बिग्रिएको छैन, र /bin/true बदल्नु टनेल होइन, प्याकेजिङ सम्झौता बदल्नु हो।

wrapper ले प्रतिनिधित्व गर्छ। प्याकेज कन्फिगरेसन वा यसको systemd जेनेरेटरले दिने instance unit हरू सुरु गर्छ, त्यसैले खाली प्रक्रिया सूचीले टनेलको बारेमा केही प्रमाणित गर्दैन। कुनै इन्स्टेन्स चुनिएको नभए पनि wrapper सफल हुन्छ र केही पनि सुरु गर्दैन। अवस्थाले wrapper चल्यो कि भन्ने जवाफ दिन्छ, टनेल छ कि भन्ने होइन।

कोष्ठकभित्रको शब्द नभई status आउटपुटका तीन लाइन पढ्नुहोस्। Loaded ले systemd ले पढेको unit फाइलको नाम दिन्छ, Active ले अन्तिम सफल चलाइको समय-छाप बोक्छ, र Main PID नहुनु पूरा भएको एक-पटकको कामसँग मिल्छ। ती तीन लाइन नै यो wrapper लाई सुरु भएको एक सेकेन्डपछि खसेको सेवाबाट छुट्याउने उपाय हो।

status फेरि पढ्नुअघि unit हरूको सूची बनाउनुहोस्

के चलिरहेको छ भन्नुअघि systemd लाई के छ भनी सोध्नुहोस्। कुनै इन्स्टेन्स नबनाई टेम्प्लेट स्थापना गरिएको हुन सक्छ, र बनेको unit ले मात्र टनेल बोक्छ। लोड भएको सेटबाट सुरु गर्नुहोस्:

systemctl list-units 'openvpn*'

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

systemctl list-unit-files 'openvpn*'

दुवै सूची सँगै पढ्नुहोस्, किनकि दोस्रोमा टेम्प्लेट र पहिलोमा इन्स्टेन्स दुई फरक जवाफ हुन्। भएको टेम्प्लेट र चलिरहेको इन्स्टेन्स एउटै तथ्य होइन, र दोस्रोले मात्र टनेल बुझाउँछ। प्याकेज लेआउट वितरण र OpenVPN संस्करणअनुसार पनि फरक पर्छ। पुरानो openvpn@ टेम्प्लेट, अलग client र server जोडी, र वितरण wrapper सबै आ-आफ्नो प्याकेजिङमा वैध हुन सक्छन्।

तपाईंले भेट्टाउनुभएको ट्युटोरियलअनुसार नभई आफ्नो मेसिनअनुसार मिलाउनुहोस्। अरूको आउटपुटमा इन्स्टेन्सको नाम office हुन सक्छ जबकि तपाईंको home वा work हुन्छ। सर्ने कुरा विधि हो, स्ट्रिङ होइन।

इन्स्टेन्सको नामबाट यसले पढ्ने फाइलसम्म जानुहोस्

upstream client टेम्प्लेटमा unit को कार्य डाइरेक्टरी /etc/openvpn/client हो र यसको आदेशले त्यहीँबाट %i.conf लिन्छ, त्यसैले openvpn-client@office ले /etc/openvpn/client/office.conf पढ्छ। उदाहरणलाई विश्वास गर्नुको सट्टा स्थापित unit मा त्यो म्यापिङ पुष्टि गर्नुहोस्, किनकि तपाईंको टेम्प्लेट पुरानो वा वितरणले पुनर्लेखन गरेको हुन सक्छ:

systemctl cat [email protected]

त्यो आउटपुटको तल देखिने drop-in हरू पढ्नुहोस्, किनकि .d/ मुनिको फाइलले ExecStart, कार्य डाइरेक्टरी वा कन्फिगरेसन मार्ग बदल्न सक्छ। तपाईंले office.ovpn का रूपमा डाउनलोड गरेको प्रोफाइल इन्स्टेन्सले खोल्ने फाइल होइन। यही अन्तरले तपाईंले कहिल्यै सम्पादन नगरेको मार्ग त्रुटिले नाम दिने सामान्य कारण हो।

प्रोफाइलभित्रका सापेक्ष मार्ग अर्को जाल हो। ca, cert र key सन्दर्भ सापेक्ष राख्दै मुख्य फाइल सार्दा हराएको-फाइल त्रुटिको ठाउँ अर्को हराएको-फाइल त्रुटिले लिन्छ। दोस्रोले तपाईंलाई अवश्य छ भन्ने लागेको फाइल देखाउँछ, त्यसैले फाइल नामभन्दा प्रोफाइल डाइरेक्टरी महत्त्वपूर्ण हुन्छ।

यसलाई सुरु गर्नुहोस्, अनि त्यो इन्स्टेन्सको जर्नल पढ्नुहोस्

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

sudo systemctl start [email protected]
journalctl -u [email protected] -b

सुरु गर्नु र सक्षम गर्नु अलग निर्णय हुन्: start ले unit अहिले चलाउँछ, enable ले अर्को बुट मिलाउँछ, र enable --now दुवै एकै चरणमा गर्छ। daemon-reload ले unit परिभाषा फेरि पढ्छ र चलिरहेको प्रक्रिया पुनः सुरु गर्दैन वा सम्पादित प्रोफाइल लागू गर्दैन। प्रोफाइल बदलेपछि इन्स्टेन्स पुनः सुरु गर्नुहोस्, किनकि फाइल फेरि पढ्ने त्यही हो।

एउटै टनेलमा दोस्रो म्यानेजर नराख्नुहोस्

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

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

मूल प्रश्नको जवाफ इन्स्टेन्सको नाम, यसले पढेको फाइल र असफल जर्नल लाइनले दिनुहोस्। systemd एकीकरणबारे OpenVPN का टिप्पणीहरू टेम्प्लेट लेआउट र इन्स्टेन्सको नाम समाधान हुने फाइल म्यापिङ वर्णन गर्छन्।