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 का अवलोकन उन ऑब्जेक्ट पथों का दस्तावेज़ीकरण करता है जो कॉन्फ़िगरेशन और सत्रों के लिए उजागर किए जाते हैं, और यही वह हिस्सा है जिस पर यह निदान टिका है। इसे एक बार पढ़ें, और अगली त्रुटि ऐसे घटक के साथ आएगी जो पहले से उससे जुड़ा हुआ है।