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 चा आढावा कॉन्फिगरेशन आणि सत्रांसाठी उघड केलेल्या ऑब्जेक्ट मार्गांचे दस्तऐवजीकरण करतो, आणि हा निदान ज्या रचनेवर उभा आहे तोच तो भाग आहे. एकदा वाचा, आणि पुढील त्रुटी आधीच त्याला जोडलेल्या घटकासह येईल.