OpenVPN बिना किसी त्रुटि के शुरू नहीं हो रहा? जर्नल देखें

कमांड लौटता है, सेवा विफल दिखती है, और टर्मिनल तक व्याख्या जैसी कोई चीज़ नहीं पहुँचती। यह खामोशी वही लक्षण है जिसे लोग «OpenVPN शुरू नहीं होता» कहते हैं, और इसका मतलब लगभग कभी यह नहीं होता कि प्रोग्राम बिना कुछ कहे मर गया। इसका मतलब है कि संदेश ऐसे चैनल पर गया जिसे आप नहीं पढ़ रहे थे, या आपने जो शुरू किया वह वह नहीं था जो आपने कॉन्फ़िगर किया। प्रोफ़ाइल को संदिग्ध मानना बंद करते ही दोनों मामलों का निदान एक मिनट से कम में किया जा सकता है।

आउटपुट को चार जगहें सोखती हैं: यूनिट का जर्नल, वह प्लगइन जो कनेक्शन का मालिक है, सुरंग का दूसरा सिरा, और उससे अलग बाइनरी जिसे आप चलता हुआ मानते हैं। हर एक की अपनी जाँच है।

खामोशी का अर्थ है कि आप सही चैनल नहीं देख रहे थे

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

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

जोड़ें systemctl show -p Result -p ExecMainStatus openvpn-client@office ताकि स्वच्छ निकास को सिग्नल से अलग किया जा सके। स्थिति 1 और Result=exit-code किसी प्रोग्राम का निर्णय है; Result=signal या टाइमआउट इसके बजाय पर्यावरण की ओर इशारा करते हैं, और प्रोफ़ाइल संपादन की कोई भी मात्रा उसे नहीं बदलेगी। कुछ भी पुनः आरंभ करने से पहले दोनों मान लिख लें, क्योंकि पुनः आरंभ उस क्षणिक स्थिति को मिटा देता है जिसने उन्हें उत्पन्न किया।

इंस्टेंस का नाम पथ का हिस्सा है

पैकेज किया गया टेम्पलेट यूनिट फ़ाइल पथ नहीं लेता। यह इंस्टेंस का नाम लेता है, और वह नाम प्रोफ़ाइल खोजने के लिए किसी डायरेक्टरी में जोड़ा जाता है: office का अर्थ /etc/openvpn/client/office.conf है, Debian और Ubuntu पैकेजिंग में। जिस फ़ाइल का नाम office-v2.conf है और जिसे @office के रूप में शुरू किया गया, वह कभी पढ़ी नहीं जाती, और यूनिट चुपचाप बाहर निकल जाती है क्योंकि उसके दृष्टिकोण से करने को कुछ नहीं था। खोज डायरेक्टरी क्लाइंट और सर्वर मोड में अलग होती है, इसलिए टेम्पलेट बदलने पर वही गलती बिल्कुल कहीं और इशारा करती है।

यही असंगति खामोश विफलता का सबसे आम स्रोत है, और यह प्रोफ़ाइल में अदृश्य है क्योंकि प्रोफ़ाइल ठीक है। जो वास्तव में मौजूद है उसकी सूची बनाएँ और दोनों नामों की अक्षर दर अक्षर तुलना करें, पैकेजिंग जिस भी एक्सटेंशन की अपेक्षा करती है उस सहित।

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

यदि यूनिट सक्षम है लेकिन कोई इंस्टेंस सूचीबद्ध नहीं है, तो सक्षमता स्वयं ऐसे नाम का संदर्भ दे सकती है जिसका बाद में नाम बदल दिया गया। सही इंस्टेंस को फिर से सक्षम करना आमतौर पर पर्याप्त होता है, और पीछे छूटी पुरानी यूनिट फ़ाइल को हटा देना चाहिए ताकि वह अगले व्यक्ति को भ्रमित न करे। छूटी हुई यूनिट फ़ाइल एक छोटी चीज़ है जो बाद में किसी का एक घंटा बर्बाद करती है।

