OpenVPN PAM: login आर्ग्युमेंट ही सेवा आहे, वापरकर्ता नाही

सर्व्हरवर वापरकर्ता जोडला गेला, पासवर्ड बरोबर टाइप केला, तरीही कनेक्शन AUTH_FAILED ने संपते। सहसा कारण प्लगइन ओळ स्पष्ट करते: प्लगइन मार्गानंतरचा शब्द PAM सेवा नाव आहे, आणि कोणता मॉड्यूल संच प्रश्नाचे उत्तर देतो हे तोच ठरवतो। ते वापरकर्तानाव नाही, आणि OpenVPN स्वतः वाचतो अशा पासवर्ड फाइलकडे निर्देश करणारेही नाही।

दुसरा शब्द काय निवडतो

कॉन्फिगरेशन ओळ एक प्लगइन मार्ग आणि एक आर्ग्युमेंट घेते:

plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

तो आर्ग्युमेंट सेवा नाव म्हणून PAM लायब्ररीकडे दिला जातो, त्यामुळे /etc/pam.d/openvpn मधील स्टॅक चालतो। तिथे login लिहिले तर त्याऐवजी संवादात्मक लॉगिन धोरण लागू होते, तुमच्या वितरणात ते धोरण जे मॉड्यूल समाविष्ट करते त्यासह।

स्थापित पॅकेज देते तो प्लगइन मार्ग वापरा, दुसऱ्या होस्टवरून कॉपी केलेला मार्ग नाही। फाइलनाव आणि डिरेक्टरी वितरणानुसार वेगळे असतात, आणि चुकीचा मार्ग प्रमाणीकरणाच्या वेळी नाही, सुरुवातीला प्लगइन लोड त्रुटीने अयशस्वी होतो।

स्टॅक प्रत्यक्षात खाती कुठून वाचतो

PAM एक डिस्पॅचर आहे। सेवा फाइल मॉड्यूल क्रमाने सूचीबद्ध करते, आणि उत्तर देऊ शकणारा पहिलाच निकाल ठरवतो। pam_unix कॉल करणारा स्टॅक स्थानिक खाती वाचतो; LDAP किंवा RADIUS मॉड्यूल कॉल करणारा स्टॅक क्रेडेन्शियल्स पूर्णपणे दुसरीकडे पाठवतो।

सेवा नाव ज्या फाइलमध्ये विरघळते ती, तिने समाविष्ट केलेल्या सर्वांसह वाचा:

cat /etc/pam.d/openvpn
grep -H pam_ /etc/pam.d/openvpn /etc/pam.d/common-auth

स्टॅक निर्णय डिरेक्टरीकडे सोपवत असेल, तर स्थानिक खाते जोडल्याने काहीच बदलत नाही। तो स्थानिक खाती वाचत असेल, तर डिरेक्टरीत वापरकर्ता तयार केल्यानेही काहीच बदलत नाही। खाते स्टॅक जिथे शोधतो तिथे असणे आवश्यक आहे, आणि अशा बहुतेक अहवालांमध्ये संपूर्ण निदान हेच असते।

एक प्रयत्न, दोन लॉग

एक अयशस्वी कनेक्शन दोन्ही बाजूंनी जोडून पाहा। OpenVPN लॉग प्लगइनचा निकाल आणि क्लायंटचा नकार दाखवतो; सिस्टम प्रमाणीकरण लॉग कोणता मॉड्यूल चालला आणि काय ठरवले ते दाखवतो। ते दोन्ही एकाच वेळ खिडकीत वाचणे म्हणजे गायब सेवा फाइल आणि बॅकएंड कालबाह्यता यातील फरक ओळखणे। प्रमाणीकरण लॉगमध्ये पोकळी असेल तर स्टॅकपर्यंत पोहोचलेच नाही असे समजा।

journalctl -u openvpn-server@server --since "-2 min"
journalctl -t sshd -t sudo --since "-2 min"

VPN आणि स्टॅक एकाच वेळी डीबग करू नये म्हणून PAM बोलणाऱ्या साधनाने सेवेची थेट चाचणी करा। त्याच सेवा नावाने आणि खात्याने थेट चाचणी यशस्वी झाली तर समस्या खात्यात नाही, डेमन क्रेडेन्शियल्स कसे पाठवतो यात सीमित होते।

pamtester openvpn alice authenticate

कन्सोलवर चालणाऱ्या त्याच क्रेडेन्शियल्सनी थेट चाचणी अयशस्वी झाली तर स्टॅक तुम्ही गृहीत धरलेला खाते स्रोत वाचत नाही। ती यशस्वी झाली तर प्लगइन चालवत असलेला संवाद आणि क्लायंटने प्रत्यक्षात काय पाठवले ते पाहा। मुद्दाम चुकीच्या पासवर्डनेही एकदा चालवा, म्हणजे नकार आणि मॉड्यूल त्रुटी यातील फरक दिसेल। ते दोन निकाल VPN लॉगमध्ये सारखेच दिसतात, इथे मात्र पूर्णपणे वेगळे।

समर्पित सेवा login संपादनापेक्षा बरी

VPN च्या गरजा संवादात्मक लॉगिनपेक्षा वेगळ्या असतील तर, सहसा वेगळ्या असतात, त्याला स्वतःची सेवा फाइल द्या। login किंवा common-auth संपादित केल्याने ती समाविष्ट करणाऱ्या प्रत्येक प्रोग्रामचे धोरण बदलते, आणि याच्याशी संबंध नसलेली लॉगिन समस्या डीबग करणारी पुढची व्यक्ती तुमचा बदल घेऊन पुढे जाईल।

आवश्यक मॉड्यूल एका छोट्या सेवा फाइलमध्ये कॉपी करा, क्रम स्पष्ट ठेवा, आणि मालक कोण आहे ते नोंदवा। पासवर्ड रीसेटचा परिणाम होत नसल्यासारखे वाटल्यास तपासायची तीच फाइल।

क्लायंट काय पाठवतो, काय पाठवत नाही

क्लायंट वापरकर्तानाव आणि पासवर्ड त्याच्या समर्थित प्रॉम्प्ट किंवा फाइलमार्फत देतो। सर्व्हर प्लगइन ती मूल्ये PAM संवादात पाठवतो; तो ती सर्व्हरच्या कॉन्फिगरेशनमधून वाचत नाही। पासवर्ड परिभाषित करत असल्यासारखी दिसणारी सर्व्हरबाजूची ओळ तसे करत नाही, आणि कोणतेही प्रोफाइल संपादन खाते तयार करत नाही।

वापरकर्तानाव आणि पासवर्ड क्लायंट प्रमाणपत्रांसह एकत्र राहू शकतात, आणि PAM सक्षम करणे म्हणजे प्रमाणपत्रांची पडताळणी थांबवण्याचे कारण नाही। तैनातीने हेतू ठेवलेले स्तर टिकवा आणि फक्त खाते स्रोत दुरुस्त करा।

स्वीकारार्हता दोन बाजूंची असते: हेतू असलेले खाते यशस्वी होते, आणि नाकारायचे खाते अजूनही अयशस्वी होते। auth-pam प्लगइनचे README सेवा आर्ग्युमेंट आणि ते समोर ठेवू शकणारे बॅकएंड वर्णन करते, आणि तुम्ही बांधू पाहत असलेली रचना पुष्टी करायची जागा तीच आहे।