पहिलो सत्र जित्छ: निष्कासन अघि OpenVPN लगइन नियन्त्रण गर्ने

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

एउटा सेटिङ पछाडि दुई सम्झौता लुकेका छन्

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

केही कार्यान्वयन गर्नु अघि सम्झौता लेख्नुहोस्: कसलाई अस्वीकार गरिन्छ, कुन प्रमाणले चालु सत्र पहिचान गर्छ, र सफा विच्छेदन बिना सत्र मरे के हुन्छ। कसैले यसरी नभनेको नीति पछि परीक्षण गर्न सकिँदैन।

निष्कासन तपाईंको जडान हुक अघि हुन्छ

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

स्टेटस फाइल पोल गर्नु पनि ढोका होइन। सँगै आउने दुई प्रयासले कुनैले पनि पक्का गर्नु अघि खाली स्लट देख्न सक्छन्, र दुवै अगाडि बढ्छन्।

निर्णय प्रमाणीकरणमा सार्नुहोस्

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

प्रत्येक नयाँ उदाहरणले यो ढोका पार गर्नुपर्छ, पुनःजडान र सूचना बिना पुनः प्रमाणीकरण गर्ने कुनै पनि मार्ग सहित। केही उदाहरण कहिल्यै नपुग्ने ढोकाले केही रक्षा गर्दैन, र कोहीले बाइपास प्रयास नगरेसम्म यो छुट अदृश्य रहन्छ।

टोकनहरू ढोकाको छेउबाट जान सक्छन्

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

प्रत्येक टोकन बिनासर्त स्वीकार गरेर यसको क्षतिपूर्ति नगर्नुहोस्। म्याद सकिएको वा अवैध टोकन अझै असफल हुनुपर्छ, र अरू सबै जस्तै त्यही निर्णय बिन्दुबाट असफल हुनुपर्छ।

आरक्षणलाई उदाहरणसँग बाँध्नुहोस्, ठेगानासँग होइन

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

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

साँच्चै पुरानो स्लट कसरी पुनःप्राप्त हुन्छ भन्ने अलगै निर्णय गर्नुहोस्। प्रशासकलाई त्यो सफा गर्ने कागजातीय तरिका चाहिन्छ, र त्यो मार्ग पुनः जडान क्लिक गर्ने प्रयोगकर्ताका लागि पहुँचयोग्य हुनु हुँदैन।

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