OpenVPN 3 Linux: फर्कनु अघि D-Bus त्रुटि पढ्नुहोस्
पाँच सेवा, एउटा फ्रन्टएन्ड। D-Bus त्रुटिलाई अस्वीकार गर्ने घटकसँग जोड्नुहोस्, सत्र छ कि छैन जाँच्नुहोस्, अनि त्यही सीमामा सुधार गर्नुहोस्।
OpenVPN 3 Linux का असफलताहरू अपरिचित नामसहित D-Bus विधि त्रुटिका रूपमा आउँछन्, र प्रलोभन यो हुन्छ कि प्याकेजको संस्करण तल झार्ने र आशा गर्ने। ग्राहक एउटा कार्यक्रम होइन: कमाण्ड-लाइन फ्रन्टएन्डले बस मार्फत ती सेवाहरूसँग कुरा गर्छ जसले प्रोफाइल, सत्र, VPN इन्जिन र विशेषाधिकार प्राप्त नेटवर्क परिवर्तनहरूको स्वामित्व लिन्छन्। यी पाँचमध्ये कुन असफल कलको स्वामित्वमा छ भनी ठम्याउनु निदानको सबैभन्दा ठूलो भाग हो र फर्कनुको सट्टा एउटा आदेशको लागत हो। अगाडि त्यही निर्णय छ, जुन क्रममा असफलताहरू सामान्यतया देखा पर्छन्।
एउटा आदेशको पछाडि पाँच मालिक
पाँच प्रक्रिया महत्त्वपूर्ण छन्, र प्रत्येकको आफ्नै बस नाम छ: तपाईंको आदेश स्वीकार गर्ने फ्रन्टएन्ड, प्रोफाइल र तिनका पहुँच नीति राख्ने कन्फिगरेसन प्रबन्धक, सत्रको आयु धारण गर्ने सत्र प्रबन्धक, OpenVPN 3 Core Engine मार्फत जडान चलाउने ब्याकएन्ड, र इन्टरफेस, मार्ग र DNS सेटिङ स्थापना गर्ने नेटवर्क कन्फिगरेसन सेवा। त्यसैले कन्फिगरेसन वस्तुको नाम लिने त्रुटि ब्याकएन्डको त्रुटि होइन, र सुरु नहुने ब्याकएन्ड प्रमाणीकरणको असफलता होइन। सन्देशलाई ती पंक्तिमध्ये एउटामा राख्नु कुनै पनि परिवर्तन अघि हुनुपर्छ, किनकि हरेक अर्को कदम कुन पंक्ति सत्य हो भन्नेमा निर्भर छ। पंक्तिको अनुमान लगाउनु त्यो बाटो हो जसमा सानो सुधार प्याकेजसँग दिनभरिको काम बन्छ।
अरू केही सोध्नु अघि प्रणाली बसलाई कुन सेवा उपस्थित छन् भनी सोध्नुहोस्, अनि स्थापित भागहरू एउटै संस्करणमा सहमत छन् भनी पुष्टि गर्नुहोस्। OpenVPN 3 Linux ती सेवाहरूलाई प्रणाली इकाइका रूपमा दर्ता गर्छ, त्यसैले सोध्नुपर्ने बस प्रणाली बस हो, संस्करणको प्रश्नका लागि प्रशासनिक अधिकार चाहिन्छ, र --user सँग बनाइएको सूचीले तपाईंको लगइन सत्र पढ्छ, जहाँ इकाइहरू कहिल्यै देखिँदैनन्। सेवाहरू मागअनुसार सक्रिय हुन्छन् र केही खाली हुँदा बन्द हुन्छन्, त्यसैले तपाईंको पहिलो अनुरोध अघि हराइरहेको सेवालाई अझै कुनै कुराको बारेमा सोधिएको छैन। तलका तीन आदेशले VPN सत्र नखोली उपस्थिति, संस्करण र इकाइको अवस्था बताउँछन्।
sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'प्रत्येक सूचीले वास्तवमा के प्रमाणित गर्छ
ग्राहकका आफ्नै दृश्यहरू उपलब्ध सबैभन्दा सस्तो प्रमाण हुन्, र तीमध्ये प्रत्येकले देखिनेभन्दा कम प्रमाणित गर्छ। कन्फिगरेसन सूचीमा प्रोफाइलले प्रोफाइल आयात भएको देखाउँछ र कसैले त्यससँग जोडिन सक्छ कि भन्नेबारे केही भन्दैन। सत्र सूचीमा सत्रले सत्र वस्तु अवस्थित रहेको देखाउँछ र टाढाको प्रमाणीकरण पूरा भयो कि भन्नेबारे केही भन्दैन।
openvpn3 configs-list
openvpn3 sessions-listती आउटपुटमा वस्तु मार्गहरूले बसमा व्यवस्थित वस्तुहरू जनाउँछन्, फाइलहरू होइन, त्यसैले तिनलाई सम्पादन गर्न सकिँदैन, र पहिले अभिलेख गरिएको मार्ग त्यो सत्र विच्छेद हुने क्षणमै पुरानो हुन्छ। तपाईंका टिप्पणीमध्येको एउटा पुनः प्रयोग गर्दा "no such object" त्रुटि उत्पन्न हुन्छन् जसको VPN सँग कुनै सम्बन्ध छैन। तलको चरण तालिकाले जडानको प्रत्येक कदमले के स्थापित गर्छ र के खुला छोड्छ भन्ने छुट्याउँछ, र फर्कने निर्णय ठ्याक्कै यही भिन्नतामा टिकेको छ। तपाईंको प्रमाणसँग मिल्ने पंक्ति पढ्नुहोस्, अनि त्रुटिको पाठ फेरि पढ्नुहोस्।
| Stage | What exists | What proves it | What it does not prove |
|---|---|---|---|
| Profile imported | A configuration object held by the configuration manager | The profile is listed by the client | That the profile owner permits a connection |
| Session requested | A session object held by the session manager | The session appears in the session list | That the remote side accepted the credentials |
| Connect dispatched | An asynchronous attempt on the VPN backend | Status changes arrive for that session | That an interface was configured |
| Tunnel configured | An interface, routes and DNS settings | The network service reports success and routes appear | That traffic reaches the peer |
जडान कल सुरुङ अवस्थित हुनुअघि फर्कन्छ
जडान कलले तपाईंलाई निगरानीका लागि सत्र दिन्छ र फर्कन्छ, त्यसैले स्पष्ट रूपमा सफल कलपछि मौनता सामान्य मध्यवर्ती अवस्था हो, विरोधाभास होइन। फ्रन्टएन्डले अझै पनि अवस्थाका परिवर्तनहरू पछ्याउनुपर्छ र हरेक अन्तरक्रिया अनुरोधको जवाफ दिनुपर्छ। जसलाई प्रमाणपत्र चाहिन्छ र जवाफ पाउँदैन, त्यस्तो प्रोफाइल अड्किएको ब्याकएन्डजस्तै देखिने अवस्थामा पर्खन्छ। त्यो प्रतीक्षा अवस्था चिनिनु आवश्यक छ, किनकि यसले मानिसहरूलाई गलत घटकतिर पठाउँछ।
प्रयास चलिरहेको बेला त्यो प्रोफाइलका लागि सत्र सूची र फ्रन्टएन्डको आफ्नै लग हेर्नुहोस्। जुन सत्रले आफ्नो सुरुवाती अवस्था कहिल्यै छोड्दैन त्यसले रोकिएको घटकको नाम लिन्छ, र लगले सामान्यतया पहिलो पंक्तिहरूमै त्यसको नाम लिन्छ। प्रोफाइलको नाम नजिकै राख्नुहोस्, किनकि लग आदेशले सत्र मार्ग होइन प्रोफाइल लिन्छ, जुन मार्ग पुनः प्रयोग गर्नुको सट्टा सूची फेरि पढ्ने अर्को कारण हो।
openvpn3 sessions-list
openvpn3 log --config <profile> --level 6सत्र नखोली एउटा घटकको लग पढ्ने
जब फ्रन्टएन्डले केही उपयोगी बताउँदैन, तब नयाँ जडान सुरु गर्नुको सट्टा जसले असफलता लग गर्यो त्यो घटककहाँ जानुहोस्। कन्फिगर गरिएको systemd-journald लगरसँग, प्रशासकको सीमित जर्नल दृश्यले एउटा घटकका घटनाहरू पढ्छ, बस नीतिलाई छुँदैन र सत्र खोल्दैन, र यो महत्त्वपूर्ण छ किनकि जुन निदानले मापन गरिँदै गरेको प्रणालीलाई नै बदल्छ त्यसले धेरै कम प्रमाणित गर्छ। इकाइअनुसार छान्नुहोस्, syslog ट्यागअनुसार होइन: अलग-अलग सेवा इकाइहरूले साझा पहिचानको ग्यारेन्टी दिँदैनन्, त्यसैले ट्यागको प्रश्नले खाली पृष्ठ फर्काउन सक्छ जबकि इकाइ आफैंले असफलता अभिलेख गरेको हुन्छ।
कसैसँग मद्दत माग्नु अघि चार क्षेत्र लेख्नुहोस्: त्रुटिको पूरा नाम, सम्बन्धित सेवा र वस्तु, समयको छाप, र स्थापित प्याकेजका संस्करण। यी नै हुन् जो मर्मत गर्नेलाई चाहिन्छ, र यीमध्ये कुनैका लागि प्रोफाइल वा प्रमाणपत्र टिकटमा टाँस्नु आवश्यक छैन। त्रुटि शान्त गर्न बस पहुँच नीति फराकिलो बनाउनु निदान होइन, यसले त्यो सीमा मेटाउँछ जसले तपाईंको तर्फबाट घटकको नाम लिइरहेको थियो। प्रोफाइलको निजी सामग्री साझा प्रतिवेदनबाहिर रहन्छ, जुन कारणले प्रमाणपत्रबाहिर रहन्छ त्यही कारणले।
journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>अस्वीकार गर्ने सीमाको सुधार
नक्साको प्रत्येक पंक्तिको आफ्नै सुधार छ, र पंक्तिहरूले एकअर्काको ठाउँ लिँदैनन्। प्रोफाइलमा अस्वीकृत कार्य नीति र स्वामित्वको प्रश्न हो, जबकि सक्रिय नहुने ब्याकएन्ड सेवा र प्याकेजिङको प्रश्न हो। प्रमाणीकरण अस्वीकार गर्ने सर्भर यीमध्ये कुनै होइन, त्यसैले बारम्बार पासवर्ड बदल्नाले स्थानीय सक्रियताको समस्या सुधार्न सक्दैन। गलत सुधार छान्नु त्यो बाटो हो जसमा नीतिको समस्या पुनःस्थापना बन्छ।
प्याकेज परिवर्तनपछि पुरानो बाइनरीलाई त्यसको ठाउँमा प्रतिलिपि गर्नुको सट्टा सुसंगत र समर्थित स्थापना प्रमाणित गर्नुहोस्। नियन्त्रित फिर्ती पुष्टि भएको रिग्रेसनको वैध जवाफ हो, बशर्ते प्याकेजहरू अनुकूल रहून् र समर्थित मर्मततर्फ फर्कने बाटो अस्तित्वमा होस्। त्यो बाटो सेवाले सुरु हुन छोड्नु अघि स्थापित गर्नुहोस्, पछि होइन।
अर्को प्लेटफर्मले त्यही मूल VPN पुस्तकालय साझा गर्न सक्छ Linux का बस सेवा नसाझा गरी, त्यसैले Windows मा देखिने समान असफलताले यसबारे केही भन्दैन। D-Bus को अवलोकन ले कन्फिगरेसन र सत्रका लागि खोलिएका वस्तु मार्गहरूको लेखाजोखा गर्छ, र यो निदान जुन संरचनामा टिकेको छ त्यही भाग हो। एकपटक पढ्नुहोस्, र अर्को त्रुटि पहिल्यै त्यसमा जोडिएको घटकसहित आउनेछ।