OpenVPN सुरू झाले पण काहीच छापले नाही: आधी log-append तपासा

तुम्ही कॉन्फिगरेशन फाइलसह शेलमधून OpenVPN सुरू करता, आणि टर्मिनल अजिबात आउटपुट न देता तसेच उभे राहते। कोणतेही बॅनर नाही, त्रुटी नाही, प्रॉम्प्ट नाही। सुरुवात अपयशी ठरली असे वाटते, म्हणून तुम्ही अजून एक प्रत सुरू करता, नंतर आणखी एक, आणि मशीनवर अर्धवट कॉन्फिगर केलेल्या अनेक प्रती राहतात। त्या सर्वांआधी, लॉग आधीच दुसरीकडे वळवणारे निर्देश प्रोफाइलमध्ये आहेत का ते तपासा। शांतता कन्सोलची गुणधर्म आहे, प्रक्रियेची नाही।

शांततेची दोन अगदी वेगळी स्पष्टीकरणे आहेत

पहिले असे की प्रक्रिया व्यवस्थित चालू आहे आणि तुम्ही न पाहत असलेल्या फाइलमध्ये लिहीत आहे। दुसरे असे की ती लगेच त्याच फाइलमध्ये नोंदलेल्या त्रुटीसह बाहेर पडली।

दोन्ही रिकामे टर्मिनल सोडतात, आणि एक प्रश्न त्यांना वेगळा करतो: आता प्रक्रिया आहे का, आणि तिला लिहायला सांगितलेल्या फाइलमध्ये काय आहे। कॉन्फिगरेशन पुन्हा हाताळण्यापूर्वी याचे उत्तर द्या। आउटपुट मिळवण्यासाठी पुन्हा सुरू करणे म्हणजे दोन प्रती एका टनेल उपकरणासाठी आणि त्याच पोर्टसाठी भांडू लागणे, ज्यामुळे मूळ समस्याशी काहीही संबंध नसलेल्या त्रुटी निर्माण होतात।

निर्देश शोधा, नंतर प्रक्रिया शोधा।

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

चालू प्रक्रिया वापरत असलेले गंतव्य शोधा

प्रक्रिया प्रत्यक्षात ज्या प्रोफाइलसह सुरू झाली ते वाचा, तुम्ही संपादित केलेले नाही। सेवेद्वारे व्यवस्थापित प्रत सहसा वेगळा मार्ग लोड करते आणि वेगळ्या कार्यरत डिरेक्टरीत चालते, त्यामुळे सापेक्ष फाइलनाव तुम्ही अपेक्षा न केलेल्या ठिकाणी सोडवले जाते।

स्पष्ट cd निर्देश हा फरक अधिक तीव्र करतो, कारण सापेक्ष मार्ग डिरेक्टरी बदलासोबत हलतो। हे कॉन्फिगरेशन तुम्हाला वारशाने मिळाले असल्यास, फाइल आता कोणीही शोधणार नाही अशा ठिकाणी असू शकते।

फाइलची बदललेली वेळ तुम्ही सुरू केलेल्या क्षणाशी तुलना करा। गेल्या आठवड्यातील लॉग गेल्या आठवड्याबद्दलचा पुरावा आहे। नंतर बदललेल्या फाइलच्या शेवटच्या ओळी वाचा, आणि तिथले जे काही असेल त्याला तुम्हाला हरवलेला सुरुवातीचा संदेश समजा।

log विरुद्ध log-append: पुरावा आणि विलोपन

log-append आधीपासून फाइलमध्ये असलेल्यात भर घालते। log फाइल लिहिण्यासाठी उघडते आणि ती कापून टाकते, त्यामुळे दोन्हींमध्ये बदल केल्यास तुम्ही वाचणार असलेली फेरी नष्ट होऊ शकते।

