OpenVPN मध्ये RADIUS जोडणे: प्लगइन की स्क्रिप्ट हुक?

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

दंतकथा: प्लगइन हाच समर्थित मार्ग

प्लगइन हा OpenVPN प्रक्रियेत लोड होणारा सामायिक ऑब्जेक्ट आहे, म्हणून तो ती प्रक्रिया देते त्या इंटरफेसशी जुळला पाहिजे। बिल्ड बदलतात, पॅकेजिंग बदलते, आणि जुन्या इंटरफेससाठी कंपाइल केलेली लायब्ररी लोड होण्यास सरळ नकार देते। सर्व्हर कॉन्फिगरेशनमधील काहीही ती तफावत भरून काढू शकत नाही, म्हणून "फक्त radiusplugin स्थापित करा" हा सल्ला सुरू न होणाऱ्या सर्व्हरवर संपतो।

स्क्रिप्ट हुक त्याऐवजी प्रक्रियेबाहेर असतो। OpenVPN एक प्रोग्राम चालवतो, त्याला क्रेडेन्शियल्स देतो आणि निर्णय वाचतो। हेच विलगीकरण त्याला अपग्रेडमधून टिकवते, आणि तेच त्याला प्लगइन कधीही नव्हते अशा पद्धतीने तुमची जबाबदारी बनवते।

कोणताही दृष्टिकोन रचनेने अधिक सुरक्षित नाही। एक डेमनच्या आत परदेशी कोड चालवतो; दुसरा क्रेडेन्शियल्स हातात घेऊन तुमचा कोड त्याच्या शेजारी चालवतो। योग्य प्रश्न हा आहे की या दोन जोखमींपैकी कोणती तुम्ही खरोखर सांभाळू शकता।

प्लगइनने काय एकत्र बांधले

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

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

असा प्लगइन अजूनही तुमच्या बिल्डवर लोड होत असेल, तर तो लहान कार्यरत पृष्ठभाग असू शकतो। तो कोणत्या इंटरफेससाठी बनवला होता याची पुष्टी करा, तुम्ही चाचणी केलेल्या बिल्डशी तो पिन ठेवा, आणि कोणतेही अपग्रेड नियमित पॅकेज अपडेटऐवजी पूर्ण लॉगिन चाचणी आवश्यक असलेला बदल माना।

स्क्रिप्ट हुक प्रत्यक्षात कशावर विश्वास ठेवतो

हुक auth-user-pass-verify आणि वितरण यंत्रणेसह संरचित केला जातो: पर्यावरण चल किंवा तात्पुरती फाइल। पर्यावरण स्वरूपात OpenVPN ला script-security 3 आवश्यक आहे, जो स्क्रिप्टना पासवर्ड उघड करण्यास परवानगी देणारा दस्तऐवजी स्तर आहे। तो स्तर डीफॉल्टचे जाणीवपूर्वक कमकुवत करणे आहे, आणि त्याकडे कारण जोडलेली परवानगी म्हणून पाहिले पाहिजे।

स्क्रिप्ट ज्याला स्पर्श करते ते सर्व तो विश्वास वारसाहक्काने घेते। ते root च्या मालकीचे असावे, गट किंवा इतरांना लिहिण्यायोग्य नसावे, पूर्ण पथाने संदर्भित असावे, आणि अविश्वसनीय मूल्य शेलपर्यंत पोहोचणारी कोणतीही जागा नसावी। प्रत्येक चल उद्धरणात ठेवा, अनपेक्षित अक्षरे नाकारा, आणि दिलेल्या वापरकर्तानावावरून कधीही आदेश तयार करू नका। प्रत्येक लॉगिन प्रयत्नाला root म्हणून चालणारी स्क्रिप्ट त्या चार गुणांमुळेच एकदा पुनरावलोकनास पात्र आहे।

ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh

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

एक्झिट कोड ठरवतात की तुम्ही उघडेत अपयशी व्हाल का

स्क्रिप्टची एक्झिट स्थिती हाच निर्णय: शून्य स्वीकारते, अशून्य नाकारते। त्रास देणारा नमुना म्हणजे असा शेल स्क्रिप्ट जो RADIUS प्रतिसादात विशिष्ट स्वीकृती टोकन असेल तेव्हाच स्वीकारतो आणि बाकी सर्वांसाठी अपयश परत करतो, कारण ते तीन वेगळ्या घटना एका उत्तरात विलीन करते। चुकीचा पासवर्ड, पोहोचता न येणारा सर्व्हर आणि विकृत प्रतिसाद सर्व एकच नकार बनतात।

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

दोन सवयी उर्वरित सुज्ञ ठेवतात। RADIUS अधिकार असेल, तर पासवर्ड तपासला जाणारी एकमेव जागा तीच असावी, कारण सावली तक्ता एकाच प्रश्नाला दोन उत्तरे तयार करतो आणि दुसरे कोणीही न पाहणारे हल्ला-पृष्ठ आहे। आणि लक्षात ठेवा हुक प्रत्येक पुनःप्रयत्नाला पुन्हा बोलावला जातो, म्हणून संथ स्क्रिप्ट आणि अधीर क्लायंट मिळून RADIUS बाजूला विलंब किंवा धोरण न जोडल्यास पासवर्ड अंदाजासाठी वर्धक बनतात।

प्रमाणपत्र गेल्यावर तुम्ही काय सोडता

या आकारातील अनेक तैनाती क्लायंट-प्रमाणपत्र तपासणी पूर्णपणे बंद करतात, आणि वापरकर्तानाव व पासवर्ड हे क्लायंटचा संपूर्ण दावा ठेवतात। त्या सेटिंगसह जे नाहीसे होते ते प्रमाणपत्र-आधारित ओळख आहे। चॅनेल एन्क्रिप्टेड राहते, पण क्लायंटला नाव देणारी एकमेव गोष्ट RADIUS चा निर्णय आहे। आधी प्रमाणपत्राच्या विषयावर अवलंबून असलेल्या कोणत्याही प्रवाहातील गोष्टीला आता वापरकर्तानावावर अवलंबून राहावे लागेल।

नियंत्रण-चॅनेल संरक्षण स्थानावर ठेवा जेणेकरून अप्रमाणित सहकारी हँडशेक तपासू किंवा पूर आणू शकणार नाही, आणि प्रति-वापरकर्ता कॉन्फिगरेशन सामान्य नावावर अवलंबून असताना username-as-common-name वापरा। व्यवस्थापित गेटवे हे बहुतेकदा वेगळ्या पद्धतीने सोडवतात, RADIUS शी EAP-TLS बोलणाऱ्या गेटवेवर प्रमाणपत्र प्रमाणीकरण संपवतात, आणि त्या बाबतीत यापैकी कोणतेही सर्व्हर निर्देश लागू होत नाहीत। शेजारच्या उत्पादनाचे नव्हे, तुमचेच प्लॅटफॉर्म जे मॉडेल दस्तऐवजीकरण करते त्याची प्रत करा। महत्त्वाचे निर्देश पुरेसे वेगळे आहेत की ते मिसळल्यास पार्स होणारे आणि नंतर कोणाचेही प्रमाणीकरण न करणारे कॉन्फिगरेशन तयार होते।