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 पुस्तिका ले छनोटकर्ता र आउटपुट विकल्पहरूको दस्तावेजीकरण गर्छ, यदि तपाईंलाई तपाईंको वितरणको संस्करणले समर्थन गर्ने ढाँचा चाहिन्छ।