OpenVPN client-connect हुक: तपाईंको ठेगाना वास्तवमा कहाँ जान्छ

client-connect स्क्रिप्टबाट ठेगाना फर्काउनु ग्राहकको IP सेट गर्नुपर्ने जस्तो देखिन्छ। तर त्यसो गर्दैन: हुकको सर्भरसँगको एकमात्र माध्यम एउटा अस्थायी फाइल हो जसको बाटो स्क्रिप्टको अन्तिम आर्गुमेन्टका रूपमा आउँछ, र ठेगाना त्यहाँ ifconfig-push सिन्ट्याक्समा लेख्नुपर्छ। ठेगाना प्रिन्ट गर्ने वा केही नलेखी शून्यसँग बाहिर निस्कने स्क्रिप्टले पूलबाट ठेगाना भएको जोडिएको ग्राहक बनाउँछ, र सर्भर लग पूर्ण रूपमा स्वस्थ देखिन्छ।

अलमल्याउनु स्वाभाविक हो, किनकि अन्य धेरै हुकहरू एक्जिट कोड वा वातावरण चलहरूमार्फत साँच्चै जवाफ दिन्छन्। यो हुकको आफ्नै करार छ, र करार फाइल नामबाट सुरु हुन्छ।

हुकले फाइल लेख्छ, फर्काउने मान होइन

घोषणा दुई लाइनको छ: कललाई अनुमति दिन script-security 2, त्यसपछि client-connect /etc/openvpn/server/assign-address.sh। ग्राहक प्रमाणीकरण भएपछि सर्भरले त्यो स्क्रिप्ट सिर्जना गरिएको फाइल बाटो अन्तिम आर्गुमेन्टका रूपमा थपेर चलाउँछ, जो $1 तब मात्र हुन्छ जब घोषणाले आफ्नै कुनै अतिरिक्त आर्गुमेन्ट पठाउँदैन। त्यो ग्राहकमा लागू हुने सबै कुरा त्यो फाइलमा साधारण निर्देशनका रूपमा, प्रत्येक लाइनमा एक, कन्फिगरेसनमा देखिने जस्तै लेखिन्छ। आफ्नै प्यारामिटर थप्ने र्यापरले स्थान सार्छ, र चिरपरिचित लक्षण भनेको --verbose जस्तो देखिने बाटोमा लेख्ने स्क्रिप्ट हो।

एक्जिट स्थिति करारको अर्को आधा हो। शून्य भनेको स्वीकार र फाइल पढ; अरू जुनसुकै कुराले जडान अस्वीकार गर्छ, र यसरी नक्सा नगरिएको पहिचान चुपचाप पूलमा फर्किनुको सट्टा अस्वीकार गरिन्छ। सफलता फर्काउनु अघि पूरा निर्देशन लेख्नुहोस्, ताकि आधा लेखिएको फाइल कहिल्यै ग्राहकको कन्फिगरेसन नबनोस्।

दुई निर्देशन ध्यान दिनयोग्य छन् किनकि तिनीहरू बाँकी सबैसँग अन्तरक्रिया गर्छन्। ifconfig-push ले ठेगाना तय गर्छ, जबकि पठाइएको route ले ग्राहकलाई सुरुङमार्फत के पुग्न सकिन्छ भन्ने बताउँछ; पहिलो फर्काएर दोस्रो बिर्सनुभयो भने ठेगाना भएको तर जाने ठाउँ नभएको ग्राहक पाउनुहुन्छ। फाइलभित्रको क्रम महत्त्वपूर्ण छैन, तर पूर्णता महत्त्वपूर्ण छ। कुनै पनि सहकर्मीले पुग्न नसक्ने प्रिफिक्सका लागि रुट पठाउने हुक अर्को छेउबाट देखिएको त्यही गल्ती हो।

इनपुटहरू वातावरण चलहरूमार्फत आउँछन्: common_name, trusted_ip, ifconfig_pool_remote_ip र बाँकी। तिनीहरू सबैलाई सर्भरबाहिरका स्ट्रिङका रूपमा लिनुहोस्, कहिल्यै शेलका टुक्राका रूपमा होइन।

ठेगाना म्यापिङ एउटा नीति हो, अंकगणित होइन

एउटा लोभ्याउने छोटो बाटो भनेको प्रमाणपत्रको नाम पार्स गरेर त्यसका अंकहरूलाई अन्तिम अक्टेटका रूपमा प्रयोग गर्नु हो। त्यो आवंटक होइन, र त्यो सामान्य तरिकाले असफल हुन्छ: एउटै प्रत्यय भएका दुई नाम ठोक्किन्छन्, 300 मा अन्त्य हुने नाम ठेगाना होइन, र प्रशासकले नाम बदलेको प्रमाणपत्रले यन्त्रलाई चुपचाप सार्छ। प्रत्येक कलमा सबनेट सदस्यता, प्रयोगयोग्य होस्ट दायरा, आरक्षित ठेगाना र अद्वितीयता जाँच्नुहोस्, र म्यापिङलाई मानिसले पढ्न सक्ने तालिकामा राख्नुहोस्।

