OpenVPN PAM: लॉगिन आर्ग्युमेंट एक सेवा है, उपयोगकर्ता नहीं
auth-pam प्लगइन के पथ के बाद का शब्द PAM स्टैक चुनता है। उस स्टैक को पढ़ें, उसका खाता स्रोत खोजें, फिर प्रोफ़ाइल संपादित करने से पहले उसे pamtester से जाँचें।
सर्वर पर एक उपयोगकर्ता जोड़ा गया, पासवर्ड सही टाइप किया गया, और कनेक्शन फिर भी 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"PAM बोलने वाली उपयोगिता से सेवा को सीधे जाँचें, ताकि आप एक साथ VPN और स्टैक को डिबग न करें। उसी सेवा नाम और खाते के साथ सफल सीधी जाँच समस्या को इस बात तक सीमित करती है कि डेमॉन क्रेडेंशियल कैसे भेजता है, खाते तक नहीं।
pamtester openvpn alice authenticateअगर सीधी जाँच कंसोल पर काम करने वाले उन्हीं क्रेडेंशियल के साथ विफल होती है, तो स्टैक आपके अनुमानित खाता स्रोत को नहीं पढ़ रहा है। अगर वह सफल होती है, तो प्लगइन जो बातचीत करता है और क्लाइंट ने वास्तव में क्या भेजा, यह देखें। जानबूझकर गलत पासवर्ड के साथ भी एक बार चलाएँ, ताकि आप अस्वीकरण और मॉड्यूल त्रुटि के बीच का अंतर देख सकें। वे दोनों परिणाम VPN लॉग में एक जैसे दिखते हैं और यहाँ पूरी तरह अलग।
समर्पित सेवा लॉगिन संपादित करने से बेहतर है
VPN को उसकी अपनी सेवा फ़ाइल दें जब उसकी आवश्यकताएँ इंटरैक्टिव लॉगिन से भिन्न हों, जो आमतौर पर होती हैं। login या common-auth संपादित करने से उन्हें शामिल करने वाले हर प्रोग्राम की नीति बदल जाती है, और असंबंधित लॉगिन समस्या डिबग करने वाला अगला व्यक्ति आपका बदलाव विरासत में पाता है।
आवश्यक मॉड्यूल को एक छोटी सेवा फ़ाइल में कॉपी करें, क्रम स्पष्ट रखें, और नोट करें कि इसका स्वामी कौन है। पासवर्ड रीसेट का कोई प्रभाव न दिखने पर यही फ़ाइल जाँचनी होती है।
क्लाइंट क्या भेजता है, और क्या नहीं
क्लाइंट अपने समर्थित प्रॉम्प्ट या फ़ाइल के माध्यम से उपयोगकर्ता नाम और पासवर्ड देता है। सर्वर प्लगइन उन मानों को PAM बातचीत में भेजता है; वह उन्हें सर्वर के कॉन्फ़िगरेशन से नहीं पढ़ता। सर्वर की ओर की ऐसी पंक्ति जो पासवर्ड परिभाषित करती प्रतीत होती है, ऐसा नहीं करती, और कोई भी प्रोफ़ाइल संपादन खाता नहीं बनाएगा।
उपयोगकर्ता नाम और पासवर्ड क्लाइंट प्रमाणपत्रों के साथ रह सकते हैं, और PAM सक्षम करना प्रमाणपत्रों की जाँच बंद करने का कारण नहीं है। परिनियोजन ने जो परतें चाही थीं उन्हें रखें और केवल खाता स्रोत ठीक करें।
स्वीकृति दोतरफ़ा है: इच्छित खाता सफल होता है, और जिस खाते को अस्वीकार होना चाहिए वह अभी भी विफल होता है। फ़ाइल auth-pam प्लगइन का README सेवा आर्ग्युमेंट और उन बैकएंड का दस्तावेज़ीकरण करता है जिन्हें वह संभाल सकता है, और जिस व्यवस्था को आप बनाना चाहते हैं उसकी पुष्टि वहीं होती है।