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, कुन बाइनरी र प्रोफाइल साँच्चै चले, र असफलता स्थानीय हो वा टाढाको। प्रत्येक उत्तरले एउटा तह हटाउँछ। प्रोफाइलबाट सुरु गर्नु भनेको कहिल्यै नखोलिएको हुन सक्ने फाइल फेरि लेख्नु।