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 बोल्ने गेटवेमा प्रमाणपत्र प्रमाणीकरण अन्त्य गर्छन्, र त्यस अवस्थामा यी सर्भर निर्देशनमध्ये कुनै पनि लागू हुँदैन। छिमेकी उत्पादनको होइन, आफ्नै प्लेटफर्मले कागजात गर्ने मोडेल प्रतिलिपि गर्नुहोस्। महत्वपूर्ण निर्देशनहरू पर्याप्त फरक छन् कि तिनीहरूलाई मिसाउँदा पार्स हुने र त्यसपछि कसैलाई पनि प्रमाणीकरण नगर्ने कन्फिगरेसन बन्छ।