OpenVPN ची auth-user-pass-verify स्क्रिप्ट: एग्झिट कोड योग्य ठेवा

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

करार छोटा आहे: सबमिट केलेले खाते ओळखा, मंजूर पडताळणीकर्त्याला इच्छित प्रश्न विचारा आणि त्या विनंतीसाठी फक्त त्या पडताळणीकर्त्याचा दस्तऐवजीकृत सकारात्मक निकाल स्वीकारा। बाकी सर्व पायाभूत सुविधा आहे।

हुक परत देऊ शकतो अशा तीन स्थिती

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

HTTP यश आणि प्रमाणीकरण यश वेगवेगळे स्तर आहेत, आणि त्यांना एकत्र करणे हे हुक चुकण्याचे सर्वात सामान्य कारण आहे। 202 प्रतिसादाचा अर्थ विनंती प्रक्रियेसाठी स्वीकारली गेली, पासवर्ड सत्यापित झाला असा नाही। अपेक्षित स्थिती, प्रतिसादाचा आकार आणि अंतिम निर्णय तुम्हाला दिलेल्या API करारातून ठरवा, आणि विश्वासार्ह वाटते म्हणून फील्डचे नाव तयार करू नका।

उत्तर खरोखर नंतर आले, तर तो स्थगित मार्ग आहे आणि तसाच बांधला पाहिजे। कधीही पूर्ण न होणारा स्थगित प्रयत्न वेळेची मर्यादा संपेपर्यंत संसाधने धरून ठेवतो।

क्रेडेन्शियल फाइल जशी लिहिली आहे तशीच वाचा

दस्तऐवजीकृत फाइल-द्वारे पद्धतीत, सर्व्हर वापरकर्तानाव आणि पासवर्ड तात्पुरत्या फाइलच्या पहिल्या दोन ओळी म्हणून लिहितो, तो मार्ग स्क्रिप्टला देतो आणि स्क्रिप्ट परत आल्यावर फाइल काढून टाकतो। त्या दोन ओळी डेटा म्हणून वाचा: फाइल कधीही source करू नका, तिचे मूल्यांकन कधीही करू नका, आणि तिचा मजकूर प्रोसेस टेबल पाहू शकेल अशा कमांड लाइनमध्ये कधीही चिकटवू नका। पासवर्ड बाइटनुबाइट जतन करा, कारण वापरकर्तानावाप्रमाणे त्याचे सामान्यीकरण केल्यास क्रेडेन्शियल निःशब्दपणे बदलते। त्या तात्पुरत्या फाइलची डिरेक्टरी हा तैनातीचा निर्णय आहे, म्हणून ती अस्तित्वात आहे आणि होस्टवरील सर्वांसाठी वाचनीय नाही याची खात्री करा।

पडताळणीकर्त्याचे स्वतःचे क्रेडेन्शियल वापरकर्त्याच्यापासून वेगळे ठेवा: ते गेटवे एकत्रीकरणाचे आहे, प्लॅटफॉर्मच्या सीक्रेट स्टोअरमध्ये राहते आणि फक्त पडताळणीची परवानगी लागते, म्हणून ते कोणी विशिष्ट व्यक्ती प्रमाणित झाली याचा पुरावा नाही। हुकला दुसरा पासवर्ड पडताळणीकर्ता बनूही देऊ नका। हॅश तुलना हाताने पुन्हा लिहिणे लूप ऑप्टिमाइझ केल्याने सुरक्षित होत नाही, आणि देखभाल केलेला पडताळणीकर्ता खाते साठ्याची मीठ घातलेली आणि खर्चिक योजना आधीच समजतो।

वर्गीकृत करता न येणाऱ्या उत्तराचा अर्थ ठरवा

वेळेच्या मर्यादा, वाहतूक त्रुटी, विकृत प्रतिसाद आणि अनुपलब्ध बॅकएंड एक गुणधर्म सामायिक करतात: त्यापैकी कोणतेही सकारात्मक पडताळणी नाही। हुकने त्यापैकी प्रत्येकासाठी बंद होऊन अपयशी व्हावे आणि ऑपरेटर कारवाई करू शकेल असे कारण नोंदवावे। ते कारण संरक्षित लॉगमध्ये असावे, जोडणी करण्याचा प्रयत्न करणाऱ्या व्यक्तीला परत दिलेल्या संदेशात नाही।

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

सर्व्हर कॉन्फिगरेशनही इथे महत्त्वाचे आहे: वापरकर्ता-परिभाषित स्क्रिप्ट केवळ तेव्हाच मानल्या जातात जेव्हा चालू कॉन्फिगरेशन आवश्यक सुरक्षा स्तरावर त्यांना परवानगी देते, आणि ते सेटिंग वाढवायचे डीफॉल्ट नसून जाणीवपूर्वक केलेली निवड आहे।

निर्णय तपासा, छापलेली ओळ नाही

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

नंतर तीच प्रकरणे खऱ्या क्लायंटद्वारे उत्पादनेतर ऐकणाऱ्याविरुद्ध चालवा आणि सर्व्हरने काय नोंदवले याची खात्री करा: स्वीकृत, नाकारले किंवा स्थगित। निष्क्रिय खाते, चुकीचा पासवर्ड, विकृत पडताळणीकर्ता प्रतिसाद, वेळेची मर्यादा आणि अप्राप्य पडताळणीकर्ता यांचा समावेश करा। कोणतेही प्रकरण तुम्ही नाव देऊ शकत नाही अशा स्थितीत पडल्यास, अडाप्टर पूर्ण झालेला नाही।

पडताळणीकर्त्याच्या निकालापासून एग्झिट स्थितीपर्यंतचे मॅपिंग रिपॉझिटरीमध्ये स्क्रिप्टच्या शेजारी ठेवा, जेणेकरून पुढील अभियंता कोडचे उलटे अभियांत्रिकी न करता करार वाचू शकेल।