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

इथली वाटचाल प्लगइनच्या सेवा नावापासून सुरू होते, धोरण तयार करते आणि नंतर तीन महत्त्वाचे परिणाम तपासते: सदस्य, वैध पासवर्ड असलेला बाहेरचा माणूस आणि खराब ओळखपत्र।

वेगळी PAM सेवा का

auth-pam प्लगइन त्याचा आर्ग्युमेंट म्हणून सेवा नाव घेते। ते नाव /etc/pam.d खालील फाइल निवडते, आणि त्या फाइलमधील स्टॅक VPN लॉगिनच्या वेळी चालतो। सिस्टम-व्यापी लॉगिन वापरते तेच नाव दिल्यास, त्या स्टॅकमधील प्रत्येक निर्णय तुम्ही वारसा घेता, नंतर असंबंधित कारणांनी जोडलेले निर्णयही।

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

सेवा वेगळी करणे नुकसानीची व्याप्तीही मर्यादित करते। सामायिक स्टॅकमधील फक्त-VPN नियम सर्वांसाठी SSH किंवा कन्सोल प्रवेश नाकारू शकतो, ज्यामुळे प्रवेश बदल हा व्यत्यय बनतो।

गटाचा नियम लिहिणे

पात्रता तपासणी ओळखपत्र सत्यापित झाल्यानंतरच्या खाते टप्प्यात येते। account required pam_succeed_if.so user ingroup vpnusers सारखा नियम प्रमाणित वापरकर्ता त्या गटाचा सदस्य असेल तेव्हाच प्रक्रिया पुढे जाऊ देतो।

ती ओळ एक तुकडा आहे, संपूर्ण सेवा नाही। प्रत्येक स्वीकारलेला मार्ग जिथे पोहोचतो तिथे ती जोडा, आणि तिच्या आसपासचे नियंत्रण फ्लॅग तपासा। स्टॅकमधील आधीचे sufficient किंवा उडी नियंत्रण तुमचा नियम चालण्यापूर्वी प्रक्रिया संपवू शकते, ज्यामुळे बंधन हे फक्त सूचना बनते।

सवयीने use_uid जोडू नका। त्याशिवाय मॉड्यूल प्रमाणित होणाऱ्या वापरकर्त्याचे मूल्यांकन करते; त्यासह मॉड्यूल OpenVPN प्रक्रिया ज्या खात्याखाली चालते त्याचे मूल्यांकन करते, जे सहसा root किंवा सेवा खाते असते आणि म्हणून लॉगिन करणारी व्यक्ती नसते।

गट सदस्यत्व सिस्टमच्या ओळख निराकरणातून येते, तुम्ही ओळखता त्या नावातून नाही। डिरेक्टरी वापरकर्त्यांसाठी, तोच backend त्या वापरकर्त्याच्या गट चौकशांना उत्तर देतो याची खात्री करा, कारण परिचित नावाचा स्थानिक गट त्याच नावाच्या डिरेक्टरी गटापेक्षा वेगळी वस्तू आहे।

क्रम आणि ओळखीचे सापळे

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

दुहेरी स्टॅकपासून सावध राहा। सामान्य नमुना म्हणजे आधीच खाते नियम असलेला include, त्यानंतर तुमचा स्वतःचा गट नियम, ज्यामुळे एक अपेक्षित असलेल्या जागी दोन निर्णय तयार होतात। फक्त तुम्ही संपादित केलेली फाइल नाही, तर समाविष्ट फाइलही वाचा। प्रभावी क्रम पाहण्याचा जलद मार्ग म्हणजे फाइल वरून खाली वाचून प्रत्येक नियंत्रण मूल्य नोंदवणे।

इतर प्रवेश अटी अभंग ठेवा। यशस्वी पासवर्ड प्रमाणपत्र तपासण्या, दुसरा घटक किंवा कनेक्शननंतरचे अधिकृतता यांची जागा घेत नाही, आणि हे धोरण त्यांपैकी कोणाचाही पर्याय नाही। खाते VPN प्रवेशासाठी विचारात घेण्यायोग्य आहे की नाही हे ते फक्त ठरवते।

सदस्य, बाहेरचे लोक आणि चुकीचे पासवर्ड तपासणे

धोरण पूर्ण मानण्यापूर्वी तीन प्रकरणे तपासा। सदस्य यशस्वीरित्या जोडतो। गटाबाहेरचे वैध खाते त्याचा पासवर्ड प्रमाणित करते पण त्याला VPN प्रवेश नाकारला जातो। कोणत्याही खात्यासाठी चुकीचा पासवर्ड प्रमाणीकरण टप्प्यात नाकारला जातो, गट नियमाने नाही।

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

PAM संपादित करताना दुसरे सत्र उघडे ठेवा, आणि बदलानंतर सामान्य SSH लॉगिनही तपासा। समर्पित सेवेचा हेतू असा आहे की सिस्टम लॉगिन अप्रभावित राहिले पाहिजे, आणि ते जाणून घेण्याचा एकमेव मार्ग म्हणजे ते तपासणे।

काही तुटल्यास प्रत मधून मागील सेवा फाइल पुनर्संचयित करा। हवा असलेला नियम सांगणे सोपे आहे: सदस्यत्व खात्याला VPN प्रवेशासाठी पात्र बनवते, आणि इतर प्रत्येक आवश्यक तपासणी अजूनही लागू आहे।

संबंधित लेख