OpenVPN सुरु भयो तर केही छापिएन: पहिले log-append जाँच्नुहोस्

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

मौनताका दुई धेरै फरक व्याख्या छन्

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

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

निर्देश खोज्नुहोस्, त्यसपछि प्रक्रिया खोज्नुहोस्।

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

चलिरहेको प्रक्रियाले प्रयोग गर्ने गन्तव्य खोज्नुहोस्

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

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

फाइलको परिवर्तन समयलाई तपाईंले सुरु गरेको क्षणसँग तुलना गर्नुहोस्। गएको हप्ताको लग गएको हप्ताको प्रमाण हो। त्यसपछि परिवर्तन भएको फाइलका अन्तिम पङ्क्तिहरू पढ्नुहोस्, र त्यहाँ भएको कुरालाई तपाईंले छुटाएको सुरुवात सन्देश मान्नुहोस्।

log र log-append: प्रमाण र मेटाइ

log-append पहिले नै फाइलमा भएको कुरामा थप्छ। log फाइल लेख्नका लागि खोल्छ र त्यसलाई काट्छ, त्यसैले दुईबीच फेर्दा तपाईं पढ्न लागेको रन मेटिन सक्छ।

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

कुनै पनि विकल्पले छुटेका प्यारेन्ट डाइरेक्टरीहरू सिर्जना गर्दैन, र कुनैले पनि फाइलसिस्टम अनुमति वा सेवा स्यान्डबक्समार्फत पहुँच दिँदैन। कन्फिगरेसनमा सही देखिने मार्ग डेमन चल्ने खाताले लेख्न नसक्ने हुन सक्छ, र त्यस अवस्थामा डेमनले केही रिपोर्ट गर्नुअघि नै असफल हुन सक्छ। फाइलनाम नै समस्या हो भन्ने मान्नुअघि डाइरेक्टरी अवस्थित छ कि र यसको मालिक को हो जाँच्नुहोस्।

सेवा र्यापरले आउटपुट समात्दा

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

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

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

पढ्न सक्ने भएपछि मात्र विस्तृतता बढाउनुहोस्

गन्तव्य खोज्नुअघि विस्तृतता बढाउँदा तपाईंले नहेरेको ठाउँमा थप पाठ मात्र उत्पन्न हुन्छ।

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

त्यसपछि वास्तविक त्रुटि पढ्नुहोस्। टनेल उठ्यो कि उठेन भन्नेमा मौन टर्मिनलले केही प्रमाणित गर्दैन, र फाइलमा अभिलेख भएको असफलता नै सुधार्न लायक हो।