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

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

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

वे तीन स्थितियाँ जो हुक लौटा सकता है

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

HTTP सफलता और प्रमाणीकरण सफलता अलग परतें हैं, और इन्हें मिलाना इस हुक के गलत होने का सबसे सामान्य तरीका है। 202 प्रतिक्रिया का अर्थ है कि अनुरोध प्रसंस्करण के लिए स्वीकार हुआ, यह नहीं कि पासवर्ड सत्यापित हुआ। अपेक्षित स्थिति, प्रतिक्रिया का आकार और अंतिम निर्णय आपको दिए गए API अनुबंध से तय करें, और विश्वसनीय लगने के कारण किसी फ़ील्ड का नाम न गढ़ें।

यदि उत्तर वास्तव में बाद में आता है, तो वही विलंबित मार्ग है और उसे उसी तरह बनाना होगा। जो विलंबित प्रयास कभी पूरा नहीं होता, वह समय-सीमा समाप्त होने तक संसाधन रोके रखता है।

क्रेडेंशियल फ़ाइल को ठीक वैसे ही पढ़ें जैसे वह लिखी है

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

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

तय करें कि अवर्गीकरणीय उत्तर का क्या अर्थ है

समय-सीमाएँ, परिवहन त्रुटियाँ, विकृत प्रतिक्रियाएँ और अनुपलब्ध बैकएंड एक गुण साझा करते हैं: इनमें से कोई भी सकारात्मक सत्यापन नहीं है। हुक को इनमें से हर एक के लिए बंद होकर विफल होना चाहिए और ऐसा कारण दर्ज करना चाहिए जिस पर ऑपरेटर कार्रवाई कर सके। वह कारण संरक्षित लॉग में होना चाहिए, जुड़ने का प्रयास कर रहे व्यक्ति को लौटाए गए संदेश में नहीं।

उन मार्गों के प्रति भी उतने ही सतर्क रहें जो सत्यापनकर्ता तक बिलकुल नहीं पहुँचते। गुम कॉन्फ़िगरेशन मान, अपठनीय सीक्रेट या स्थापित न की गई निर्भरता को आकस्मिक स्वीकृति के बजाय अलग ऑपरेशनल चिह्न के साथ अस्वीकृति पैदा करनी चाहिए। उन शाखाओं को प्रयोगशाला में निर्भरता हटाकर परखें, उनके बारे में सोचने के बजाय। जहाँ लॉग करने की विफलता एग्ज़िट स्थिति बदल सकती है, वहाँ लॉगिंग निर्णय का हिस्सा बन गई है और उसे हानिरहित बनाना होगा।

सर्वर कॉन्फ़िगरेशन यहाँ भी मायने रखता है: उपयोगकर्ता-परिभाषित स्क्रिप्ट का सम्मान तभी होता है जब चालू कॉन्फ़िगरेशन उन्हें आवश्यक सुरक्षा स्तर पर अनुमति देता है, और वह सेटिंग बढ़ाने वाली डिफ़ॉल्ट नहीं बल्कि जानबूझकर चुना गया विकल्प है।

निर्णय सत्यापित करें, छपी पंक्ति नहीं

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

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

सत्यापनकर्ता परिणाम से एग्ज़िट स्थिति तक का मैपिंग रिपॉज़िटरी में स्क्रिप्ट के बगल में रखें, ताकि अगला इंजीनियर कोड की उलटी इंजीनियरिंग किए बिना अनुबंध पढ़ सके।