VPN लॉगसाठी journalctl: कोणती युनिट कनेक्शनची मालक आहे?

तुम्हाला आठवणारा लॉग कमांड नाही, तर VPN कनेक्शनची प्रत्यक्ष मालकी असलेल्या systemd युनिटपासून सुरुवात करा। थेट OpenVPN सेवा, wg-quick युनिट आणि NetworkManager प्रोफाइल त्यांचे उपयुक्त संदेश वेगवेगळ्या युनिटमध्ये ठेवतात, आणि चुकीच्या युनिटवरील क्वेरी शांततेसारखा वाटणारा रिकामा निकाल देते। तीन सामान्य मालकांची तुलना करा, खिडकी आकुंचित करा, नंतर टप्पे क्रमाने वाचा।

तीन सामान्य मालकांची तुलना करा

OpenVPN क्लायंट सेवा सामान्यतः प्रोफाइलच्या नावाने असलेली इन्स्टन्स युनिट असते, जसे [email protected]। तिच्या संदेशांमध्ये कॉन्फिगरेशन पथ, पर्यायांचे विश्लेषण, TLS हस्तांदोलन आणि क्लायंट करत असलेली मार्ग स्थापना समाविष्ट असते।

wg-quick युनिट रचनेनेच अधिक शांत असते। इंटरफेस कॉन्फिगरेशन सुरुवातीला होते, हस्तांदोलन कर्नेल हाताळते, आणि नियमित की नूतनीकरण डीफॉल्टनुसार लॉग होत नाही, म्हणून wg show जर्नलपेक्षा अधिक माहितीपूर्ण असतो। बोलणी लॉग करणाऱ्या प्रोटोकॉलची तुलना तसे न करणाऱ्या प्रोटोकॉलशी करता तेव्हा हा फरक महत्त्वाचा असतो।

NetworkManager स्वतः तयार केलेल्या प्रोफाइलचा मालक आहे, आणि मूळ प्लगइन VPN सहाय्यक असले तरी त्याचे संदेश NetworkManager.service अंतर्गत राहतात। प्रोफाइल अशा पद्धतीने व्यवस्थापित असल्यास व्यवस्थापक आणि सहाय्यक युनिट दोघांनाही विचारा।

क्वेरी एका युनिट आणि एका खिडकीपर्यंत आकुंचित करा

तुम्ही ओळखलेल्या युनिटला विचारा, आणि तुम्ही तपासत असलेल्या प्रयत्नापर्यंत वेळ मर्यादित करा। एक दिवस सामान्यतः पुरतो, आणि मशीन वारंवार पुन्हा जोडली जाते तेव्हा लहान खिडकी बरी असते।

journalctl -u [email protected] --since today
systemctl list-units --type=service | grep -i vpn
systemctl cat [email protected]

क्वेरीवर विश्वास ठेवण्यापूर्वी स्थापित नाव पडताळा। वितरण पॅकेजिंग युनिटची नावे बदलते, आणि फाइल म्हणून असलेले प्रोफाइल कधीही सेवा म्हणून सक्षम झाले नसू शकते। युनिट नसल्यास, रिकामे जर्नल तुम्हाला बोगद्याबद्दल नाही, तैनातीबद्दल सांगते।

पहिला अयशस्वी टप्पा वाचा

घटना ज्या क्रमाने घडतात त्या क्रमाने वाचा: एंडपॉइंट शोध, वाहतूक, ओळख, प्रमाणीकरण, मार्ग स्थापना आणि नंतरचे अनुप्रयोगाचे अपयश। पहिले ठोस अपयश तपासण्यासारखे असते, कारण त्यानंतरचे सर्व परिणाम असते।

यशस्वीरित्या सुरू होणारी सेवा प्रत्येक आवश्यक संसाधन पोहोचण्यायोग्य आहे हे सिद्ध करत नाही। पुनर्जोडणीचे लूप अनेक स्वतंत्र बोलणी निर्माण करू शकते, म्हणून प्रोफाइलचे नाव आणि प्रयत्नाची वेळ घटनांसोबत ठेवा, आणि एकत्रित स्ट्रीमऐवजी एक प्रयत्न वाचा। एकच प्रयत्न कारणासह असलेला क्रम असतो, तर एकत्रित स्ट्रीम पुनरावृत्त ओळींची भिंत असते। पुढे वाचण्यापूर्वी पहिली त्रुटी तिकिटात लिहा।

अयशस्वी सेवेला हाताने चालवलेल्या क्लायंटसोबत मिसळू नका

सेवा अयशस्वी झाल्यानंतर तुम्ही क्लायंट हाताने सुरू केला असेल, तर त्याचे आउटपुट अन्यत्र जाते आणि त्याचे वर्तन वेगळे असू शकते। समर्थित दुरुस्तीनंतर त्याच मालकाकडून आणि त्याच विनंतीतून नवीन निकाल घ्या, जेणेकरून तुलना दोन वेगळे प्रोग्राम मिसळण्याऐवजी काय बदलले ते दाखवेल।

दुसऱ्या होस्टशी जुळवण्यासाठी मूळ टाइमस्टॅम्प बदलू नका। वेळ क्षेत्र आणि ज्ञात घड्याळातील फरक स्वतंत्रपणे नोंदवा, कारण तुम्ही संपादित केलेली कालरेषा आता पुरावा नाही।

निर्यात नाही, उतारा सामायिक करा

जर्नल नोंदींमध्ये वापरकर्तानावे, एंडपॉइंट पत्ते, खाजगी टोपोलॉजी आणि स्क्रिप्ट वातावरणाची माहिती असू शकते। पूर्ण अमर्यादित निर्यात प्रकाशित करण्याऐवजी प्रत्यक्ष उताऱ्याचे पुनरावलोकन करा आणि संवेदनशील भाग झाकून टाका। अपयश सिद्ध करणाऱ्या ओळी उद्धृत करा आणि उर्वरित सारांश द्या। थोडक्यात पुनरावलोकित उतारा कोणीही न वाचणाऱ्या फाइलपेक्षा वापरण्यास सोपा असतो।

अरुंद खिडकी, युनिटचे नाव आणि पहिला अयशस्वी टप्पा पाठवा, आणि तुम्ही आधीच काय वगळले ते सांगा। systemd journalctl पुस्तिका निवडक आणि आउटपुट पर्यायांचे दस्तऐवजीकरण करते, तुमच्या वितरणाची आवृत्ती समर्थित करणारे स्वरूप हवे असल्यास।