OpenVPN को auth-user-pass-verify स्क्रिप्ट: सही एग्जिट कोड

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

सम्झौता सानो छ: पेस गरिएको खाता पहिचान गर्नुहोस्, स्वीकृत प्रमाणितकर्तालाई इच्छित प्रश्न सोध्नुहोस् र त्यो अनुरोधका लागि त्यही प्रमाणितकर्ताको कागजातीय सकारात्मक नतिजा मात्र स्वीकार गर्नुहोस्। बाँकी सबै पूर्वाधार हो।

हुकले फर्काउन सक्ने तीन स्थिति

auth-user-pass-verify का लागि OpenVPN 2.6 म्यानुअल एग्जिट कोड 0 लाई स्वीकृति, 1 लाई अस्वीकृति र 2 लाई स्थगित प्रमाणीकरणका रूपमा परिभाषित गर्छ। सर्भरले बुझ्ने एकमात्र तीन उत्तर यिनै हुन्, र प्रत्येकको जडानमा फरक असर पर्छ। आफ्नो अन्तिम आदेशको स्थितिसँग बाहिर निस्कने स्क्रिप्टले वास्तवमा लग कल वा सफाइको चरणलाई मत दिन दिएको हुन्छ। प्रत्येक शाखामा स्थिति स्पष्ट लेख्नुहोस्, प्रमाणितकर्तासम्म कहिल्यै नपुगेका शाखाहरू पनि समेटेर।

HTTP सफलता र प्रमाणीकरण सफलता अलग तह हुन्, र तिनलाई मिसाउनु यो हुक गल्ती हुने सबैभन्दा सामान्य तरिका हो। 202 प्रतिक्रियाको अर्थ अनुरोध प्रशोधनका लागि स्वीकार गरियो भन्ने हो, पासवर्ड प्रमाणित भयो भन्ने होइन। अपेक्षित स्थिति, प्रतिक्रियाको आकार र अन्तिम निर्णय तपाईंलाई दिइएको API सम्झौताबाट तय गर्नुहोस्, र विश्वसनीय देखिन्छ भन्दैमा कुनै फिल्डको नाम नबनाउनुहोस्।

यदि उत्तर साँच्चै पछि आउँछ भने त्यो स्थगित मार्ग हो र त्यसलाई त्यसै गरी बनाउनुपर्छ। कहिल्यै पूरा नहुने स्थगित प्रयासले समयसीमा सकिएसम्म स्रोतहरू रोकिराख्छ।

प्रमाणपत्र फाइल जस्तै लेखिएको छ त्यस्तै पढ्नुहोस्

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

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

वर्गीकरण गर्न नसकिने उत्तरको अर्थ निर्धारण गर्नुहोस्

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

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

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

निर्णय प्रमाणित गर्नुहोस्, छापिएको लाइन होइन

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

त्यसपछि तीही केसहरू वास्तविक ग्राहकमार्फत गैर-उत्पादन सुन्नेसँग चलाउनुहोस् र सर्भरले के दर्ता गर्यो पुष्टि गर्नुहोस्: स्वीकृत, अस्वीकृत वा स्थगित। निष्क्रिय खाता, गलत पासवर्ड, विकृत प्रमाणितकर्ता प्रतिक्रिया, समयसीमा र अप्राप्य प्रमाणितकर्ता समेट्नुहोस्। कुनै केस तपाईंले नाम दिन नसक्ने स्थितिमा पर्यो भने एडाप्टर पूरा भएको छैन।

प्रमाणितकर्ताको नतिजादेखि एग्जिट स्थितिसम्मको म्यापिङ रिपोजिटरीमा स्क्रिप्टको छेउमा राख्नुहोस्, ताकि अर्को इन्जिनियरले कोडको उल्टो इन्जिनियरिङ नगरी सम्झौता पढ्न सकोस्।