डीबग करताना कोणी निर्देश बदलला असेल, तर आधीचा पुरावा आधीच गेला आहे आणि फाइलचा आकार संशयास्पदरीत्या लहान दिसेल। दोन फेऱ्यांची तुलना करून काहीतरी बदलले असे निष्कर्ष काढण्यापूर्वी हे जाणून घेणे उपयुक्त आहे। लॉग मुद्दाम हटवा किंवा ठेवा, पण तुम्ही काय केले ते जाणा। मुद्दाम काढलेला पुरावा अपघाताने गमावलेल्या पुराव्यापेक्षा समजून घेणे सोपे आहे।

कोणताही पर्याय गहाळ पालक डिरेक्टर्या तयार करत नाही, आणि फाइलसिस्टम परवानग्या किंवा सेवा सँडबॉक्समधून प्रवेश देत नाही। कॉन्फिगरेशनमध्ये बरोबर दिसणारा मार्ग डेमन ज्या खात्याखाली चालतो त्या खात्याला तरीही न लिहिता येणारा असू शकतो, आणि मग डेमन काहीही कळवण्यापूर्वीच अपयशी ठरू शकतो। फाइलनाव हीच समस्या आहे असे गृहीत धरण्यापूर्वी डिरेक्टरी अस्तित्वात आहे का आणि तिचा मालक कोण आहे ते तपासा।

सेवा रॅपर आउटपुट पकडते तेव्हा

systemd अंतर्गत, स्पष्ट फाइल निर्देशाला प्राधान्य नसेल तर प्रमाणित आउटपुट आणि त्रुटी जर्नलमध्ये जातात, आणि विक्रेत्याचा रॅपर त्या पूर्णपणे वेगळ्या ठिकाणी पकडू शकतो।

म्हणूनच तेच प्रोफाइल शेलमधून आणि युनिटमधून वेगळे वागते। युनिटचे वातावरण, त्याची कार्यरत डिरेक्टरी आणि प्रमाणित प्रवाह तुमच्या इंटरॅक्टिव्ह शेलपेक्षा वेगळे असतात। सापेक्ष मार्ग एका संदर्भात सोडवला जाऊ शकतो आणि दुसऱ्यात कुठेही पोहोचू शकत नाही। दोन्ही जुळत नसतील तेव्हा प्रोफाइल नाही, युनिटची व्याख्या वाचा।

यापैकी एक बिघडला आहे असा निष्कर्ष काढण्याऐवजी दोन्ही सुरू करण्याच्या पद्धतींची तुलना करा। युनिटची कमांड लाइन आणि त्याचे वातावरण वाचा, नंतर त्याच वेळेच्या कालखंडाचे जर्नल वाचा। रॅपर आउटपुट स्वतःच्या फाइलमध्ये वळवत असेल, तर ती फाइल आता तुमचा लॉग आहे, आणि संदेश कुठे गेले यासाठी OpenVPN निर्देश अप्रासंगिक आहेत।

ते वाचता येईल तेव्हाच तपशील पातळी वाढवा

गंतव्य शोधण्यापूर्वी तपशील पातळी वाढवल्यास तुम्ही न पाहत असलेल्या ठिकाणी फक्त अधिक मजकूर तयार होतो।

आउटपुट कुठे जाते हे कळल्यावर, मध्यम पातळी प्रोफाइल कसे पार्स होते आणि कनेक्शनचा प्रयत्न कसा होतो हे दाखवते। सुरुवातीच्या समस्येसाठी दोन किंवा तीन पुरेसे आहेत। अपयश वाटाघाटीचा तपशील असतो तेव्हा उच्च पातळ्या योग्य ठरतात, आणि त्या फाइल पटकन मोठी करतात।

मग खरी त्रुटी वाचा। टनेल उभे राहिले का याबद्दल शांत टर्मिनल काहीही सिद्ध करत नाही, आणि फाइलमध्ये नोंदलेले अपयश हेच दुरुस्त करण्यासारखे आहे।