तुम्ही डीबगिंगसह 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

प्रमाणीकरण करणारे, पत्ता मिळवणारे आणि इच्छित गंतव्याकडे राउट करणारे सत्र हेच तुम्ही डीबग करत असलेला निकाल आहे। अपयशी प्रयत्नादरम्यान शांत टर्मिनल तुम्हाला फक्त एवढेच सांगते आउटपुट कुठे लिहिले गेले नाही।

संबंधित लेख