openvpn --errors-to-stderr एउटा सुरुवात विकल्प हो, त्रुटि होइन

कमाण्ड लाइनमा --errors-to-stderr देखिँदा त्यो उजुरीजस्तो देखिन्छ, तर उजुरी होइन। शब्द विकल्पको नामको भाग हो, जसरी लग फाइलको नामले फाइलमा के छ भन्ने कुरा केही बताउँदैन। कुनै पनि कन्फिगरेसन बदल्नुअघि तपाईं वास्तवमा के पढ्दै हुनुहुन्छ निर्धारण गर्नुहोस्।

निर्णयका तीन शाखा छन्: लाइन आफै सुरुवात हो, लाइन प्रोग्रामले छापेको आउटपुट हो, वा लाइन VPN सुरु हुनुअघि लपेट्ने कार्यक्रमले दोहोर्याएको पाठ हो। प्रत्येक शाखाले हेर्ने फरक ठाउँ देखाउँछ, र तीमध्ये एउटा मात्र VPNको आफ्नै सन्देश हो।

विकल्पको नाम स्थिति सन्देश होइन

Community OpenVPN का लागि --errors-to-stderr त्रुटि आउटपुटलाई मानक आउटपुटको सट्टा मानक त्रुटिमा पठाउँछ। यो स्ट्रिमको छनोट हो, गम्भीरताको फिल्टर होइन, र यसले त्रुटि बनाउँदैन। पछिको --log वा --log-append ले तीही सन्देशहरू फाइलमा पठाउन सक्छ, त्यसैले फ्ल्यागको प्रभाव कमाण्डको बाँकी भागमा निर्भर हुन्छ। स्रोतको लगिङ सन्दर्भ ले त्यो क्रम निर्धारण गर्छ।

त्यसैले फ्ल्यागको उपस्थितिले त्रुटिहरू कहाँ जान्छन् भन्ने बताउँछ। कुनै त्रुटि भयो भन्ने भने बताउँदैन।

सुरुवात लाइन वा प्रक्रियाको आउटपुट

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

यदि लाइन लपेट्ने कार्यक्रमबाट आएको हो भने VPN अझै चलेको छैन र बताउन केही छैन। आउटपुटमा अझ तल हेर्दै समय छाप वा उपप्रणालीको नाम भएको पहिलो सन्देश खोज्नुहोस्।

यदि लाइन VPN प्रक्रियाबाट आएको हो भने पनि त्यो केवल आह्वान हो। OpenVPN ले आफ्नै कमाण्ड लाइन त्रुटिका रूपमा छाप्दैन, र महत्त्वपूर्ण सन्देशहरू त्यसपछि आउँछन्।

प्रक्रिया र त्यसको नतिजा खोज्नुहोस्

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

त्यसपछि प्रक्रियाको मालिक भएको घटकमार्फत नतिजा पढ्नुहोस्। systemd अन्तर्गत त्यो एकाइको जर्नल हो; डेस्कटप अनुप्रयोगमा त्यो अनुप्रयोगको आफ्नै लग वा कन्सोल हो। निकास स्थिति र अन्तिम सन्देशहरूले विकल्पको नामले मात्र संकेत गर्ने प्रश्नको उत्तर दिन्छन्।

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

फ्ल्याग कहिले आफ्नो स्थानको योग्य हुन्छ

stdout ले डाटा बोक्छ र त्रुटिले त्यसलाई दूषित गर्नु हुँदैन भन्ने बेला, वा लपेट्ने कार्यक्रमले दुई स्ट्रिम छुट्टाछुट्टै समात्ने बेला फ्ल्याग आफ्नो स्थानको योग्य हुन्छ। टर्मिनलमा अग्रभूमि सत्रमा दुवै स्ट्रिम तपाईंको अगाडि आउँछन्। त्यो अवस्थामा भिन्नताले तपाईंले गर्ने काम विरलै बदल्छ।

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

के बदल्नु हुँदैन

विकल्पलाई मर्मतको चरणका रूपमा नलिनुहोस्। यसलाई मेटाउँदा प्रमाणपत्र, मार्ग वा प्रमाणीकरण असफलता सुधारिँदैन।

यदि आह्वानमा --config stdin छ भने, कन्फिगरेसन मानक इनपुटमार्फत दिइन्छ। फाइल कसरी उपलब्ध गराइन्छ भन्नेबारे यो छुट्टै निर्णय हो। एक पटकमा एउटा कुरा बदल्नुहोस्, र दोस्रो बदल्नुअघि वास्तविक सन्देश फेरि पढ्नुहोस्।