OpenVPN कहता है active (exited)? वह इंस्टेंस खोजें जिसे आपने शुरू किया

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

इस unit पर active (exited) का असल में क्या अर्थ है

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

wrapper प्रतिनिधित्व करता है। यह उन instance units को शुरू करता है जो पैकेज कॉन्फ़िगरेशन या उसका systemd जनरेटर देता है, इसलिए खाली प्रोसेस सूची टनल के बारे में कुछ साबित नहीं करती। जब कोई इंस्टेंस चुना नहीं गया हो, तब भी wrapper सफल होता है और तब भी कुछ शुरू नहीं करता। स्थिति बताती है कि wrapper चला या नहीं, यह नहीं कि टनल है या नहीं।

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

status फिर पढ़ने से पहले units की सूची बनाएँ

क्या चल रहा है यह पूछने से पहले 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 के नोट्स टेम्पलेट लेआउट और उस फ़ाइल मैपिंग का वर्णन करते हैं जिसके द्वारा इंस्टेंस का नाम हल होता है।