जब प्लगइन सुरंग का मालिक हो, तो टर्मिनल कुछ नहीं देखता

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

जर्नल में उस सेवा को खोजें जो इसकी मालिक है, फिर उस पार्सिंग को उतनी विस्तार-मात्रा में दोहराएँ जितनी आप पढ़ सकें। नीचे दिए दो कमांड एक ही विफलता के अलग-अलग मालिकों को देखते हैं।

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

स्वतंत्र रन संदेश पढ़ने के लिए है, प्रबंधित कनेक्शन को बदलने के लिए नहीं, और बाद में दोनों अलग होते हैं: DNS एकीकरण, रूट और जीवनकाल प्लगइन के हैं। स्वतंत्र रन में पार्स त्रुटि ठीक करना ऐपलेट के नियंत्रण लेने पर नाम विश्लेषण को अपने आप ठीक नहीं करता, इसलिए दोनों अवलोकन अलग रखें।

दो बाइनरी, एक PATH

हाथ से बनाई गई इंस्टॉल जो /usr/local के अंतर्गत है, शेल कॉल में जीतती है, क्योंकि /usr/local/sbin डिफ़ॉल्ट Ubuntu PATH पर /usr/sbin से पहले आता है। यूनिट आपके PATH का उपयोग नहीं करती; वह ExecStart में लिखा निरपेक्ष पथ चलाती है। इसलिए आपके टर्मिनल में काम करने वाला संस्करण और सेवा के रूप में विफल होने वाला संस्करण वास्तव में अलग प्रोग्राम हो सकते हैं।

कुछ भी फिर से बनाने से पहले दोनों की तुलना करें। तीसरा कमांड ही तर्क का फ़ैसला करता है।

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

एक और पर्यावरणीय अंतर उसी जगह छिपा है। पैकेज की गई यूनिट /run के अंतर्गत उस रनटाइम डायरेक्टरी पर निर्भर करती है जो systemd उसके लिए बनाता है; वह सेटिंग छोड़ने वाली हाथ से लिखी प्रतिस्थापन यूनिट एक भी फ़ाइल खोलने से पहले विफल हो सकती है, और विफलता बिना किसी OpenVPN संदेश के सामान्य अस्वीकृति जैसी दिखती है।

वे विफलताएँ जिनकी रिपोर्ट क्लाइंट नहीं कर सकता

कुछ परिणाम दूर के छोर पर तय होते हैं। जो गेटवे HTTP स्थिति के साथ उत्तर देकर कनेक्शन बंद कर देता है, उसने आपको अपनी स्थिति बता दी है, और अगला उपयोगी कदम आपकी स्थानीय फ़ाइलें नहीं, बल्कि उसका लॉग या क्रेडेंशियल के पीछे का खाता है। उस परिदृश्य में स्थानीय कुछ भी टूटा नहीं है, और भरपाई के लिए प्रोफ़ाइल संपादित करना अगले निदान को कठिन बना देता है। क्लाइंट कॉन्फ़िगरेशन छूने से पहले वह लॉग पढ़ें।

एक और खामोश मामला वह क्लाइंट है जो सही ढंग से काम कर रहा है। क्लाइंट-मोड सुरंग कभी किसी पोर्ट पर नहीं सुनती, इसलिए खुले श्रोता की अपेक्षा करने वाली जाँच कुछ नहीं बताएगी और विफलता जैसी दिखेगी। खाली पोर्ट सूची से निष्कर्ष निकालने से पहले पुष्टि करें कि आपने कौन-सा मोड शुरू किया था।

परतों को क्रम में कीजिए: क्या यूनिट मौजूद है और इंस्टेंस का नाम सही है, क्या कुछ जर्नल या --log फ़ाइल तक पहुँचा, कौन-सी बाइनरी और प्रोफ़ाइल वास्तव में चले, और विफलता स्थानीय है या दूर की। हर उत्तर एक परत हटाता है। प्रोफ़ाइल से शुरू करने का अर्थ है ऐसी फ़ाइल फिर से लिखना जो शायद कभी खोली ही न गई।