L2TP डिबग लग खाली छ? त्रुटि सम्भवतः जर्नलमा छ

तपाईं डिबगिङसँग L2TP हेल्पर सुरु गर्नुहुन्छ, टर्मिनल हेर्नुहुन्छ, र स्क्रिनमा केही उपयोगी नदेखी त्यो रोकिन्छ। यो बिग्रिएको डिबग फ्ल्याग होइन। NetworkManager L2TP जडान चार सहयोगी प्रक्रिया हुन्, र तिनमा केही मात्र तपाईंले हेरिरहनुभएको टर्मिनलमा लेख्छन्। बाँकी प्रमाण जर्नलमा छ, एउटा फिल्टरको दूरीमा।

चार प्रक्रिया, लगका दुई गन्तव्य

जडान IPsec बाट सुरु हुन्छ, जो स्थापनाअनुसार libreswan वा strongSwan हुन्छ। त्यसपछि L2TP डेमन, परम्परागत रूपमा xl2tpd र केही बिल्डमा kl2tpd, टनेल चलाउँछ। अन्तमा pppd त्यसभित्र प्रमाणीकरण र ठेगाना व्यवस्थापन गर्छ।

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

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

एउटा प्रयास संकलन गर्नुहोस्, त्यसपछि क्रम पढ्नुहोस्

ज्ञात प्रोफाइल र ज्ञात समयसँग एक पटक पुनरुत्पादन गर्नुहोस्, त्यसपछि पूरै बुटको सट्टा साँघुरो विन्डो पढ्नुहोस्। सेटिङ परिवर्तन गर्दा प्रयासहरू दोहोर्याउँदा लग व्याख्या गर्न नसकिने मिश्रण बन्छ।

यी आदेशहरूले वर्तमान बुटका सहभागी प्रक्रिया छान्छन्, र तपाईंको वितरणमा प्लगइनको बाटो जाँच्नु उपयुक्त हुन्छ:

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

एउटै कलमा दोहोरिएका फिल्डले ती प्रक्रियाहरूको संघ छान्छन्, जसले क्रमलाई समयको क्रममा राख्छ। Debian-आधारित प्रणालीमा समतुल्य क्वेरी dpkg -L हो; मुख्य कुरा हातले चलाउनु अघि हेल्पर वास्तवमा कहाँ बस्छ भनेर पत्ता लगाउनु हो।

अर्को कदम तीन सर्तले निर्धारण गर्छन्

पहिलो असफल चरण पढ्नुहोस्, त्यसपछि सोही अनुसार छान्नुहोस्। यदि IPsec ले प्रस्ताव वा सहकर्मी प्रमाणीकरणको असफलता रिपोर्ट गर्छ भने, टनेल कहिल्यै बनेन, र PPP पासवर्ड परिवर्तन गर्दा मद्दत गर्न सक्दैन।

यदि टनेल बन्यो र pppd ले लगइन अस्वीकार गर्यो भने, साझा रहस्य पहिले नै ठीक थियो र प्रमाणपत्र समस्या एक तह माथि छ। यदि pppd ले ठेगानामा वार्ता गर्यो र असफलता पछि देखियो भने, दुवै काम गरिरहेका छन् र बाँकी समस्या राउटिङ, DNS वा सर्भरको आफ्नै नीति हो।

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

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

डिबग मोडले फाइलहरू छोड्छ

मूल डिबग वर्कफ्लोले सेवालाई डिबग फ्ल्यागसहित हातले चलाउँछ, र त्यो मोडले जडान सकिँदा सिर्जना गरिएका रनटाइम कन्फिगरेसन फाइलहरू त्यहीँ छोड्न सक्छ।

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

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

त्यसपछि सामान्य हेल्पर पुनर्स्थापित गर्नुहोस्

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

त्यसपछि नतिजा असफल भएको तहमा जाँच्नुहोस्, डेस्कटप आइकनमा होइन:

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

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