VPN लॉग के लिए journalctl: कौन-सी यूनिट कनेक्शन की मालिक है?

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

तीनों सामान्य मालिकों की तुलना करें

OpenVPN क्लाइंट सेवा आम तौर पर प्रोफ़ाइल के नाम पर बनी इंस्टेंस यूनिट होती है, जैसे [email protected]। इसके संदेशों में कॉन्फ़िगरेशन पथ, विकल्पों का विश्लेषण, TLS हैंडशेक और क्लाइंट द्वारा किया गया रूट इंस्टॉलेशन शामिल होता है।

wg-quick यूनिट डिज़ाइन से ही अधिक शांत होती है। इंटरफ़ेस कॉन्फ़िगरेशन शुरू होने पर होता है, हैंडशेक कर्नेल संभालता है, और नियमित कुंजी नवीनीकरण डिफ़ॉल्ट रूप से लॉग नहीं होते, इसलिए wg show अक्सर जर्नल से अधिक जानकारीपूर्ण होता है। यह अंतर तब मायने रखता है जब आप बातचीत लॉग करने वाले प्रोटोकॉल की तुलना ऐसे प्रोटोकॉल से करते हैं जो ऐसा नहीं करता।

NetworkManager अपने बनाए प्रोफ़ाइल का मालिक है, और उसके संदेश NetworkManager.service के अंतर्गत रहते हैं, भले ही अंतर्निहित प्लगइन VPN सहायक हो। जब प्रोफ़ाइल इस तरह प्रबंधित हो तो मैनेजर और सहायक यूनिट दोनों से पूछें।

क्वेरी को एक यूनिट और एक खिड़की तक सीमित करें

उस यूनिट से पूछें जिसकी आपने पहचान की, और समय को उस प्रयास तक सीमित करें जिसकी आप जाँच कर रहे हैं। एक दिन आम तौर पर पर्याप्त होता है, और जब मशीन बार-बार फिर से जुड़ती है तो छोटी खिड़की बेहतर होती है।

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

क्वेरी पर भरोसा करने से पहले स्थापित नाम सत्यापित करें। डिस्ट्रीब्यूशन पैकेजिंग यूनिट के नाम बदलती है, और फ़ाइल के रूप में मौजूद प्रोफ़ाइल कभी सेवा के रूप में सक्षम नहीं किया गया हो सकता है। यदि यूनिट मौजूद नहीं है, तो खाली जर्नल आपको टनल के बारे में नहीं, परिनियोजन के बारे में बताता है।

पहला असफल चरण पढ़ें

घटनाओं को उस क्रम में पढ़ें जिसमें वे होती हैं: एंडपॉइंट की खोज, ट्रांसपोर्ट, पहचान, प्रमाणीकरण, रूट इंस्टॉलेशन और एप्लिकेशन की बाद की विफलता। पहली ठोस विफलता ही जाँचने योग्य है, क्योंकि उसके बाद सब कुछ परिणाम है।

सफलतापूर्वक शुरू होने वाली सेवा यह सिद्ध नहीं करती कि हर आवश्यक संसाधन पहुँच योग्य है। पुनः कनेक्शन का लूप कई अलग-अलग बातचीत पैदा कर सकता है, इसलिए प्रोफ़ाइल का नाम और प्रयास का समय घटनाओं के साथ रखें, और मिश्रित स्ट्रीम के बजाय एक प्रयास पढ़ें। एकल प्रयास कारण वाला क्रम है, जबकि मिश्रित स्ट्रीम दोहराई गई पंक्तियों की दीवार है। आगे पढ़ने से पहले पहली त्रुटि टिकट में लिखें।

असफल सेवा को हाथ से चलाए क्लाइंट के साथ न मिलाएँ

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

किसी अन्य होस्ट से मिलाने के लिए मूल टाइमस्टैम्प न बदलें। समय क्षेत्र और ज्ञात घड़ी का अंतर अलग से दर्ज करें, क्योंकि आपके द्वारा संपादित समयरेखा अब प्रमाण नहीं है।

निर्यात नहीं, अंश साझा करें

जर्नल प्रविष्टियों में उपयोगकर्ता नाम, एंडपॉइंट पते, निजी टोपोलॉजी और स्क्रिप्ट परिवेश की जानकारी हो सकती है। पूरा अप्रतिबंधित निर्यात प्रकाशित करने के बजाय वास्तविक अंश की समीक्षा करें और संवेदनशील भाग छिपाएँ। जो पंक्तियाँ विफलता सिद्ध करती हैं उन्हें उद्धृत करें और शेष का सारांश दें। संक्षिप्त समीक्षित अंश किसी ऐसी फ़ाइल से उपयोग करना आसान है जिसे कोई नहीं पढ़ता।

संकीर्ण खिड़की, यूनिट का नाम और पहला असफल चरण भेजें, और बताएँ कि आप पहले से क्या बाहर कर चुके हैं। systemd journalctl मैनुअल चयनकर्ताओं और आउटपुट विकल्पों का दस्तावेज़ीकरण करता है, यदि आपको वह प्रारूप चाहिए जिसे आपके डिस्ट्रीब्यूशन का संस्करण समर्थित करता है।