OpenVPN सेवा खाजगी कीचा पासवर्ड विचारताना थांबते: कसे दुरुस्त करावे
सेवेकडे टर्मिनल नाही, म्हणून एन्क्रिप्टेड कीला askpass आणि वाचनीय फाइल लागते. कीचा पासफ्रेज सर्व्हर लॉगिनपासून वेगळा ठेवा आणि unit तपासा.
OpenVPN स्थानिक मशीनवर खाजगी कीचा पासफ्रेज विचारते, त्यामुळे काम करणारी लॉगिन फाइल त्याला कधीच उत्तर देत नाही. सेवेमध्ये टाइप करण्यासाठी टर्मिनल नसते, आणि सुरुवात एकतर अडकते किंवा कारण नाही तर इनपुटचे नाव घेणाऱ्या जर्नल नोंदीसह अयशस्वी होते. येथे दोन गुपिते आहेत, आणि unit पुन्हा सुरू करण्यापूर्वी प्रत्येकाला स्वतःचा वाचनीय स्रोत हवा. खालील क्रम त्यांना वेगळा करतो, नंतर प्रत्येक फाइल प्रत्यक्षात उघडणारी ओळख तपासतो.
दोन विनंत्या वेगळ्या ओळखा
कीचा पासफ्रेज स्थानिक खाजगी की डिक्रिप्ट करतो; खात्याची क्रेडेन्शियल्स सर्व्हरशी सत्र प्रमाणित करतात. ती वेगवेगळ्या ठिकाणांहून येतात, वेगवेगळ्या क्षणी अयशस्वी होतात आणि वेगवेगळे संदेश देतात. ती गोंधळल्याने लोक पासवर्ड रीसेट शोधायला जातात, पण खातेच सहभागी नव्हते. कोणते गुपित गहाळ आहे याचा एकमेव विश्वासार्ह सुगावा शब्दरचना आहे, म्हणून कोणताही पर्याय बदलण्यापूर्वी विनंतीचा मजकूर वाचा.
Community OpenVPN 2.x मध्ये askpass पहिल्या ओळीत कीचा पासफ्रेज ठेवणारी फाइल दाखवते, आणि auth-user-pass एका ओळीत वापरकर्तानाव व पुढच्या ओळीत पासवर्ड असलेली फाइल दाखवते. दोन्हीपैकी कोणतीही फाइल दुसरा पर्याय पूर्ण करू शकत नाही. डेस्कटॉप अ‍ॅप किंवा NetworkManager प्रोफाइल दोन्ही आपल्या गुपित भांडारात ठेवू शकते, जे कमांड-लाइन क्लायंट कधीच वाचत नाही, म्हणून कोणताही मार्ग लिहिण्यापूर्वी तुम्ही कोणता क्लायंट कॉन्फिगर करत आहात ते नोंदवा.
दोन्ही पर्याय वाचनीय फाइलांकडे वळवा
दोन्ही इनपुट लागणाऱ्या प्रोफाइलकडे शेवटी तीन फाइल संदर्भ असतात: एन्क्रिप्टेड की, ती उघडणारा पासफ्रेज आणि लॉगिन जोडी. CA आणि ओळख तपासण्यांना हात न लावता ते जोडा, कारण ते सर्व्हर कोण आहे हे ठरवतात आणि या समस्येचा भाग नाहीत. जर तैनाती खाते क्रेडेन्शियल्स अजिबात वापरत नसेल, तर auth-user-pass जोडल्याने कोणीही देऊ न शकणारे इनपुट तयार होते.
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authविना-वितर्क पर्याय मार्ग असलेल्या पर्यायांपेक्षा वेगळे वागतात, आणि सेवेमध्ये हा फरक महत्त्वाचा आहे. विना-वितर्क askpass अजूनही कन्सोल वाचतो, आणि फक्त वापरकर्तानाव असलेली auth-user-pass फाइल अजूनही पासवर्ड विनंती प्रतीक्षेत ठेवते. क्लायंट डेमन झाल्यावर तो टर्मिनलकडून इनपुट मागूच शकत नाही, म्हणून अशा प्रकारे कॉन्फिगर केलेली सेवा सुरू होत नाही.
निरपेक्ष मार्ग कार्यरत डिरेक्टरीचा प्रश्न दूर करतात पण प्रवेश देत नाहीत. नंतर मालकी, मोड आणि मार्गक्रमण येते, आणि तिन्ही प्रक्रिया ज्या खात्याखाली चालते त्याच्याशी तपासल्या जातात.
प्रोफाइलपूर्वी unit चे कॉन्फिगरेशन वाचा
इन्स्टन्स कोणते कॉन्फिगरेशन लोड करेल हे unit ठरवते, तुम्ही संपादित करत असलेली फाइल नाही. त्याची कमांड लाइन आणि सर्व drop-in वाचा, नंतर कार्यरत डिरेक्टरीतून प्रत्यक्षात वापरल्या जाणाऱ्या प्रोफाइलपर्यंत जा. दुसऱ्या .ovpn फाइलमध्ये जोडलेला पासफ्रेज संदर्भ या इन्स्टन्ससाठी काहीही बदलत नाही.
तीन फक्त-वाचन आदेश यातील बहुतेकांना उत्तर देतात. पहिला unit आणि सर्व drop-in छापतो, दुसरा प्रक्रियेला बांधणारी ओळख व सँडबॉक्स सेटिंग्ज छापतो, आणि तिसरा मागील सुरुवातीने प्रत्यक्षात कशाची तक्रार केली ते छापतो. होस्टवर असलेले इन्स्टन्स नाव वापरा:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bProtectHome आणि प्रोफाइलच्या स्वतःच्या user, group व chroot पर्यायांकडे लक्ष द्या. होम डिरेक्टरीखालील फाइल तुमच्या शेलमध्ये वाचनीय असू शकते आणि होम डिरेक्टऱ्या लपवल्यावर सेवेच्या आत अदृश्य होते. systemd ज्या खात्याने सुरू होते तेच खाते शेवटी की उघडते असे नाही.
रनटाइम ओळख दोन्ही फाइल उघडू शकते हे सिद्ध करा
फक्त मोड वाचणे पुरत नाही, कारण मार्गावरील प्रत्येक डिरेक्टरी त्याच ओळखीने ओलांडता येण्याजोगी असली पाहिजे. मार्ग घटकागणिक चाला, नंतर प्रक्रिया वापरत असलेल्या खात्याने उघडण्याची चाचणी घ्या. root च्या मालकीची आणि मोड 600 असलेली फाइल प्रक्रिया अजून root असतानाच चालते, आणि अनेक प्रोफाइल करतात त्या विशेषाधिकार कपातीनंतर ते खरे नसते. दोन आदेश मार्गक्रमण आणि उघडणे दोन्ही व्यापतात:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableपहिला आदेश प्रत्येक घटकाचा मोड छापतो आणि खाते ओलांडू शकत नाही तिथे अयशस्वी होतो; दुसरा एकमेव महत्त्वाच्या प्रश्नाचे उत्तर देतो, म्हणजे रनटाइम ओळख फाइल वाचनासाठी उघडू शकते का. दोन्हीही फाइलचा मजकूर छापत नाहीत, आणि फाइलमध्ये पासफ्रेज असताना हाच मुख्य मुद्दा आहे. लॉगिन फाइलसाठीही चाचणी पुन्हा करा, कारण दोन्ही बऱ्याचदा वेगळ्या मालकीने साठवल्या जातात.
जर प्रक्रिया chroot किंवा मर्यादित namespace वापरत असेल, तर तीच चाचणी त्या दृश्याच्या आतून चालवा, नाहीतर उत्तर चुकीच्या फाइलसिस्टमचे वर्णन करते. लपलेल्या होम डिरेक्टरीखाली साठवलेला पासफ्रेज हे unit बाहेर पास होऊन आत अयशस्वी होणाऱ्या चाचणीचे नेहमीचे उदाहरण आहे.
पहिली सुरुवात तपासा, नंतर पुनःकनेक्शन
इन्स्टन्स एकदा सुरू करा आणि शेवटचा नाही तर पहिला अपयश वाचा. गहाळ इनपुट फाइल, अयशस्वी की डिक्रिप्शन आणि सर्व्हरकडून AUTH_FAILED या तीन वेगळ्या घटना आहेत, तीन वेगळ्या दुरुस्त्यांसह. परवानगीचा इशारा दुरुस्त केल्याने की उघडली का हे काहीही सिद्ध होत नाही.
जर्नलची ओळ सांगते की तीनपैकी कोणती स्थिती आहे. दुरुस्ती कोणते इनपुट अयशस्वी झाले यावरून येते:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
नंतर तुम्हाला खरोखर आवश्यक असलेले जीवनचक्र तपासा: बूटवर सुरुवात आणि कोणतेही समर्थित पुनःकनेक्शन, केवळ तुमच्या शेलमधून हाताने सुरू करणे नाही. auth-nocache असल्यास इनपुट पहिल्या वापरानंतर टाकून दिले जातात, म्हणून नंतरच्या पुनःकनेक्शनलाही वाचनीय स्रोत लागतो. डेस्कटॉप लॉगिनला उघडणारे कीरिंग कोणी लॉगिन करण्यापूर्वी सुरू झालेल्या सेवेला उपलब्ध नसते, आणि हातची चाचणी पास होऊन रीबूट अयशस्वी होण्याचे हेच नेहमीचे कारण आहे. जर पहिली सुरुवात यशस्वी झाली आणि नंतरचे पुनःकनेक्शन अयशस्वी झाले, तर परवानग्या पुन्हा बदलण्यापूर्वी पुनःकनेक्शन घटनेसाठी जर्नल वाचा.
कीच्या बाजूला पासफ्रेज ठेवल्याने एन्क्रिप्शन जे देते ते कमी होते, म्हणून ती फाइल आणि तिच्या बॅकअप मर्यादित ठेवा. कीचा पासफ्रेज काढणे हे गहाळ इनपुटची दुरुस्ती नसून स्वतंत्र क्रेडेन्शियल निर्णय माना. मानवी मंजुरी किंवा इंटरअ‍ॅक्टिव्ह MFA वर अवलंबून असलेल्या तैनातीला तिचा समर्थित एजंट किंवा व्यवस्थापन एकत्रीकरण हवे; कायम साठवलेला एकवेळ कोड समतुल्य पर्याय नाही.