OpenVPN शुरू नहीं हो रहा: पहली पंक्ति पढ़ें, कॉन्फ़िग नहीं

पहले सेकंड में मरने वाला 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 काम नहीं कर रहा» कहने पर होता है।

जो शाखा आपने ली उसे नोट करें: पोर्ट टकराव, गुम बाइनरी, गुम कॉन्फ़िग। अगली बार पहचानना तेज़ होगा।