OpenVPN सुरू होत नाही: कॉन्फिग नाही, पहिली ओळ वाचा

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

तीन फक्त-वाचन आदेश तुम्हाला तिथे नेतात: आधी journalctl -u openvpn@server -b --no-pager, नंतर systemctl status openvpn@server, आणि UDP श्रोते व त्यांचे मालक यांच्यासाठी ss -lunp।

पहिली ओळच शाखा निवडते

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

मूळ ओळ लपवणाऱ्या पुनःप्रयत्न लूपकडे लक्ष द्या। रीस्टार्ट धोरण असलेले युनिट पहिली अयशस्वीता डझनभर समान अयशस्वीतांच्या खाली पुरू शकते, म्हणून युनिटनुसार फिल्टर करून वरून वाचलेले journalctl -b शेपटीपेक्षा बरे।

अजून कोण 1194 पोर्ट धरून आहे

दोषी सहसा कोणी जाणूनबुजून सेट केलेला दुसरा सर्व्हर नसतो। दुसऱ्या टर्मिनलमध्ये अजून जिवंत असलेला हाताने सुरू केलेला क्लायंट, तोच पोर्ट निवडलेला दुसरा प्रोफाइल, किंवा ज्याचा स्वतःचा टनेल 1194 धरून आहे असे विक्रेता बंडल अपेक्षित धरा। सॉकेटचा मालक ss -lunp मध्ये दिसतो; युनिट जबाबदार आहे का हे जाणून घेण्यासाठी तो PID systemctl status ला द्या। सिग्नलने नाही, त्याच्या स्वतःच्या नियंत्रण मार्गाने तो खाली उतरवा।

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

काढल्यानंतर शिल्लक राहिलेली युनिट्स

काढणे बाइनरी हटवते; हाताने लिहिलेल्या युनिट फाइल्स, सहसा /etc/systemd/system खाली, त्यातून वाचतात। मग Systemd आता नसलेल्या मार्गाकडे निर्देश करणारे युनिट पुन्हा प्रयत्न करते, आणि संदेश कालच्या काढण्याबद्दल नाही तर त्या गहाळ फाइलबद्दल असतो। systemctl status युनिटचा फ्रॅगमेंट मार्ग वरच्या बाजूला दाखवते, म्हणून काहीही हटवण्यापूर्वी तो dpkg -S ने तपासा। अनाथ गेल्यावर systemctl daemon-reload आणि systemctl reset-failed स्थिती स्वच्छ करतात; नाहीतर पुढील प्रत्येक स्थिती-तपासणी ती वारसाहक्काने घेते।

जेव्हा which openvpn /usr/local खालील काहीतरी उत्तर देते, तेव्हा वापरात असलेली बाइनरी apt मधून नाही तर विक्रेता इंस्टॉलरमधून आलेली असते। असा इंस्टॉलर सहसा स्वतःचा श्रोता, स्वतःची बूट नोंद आणि स्वतःची कॉन्फिग डिरेक्टरी आणतो, म्हणून दिसणारा आदेश हटवल्यास सॉकेट व्यस्तच राहते।

विक्रेता जसे दस्तऐवज करतो त्याप्रमाणे ते अनइंस्टॉल करा, ss -lunp ने पोर्ट मोकळा असल्याची खात्री करा, आणि गरज असेल तरच वितरणाचा क्लायंट जोडा।

पुन्हा प्रयत्न करण्यापूर्वी स्थिती नीट करा

त्यातून निष्कर्ष काढण्यापूर्वी अयशस्वी स्थिती स्वच्छ करा: systemctl reset-failed काउंटर काढून टाकते, आणि मग systemctl status युनिटचा इतिहास नाही तर सध्याची स्थिती कळवते। ते एकदा सुरू करा आणि यंत्राची एकूण स्थिती नाही तर त्या फेरीचे स्वतःचे जर्नल वाचा। टनेल काहीही वाहून नेत नसताना सक्रिय असल्याचे कळवणारे युनिट वेगळी समस्या आहे, आणि अधिक सामान्य। दोन्ही बग अहवालांमध्ये एकत्र मिसळतात कारण दोन्ही वापरकर्त्याने «VPN चालत नाही» असे म्हणण्यावर संपतात।

तुम्ही घेतलेली शाखा नोंदवा: पोर्ट संघर्ष, गहाळ बाइनरी, गहाळ कॉन्फिग। पुढील वेळी ओळखणे जलद होईल।