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 चल्दैन» भन्नेमा टुंगिन्छन्।

तपाईंले लिनुभएको शाखा नोट गर्नुहोस्: पोर्ट द्वन्द्व, हराएको बाइनरी, हराएको कन्फिग। अर्को पटक चिन्न छिटो हुनेछ।