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 Debian आणि Ubuntu पॅकेजिंगमध्ये /etc/openvpn/client/office.conf असे सोडवले जाते। 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 पर्यंत काही पोहोचले का, कोणती बायनरी आणि प्रोफाइल प्रत्यक्षात चालले, आणि अयशस्वीता स्थानिक आहे की दूरची। प्रत्येक उत्तर एक स्तर काढून टाकते। प्रोफाइलपासून सुरुवात करणे म्हणजे कधीच उघडली नसलेली फाइल पुन्हा लिहिणे।