जसले नाम नियन्त्रण गर्छ उसले ठेगाना नियन्त्रण गर्छ, त्यसैले यो परिनियोजनमा common_name ले वास्तवमा के प्रतिनिधित्व गर्छ भनेर निर्णय गर्नुहोस्। username-as-common-name सक्षम हुँदा पहिचान लगइन हो, प्रमाणपत्रको विषय होइन। त्यो मान कहिल्यै शेल मूल्यांकनमा नपठाउनुहोस्, र ग्राहकलाई कहिल्यै फाइल बाटोमा प्रभाव पार्न नदिनुहोस्।

दर्ता-आधारित आवंटकले समवर्तीता सहनुपर्छ। ठेगाना आणविक रूपमा आरक्षित गर्नुहोस्, आधा कन्फिगर भएको ग्राहक प्रवेश नगराई असफल लेखन व्यवस्थापन गर्नुहोस्, र प्रत्येक आवंटनलाई त्यसको मालिक जडानसँग ट्याग गर्नुहोस्, ताकि पुरानो सत्रको ढिलो विच्छेदले नयाँ सत्रले पहिले नै राखेको ठेगाना मुक्त गर्न नसकोस्। एउटै पूल साझा गर्ने धेरै सर्भर इन्स्ट्यान्सहरूले यो आवश्यकतालाई वैकल्पिक नभई थप तीव्र बनाउँछन्।

टोपोलोजीले ifconfig-push को अर्थ निर्धारण गर्छ

10.77.0.0/24 मा topology subnet सहित, ifconfig-push 10.77.0.20 255.255.255.0 ठेगाना र त्यसको नेटमास्क हो। topology net30 अन्तर्गत दोस्रो आर्गुमेन्ट नेटमास्क होइन तर सहकर्मीको ठेगाना हो, त्यसैले सबनेट स्वरूप net30 सर्भरमा प्रतिलिपि गर्दा जोडिने तर ट्राफिक पार गर्न नसक्ने ग्राहक पाइन्छ। टोपोलोजी जानाजान परिवर्तन गर्नुहोस्, उदाहरण सुसंगत देखियोस् भनेर कहिल्यै होइन। पहिले नै net30 चलिरहेको सर्भरसँग पुरानो ठेगानामा जीवित ग्राहकहरू छन्, त्यसैले परिवर्तन भनेको मर्मत विन्डोसहितको स्थानान्तरण हो, एक लाइनको सम्पादन होइन।

स्थिर ठेगानाहरू गतिशील पूलबाहिर र अन्य प्रत्येक स्थिर आवंटनबाहिर हुनुपर्छ, जसमा साधारण client-config-dir फाइलहरूले दिने ठेगानाहरू पनि समावेश छन्। यदि दुई संयन्त्रले विभिन्न ग्राहकका लागि एउटै ठेगाना उत्पादन गर्न सक्छन् भने तिनमध्ये एकले अन्ततः त्यसो गर्नेछ।

यसमा भरोसा गर्नु अघि चार अवस्था परीक्षण गर्नुहोस्

उही जाँचहरू नक्सा गरिएको पहिचान, नगरिएको पहिचान, पुनःजडान र अनुकरण गरिएको दर्ता विफलतामा चलाउनुहोस्। openvpn --config client.ovpn --verb 4 ले तोकिएको ठेगाना पुश जवाफमा देखाउँछ, र सर्भरमा grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log ले वास्तवमा के पठाइयो भनी पुष्टि गर्छ। नक्सा नगरिएको पहिचानका लागि अपेक्षित नतिजा अस्वीकृत जडान हो, पूलको ठेगाना होइन।

त्यसपछि डेमनले ती अस्थायी फाइलहरू लेख्ने डाइरेक्टरी जाँच्नुहोस्। स्क्रिप्ट तल्लो तहको सेवा सन्दर्भमा चल्छ, त्यसैले root लेख्न सक्ने तर डेमनले नसक्ने बाटोले प्रत्येक जडानलाई लगमा धेरै लाइन तल गाडिएको अनुमति त्रुटिसहित अस्वीकारमा परिणत गर्छ।

आवंटन अधिकार होइन: पिन गरिएको ठेगानाले अझै सर्भरपछाडिको प्रत्येक गन्तव्यमा पहुँच दिँदैन। राउटिङ र फायरवाल नीति आफ्नै तहमा राख्नुहोस्, र तपाईंले भर्खर तय गर्नुभएको ठेगानाविरुद्ध त्यसलाई प्रमाणित गर्नुहोस्।