तपाईंको सेवा OpenVPN कहिल्यै चल्नुअघि नै असफल हुन्छ, र त्रुटिले तपाईंले कहिल्यै कन्फिगर नगरेको माउन्ट युनिटको कुरा गर्छ। यही संकेत हो: systemd सम्पूर्ण कारोबार अस्वीकार गर्दै छ किनभने रुट माउन्ट युनिट मास्क छ, र तपाईंको VPN प्रोफाइल अझै पढिएको छैन। सामान्य कारण रनटाइम युनिट डाइरेक्टरीमा बाँकी रहेको फाइल हो, बिग्रिएको fstab होइन र हराएको प्रमाणपत्र होइन। पहिले फाइल पछ्याउनुहोस्, किनभने यसलाई बाहिर राख्नु सबैभन्दा सस्तो व्याख्या हो।

त्रुटिले रुट माउन्टको नाम लिन्छ, तपाईंको प्रोफाइलको होइन

systemd आफैं कर्नेलको माउन्ट जानकारीबाट रुट माउन्ट युनिट बनाउँछ र युनिटलाई -.mount भन्छ किनभने ड्यासले रुट बाटो जनाउँछ। यो युनिट सामान्यतया मेमोरीमा मात्र हुन्छ र यसको पछाडि फाइल हुँदैन। त्रुटिले यो मास्क छ भन्छ भने कसैले युनिट फाइल त्यहाँ राखेको छ जहाँबाट systemd यसलाई लोड गर्छ र त्यो फाइल /dev/null तर्फ देखाएको छ। मास्क हुनु वास्तविक अवस्था हो, सन्देशमा टाइपिङ गल्ती होइन।

इन्स्ट्यान्स युनिट असफल हुन्छ किनभने यसको जब ग्राफ क्रम र आफ्नै माउन्ट आवश्यकताबाट रुट माउन्टसम्म पुग्छ। OpenVPN बाइनरी चल्नुअघि नै कारोबार अस्वीकार गरिन्छ, त्यसैले क्लाइन्टको कन्फिगरेसनमा केही पनि कारण हुन सक्दैन। त्यसैले प्रोफाइल, प्रमाणपत्र वा प्रमाणहरू बदल्नुको यो विशेष असफलतामा कुनै असर हुँदैन।

OpenVPN डिबग गर्नुअघि रनटाइम डाइरेक्टरी हेर्नुहोस्

रनटाइम युनिट डाइरेक्टरीमा ठ्याक्कै त्यही नामको फाइल खोज्नुहोस्, त्यसपछि systemd लाई युनिट के हो भनेर सोध्नुहोस्। दुवै जवाफ छिटो छन्, र सँगै बाँकी रहेको फाइललाई वास्तविक माउन्ट समस्याबाट अलग गर्छन्।

ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount

सामान्य मेसिनमा यस्तो फाइल हुँदैन, र मास्क गरिएको सूचीमा रुट माउन्ट हुँदैन। यदि पहिलो कमान्डले /dev/null को सिम्बोलिक लिङ्क छाप्छ भने निदान निश्चित छ। त्यही डाइरेक्टरीमा उही औजारले बनाएको tmp.mount मास्क पनि हुन सक्छ, र त्यसले अर्को नाममा उही प्रकारको असफलता निम्त्याउँछ। पूरै डाइरेक्टरी हेर्नुहोस्, त्रुटिमा लेखिएको नाम मात्र होइन।

ls -la /run/systemd/system/*.mount

यदि डाइरेक्टरी सफा छ र युनिट अझै मास्क छ भने, मास्क खोजमार्गमा अन्त कतै छ, र systemctl cat -.mount ले कुन फाइल लोड हुँदै छ देखाउनेछ।

फाइल मेटाउनुहोस्, फेरि लोड गर्नुहोस् र फेरि सुरु गर्नुहोस्

रनटाइम फाइल हटाउनु र म्यानेजर फेरि लोड गर्नु पर्याप्त छ, र यसले प्याकेजबाट आएको कुनै पनि कुरालाई छुँदैन। सुरु गर्नुअघि फेरि लोड गर्नुहोस्, किनभने systemd ले डाइरेक्टरी फेरि नपढेसम्म लोड गरिएको युनिटको स्थिति राख्छ।

sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]

त्यसपछि सुधारले काम गर्यो भन्ने मान्नुको साटो सेवाकै जर्नल पढ्नुहोस्। सफा सुरुवातले systemd ले युनिट स्वीकार गर्यो भन्ने मात्र प्रमाणित गर्छ; क्लाइन्ट अझै हराएको प्रोफाइल, अगम्य साथी वा प्रमाणित नहुने प्रमाणपत्रका कारण मर्न सक्छ। यी OpenVPN का सामान्य समस्या थिए जो मास्क युनिटपछाडि लुकेका थिए। जर्नलले कुन प्रोफाइल लोड भयो र सुरुङ साँच्चै बन्यो कि भन्ने लेख्छ। यदि युनिट सुरु भयो र सुरुङ भएन भने तपाईं अर्को समस्यामा पुग्नुभयो, र यो प्रगति हो।

journalctl -u [email protected] -b --no-pager

किनभने /run अस्थायी फाइल सिस्टम हो, रिबुटले फाइल पनि मेटाउँछ। यसले रिबुटलाई उपयोगी परीक्षण बनाउँछ: यदि सेवा रिबुटपछि चल्यो र अर्को तैनातीपछि फेरि असफल भयो भने, फाइल इमेजमा पकाइँदै छ।

यसलाई इमेजबाट फर्केर आउनबाट रोक्नुहोस्

कन्टेनर वा भर्चुअल मेसिनको टेम्प्लेट जसले निर्माणका क्रममा माउन्ट युनिट मास्क गर्छ, त्यसले त्यो मास्क हरेक क्लोनमा लैजान्छ। अर्को जसलाई फाइल सिस्टम चाहिन्छ त्यो बिग्रन्छ, र सन्देशले आएको इमेजको साटो माउन्टलाई दोष दिन्छ। एउटा चलिरहेको इन्स्ट्यान्सभित्र सुधार गर्नुले अर्को इन्स्ट्यान्स बन्नेसम्म समस्या लुकाउँछ।

निर्माण सन्दर्भमा फाइलको नाम र त्यो बनाउने कमान्ड खोज्नुहोस्, त्यसपछि टेम्प्लेटबाट मास्क हटाएर फेरि निर्माण गर्नुहोस्। यदि मास्क निर्माणका क्रममा साँच्चै आवश्यक छ भने, निर्माण सक्ने त्यही तहमा हटाउनुहोस्, ताकि पठाइने इमेज सफा सुरु होस्। नयाँ क्लोनमा जाँच्नुहोस्, हातले मर्मत गरेको मेसिनमा होइन। इमेज बदलियो भन्ने प्रमाणित गर्ने यही एउटै परीक्षण हो।

सम्झनुपर्ने लक्षण भनेको त्रुटि र तपाईं कन्फिगर गर्दै गरेको कुराबीचको अमिल्दो हो। जब systemd माउन्टको गुनासो गर्छ र तपाईं VPN क्लाइन्ट सुरु गर्दै हुनुहुन्छ, पहिले सन्देशमा युनिटको नाम पढ्नुहोस् र त्यसपछि सेवाको नाम।

सम्बन्धित लेखहरू