पहला सत्र जीतता है: निष्कासन से पहले OpenVPN लॉगिन को नियंत्रित करना
बाद के लॉगिन को अस्वीकार करना पुराने को बदलने के समान नहीं है। निर्णय उसी नाम के निष्कासन से पहले लेना होगा, और स्लॉट जाँच परमाणु होनी चाहिए।
प्रति खाता एक सत्र की अनुमति देने वाली नीति दूसरे लॉगिन के आने तक तय लगती है। दो परिणाम संभव हैं: नया आने वाला मौजूदा सत्र को बदल देता है, या मौजूदा सत्र स्लॉट रखता है और नए को अस्वीकार कर दिया जाता है। केवल दूसरा ही पहला सत्र जीतता है नीति है। जिस क्लाइंट विकल्प की ओर अधिकांश लोग जाते हैं वह समवर्तिता सक्षम करता है और इसलिए यह परिणाम नहीं देता।
एक सेटिंग के पीछे दो अनुबंध छिपे हैं
समवर्तिता बंद होने पर, वही प्रमाणपत्र नाम लेकर आने वाला दूसरा कनेक्शन पहले से चल रहे सत्र को विस्थापित कर सकता है। समवर्तिता चालू करने से एक साथ कई सत्रों की अनुमति मिलती है, जो सीमा के विपरीत है। दोनों में से कोई भी स्थिति अस्वीकृति नीति नहीं है, इसलिए निर्णय कहीं और लेना होगा।
कुछ भी लागू करने से पहले अनुबंध लिख लें: किसे अस्वीकार किया जाता है, कौन सा साक्ष्य मौजूदा सत्र की पहचान करता है, और जब कोई सत्र स्वच्छ डिस्कनेक्ट के बिना मरता है तो क्या होता है। जिस नीति को किसी ने इस तरह नहीं कहा, उसका बाद में परीक्षण नहीं हो सकता।
निष्कासन आपके कनेक्ट हुक से पहले होता है
2.6 सर्वर कोड पथ में, नए क्लाइंट की शुरुआती तैयारी समवर्तिता बंद होने पर उसी नाम के मौजूदा इंस्टेंस हटा देती है। वह हटाना कनेक्ट हैंडलर श्रृंखला चलने से पहले होता है। इसलिए डुप्लिकेट देखकर विफलता लौटाने वाली स्क्रिप्ट नए को तब अस्वीकार करती है जब मौजूदा सत्र पहले ही गिराया जा चुका होता है - ठीक वही परिणाम जिसे नीति रोकना चाहती थी। upstream कार्यान्वयन में कॉलबैक का क्रम ही आपके बिल्ड के लिए एकमात्र भरोसेमंद उत्तर है।
| Stage | Who can still refuse | Effect on the incumbent |
|---|---|---|
| Certificate check | Server trust configuration | None |
| Authentication decision | The authentication controller | None, because establishment has not run |
| Connect handler | A profile script | Already evicted in the same-name case |
| Post-establishment | Status tooling, monitoring | Both sessions already exist or one is gone |
स्टेटस फ़ाइल को पोल करना भी द्वार नहीं है। एक साथ आने वाले दो प्रयास दोनों खाली स्लॉट देख सकते हैं, इससे पहले कि कोई उसे पक्का करे, और दोनों आगे बढ़ जाते हैं।
निर्णय को प्रमाणीकरण में ले जाएँ
प्रमाणपत्र सत्यापित होने के बाद प्रबंधन इंटरफ़ेस प्रमाणीकरण का निर्णय ले सकता है। उस व्यवस्था में नियंत्रक पर्यवेक्षक नहीं है: वह हर जुड़ने वाले क्लाइंट इंस्टेंस को प्राप्त करता है और उत्तर देता है कि वह इंस्टेंस आगे बढ़ सकता है या नहीं। चूँकि उत्तर स्थापना से पहले आता है, अस्वीकृति मौजूदा सत्र को अछूता छोड़ देती है। वही चैनल डिस्कनेक्ट की सूचना देता है, और इस तरह नियंत्रक जानता है कि स्लॉट वैध रूप से छोड़ा गया।
हर नए इंस्टेंस को उस द्वार से गुज़रना होगा, जिसमें पुनः कनेक्शन और बिना संकेत के फिर से प्रमाणीकरण करने वाला कोई भी मार्ग शामिल है। जिस द्वार तक कुछ इंस्टेंस कभी नहीं पहुँचते वह कुछ नहीं बचाता, और यह चूक तब तक अदृश्य रहती है जब तक कोई बाईपास आज़माए नहीं।
टोकन द्वार के पास से निकल सकते हैं
टोकन जारी होने के बाद, सर्वर उसे आंतरिक रूप से मान्य कर सकता है और उस कनेक्शन के लिए बाहरी प्रमाणीकरण छोड़ सकता है. प्रबंधन कॉल कभी नहीं होता, इसलिए केवल वहीं लागू स्लॉट जाँच नए इंस्टेंस को कभी नहीं देखती। यह व्यवहार उपयोगकर्ताओं के लिए सुविधा और समवर्तिता नीति के लिए छेद है। टोकन-प्रमाणित कनेक्शनों को समतुल्य आधिकारिक जाँच से गुज़रने दें, या जब नीति हर कनेक्शन पर निर्णय मांगे तो टोकन मार्ग बंद करें।
हर टोकन को बिना शर्त स्वीकार करके इसकी भरपाई न करें। समाप्त या अमान्य टोकन को फिर भी विफल होना है, और उसे बाकी सब की तरह उसी निर्णय-बिंदु से विफल होना है।
आरक्षण को इंस्टेंस से बाँधें, पते से नहीं
पता कमज़ोर पहचान है: उसी लैपटॉप से पुनः कनेक्शन किसी दूसरे पते से आ सकता है, और नकल किया गया क्रेडेंशियल उसी पते से आ सकता है। आरक्षण को सर्वर द्वारा सौंपे गए क्लाइंट इंस्टेंस से बाँधें, ताकि पहले से स्वीकृत इंस्टेंस का पुनः प्रमाणीकरण स्वामी के रूप में पहचाना जाए। नई इंस्टेंस पहचानकर्ता को वही टोकन प्रस्तुत करने पर भी पहला जीतता है निर्णय से अपना स्लॉट लेना है।
केवल विफल प्रयास का आरक्षण छोड़ें। पुराने प्रयास से देर से आया डिस्कनेक्ट ईवेंट नए स्वामी का स्लॉट नहीं साफ़ कर सकता, इसलिए जारी करना खाते के बजाय इंस्टेंस का नाम लेता है। नियंत्रक के पुनरारंभ के बाद किसी को स्वीकार करने से पहले सक्रिय सत्रों का मिलान करें, और खाते की सेवा करने वाले हर गेटवे पर वही नियम लागू करें।
वास्तव में पुराने स्लॉट की वसूली कैसे होगी, यह अलग से तय करें। व्यवस्थापक को उसे साफ़ करने का प्रलेखित तरीका चाहिए, और वह मार्ग ऐसे उपयोगकर्ता के लिए उपलब्ध नहीं होना चाहिए जो केवल पुनः कनेक्ट क्लिक करता है।
महत्वपूर्ण जोड़ियों का परीक्षण करें: लगभग एक साथ दो लॉगिन, स्वच्छ विच्छेद के बाद पुनः कनेक्शन, मौजूदा सत्र का पुनः प्रमाणीकरण, अस्वीकृत नया आने वाला, और नियंत्रक का पुनरारंभ। हर मामले में मौजूदा सत्र उपयोगी रहना चाहिए और नए को अन्य खातों को नुकसान पहुँचाए बिना अस्वीकार किया जाना चाहिए।