पहिले सत्र जिंकते: बाहेर काढण्यापूर्वी OpenVPN लॉगिन मर्यादित करणे

प्रति खाते एक सत्र परवानगी देणारे धोरण दुसरे लॉगिन येईपर्यंत निकाली काढलेले वाटते. दोन परिणाम शक्य आहेत: नवीन येणारा सध्याचे सत्र बदलतो, किंवा सध्याचे सत्र स्लॉट राखून ठेवते आणि नवीन नाकारला जातो. फक्त दुसराच पहिले सत्र जिंकते हे धोरण आहे. बहुतेक लोक ज्या क्लायंट पर्यायाकडे वळतात तो एकाचवेळीपणा सक्षम करतो आणि म्हणून हा परिणाम देत नाही.

एका सेटिंगमागे दोन करार लपलेले आहेत

एकाचवेळीपणा बंद असताना, त्याच प्रमाणपत्र नावाने येणारे दुसरे कनेक्शन आधीच चालू असलेले सत्र बाजूला सारू शकते. एकाचवेळीपणा सुरू केल्याने एकाच वेळी अनेक सत्रांना परवानगी मिळते, जी मर्यादेच्या उलट आहे. दोन्हीपैकी कोणतीही स्थिती नाकारण्याचे धोरण नाही, म्हणून निर्णय पूर्णपणे दुसरीकडे घ्यावा लागेल.

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

बाहेर काढणे तुमच्या कनेक्ट हुकपूर्वी होते

2.6 सर्व्हर कोड मार्गात, नवीन क्लायंटची सुरुवातीची तयारी एकाचवेळीपणा बंद असताना त्याच नावाच्या विद्यमान उदाहरणांची नोंदणी काढून टाकते. ती नोंदणी काढणे कनेक्ट हँडलरची शृंखला चालू होण्यापूर्वी होते. त्यामुळे नक्कल ओळखून अयशस्वीता परत करणारी स्क्रिप्ट सध्याचे सत्र आधीच खाली पाडल्यानंतर नवीनला नाकारते - धोरणाला जे प्रतिबंधित करायचे होते तोच परिणाम. Upstream अंमलबजावणीतील कॉलबॅकचा क्रम हेच तुमच्या बिल्डसाठी एकमेव विश्वासार्ह उत्तर आहे.

स्टेटस फाइल पोल करणेही द्वार नाही. एकत्र येणारे दोन प्रयत्न दोन्ही रिकामा स्लॉट पाहू शकतात, यापैकी कोणीही निश्चित करण्यापूर्वी, आणि दोन्ही पुढे जातात.

निर्णय प्रमाणीकरणात हलवा

प्रमाणपत्र तपासल्यानंतर व्यवस्थापन इंटरफेस प्रमाणीकरणाचा निर्णय घेऊ शकते. त्या रचनेत नियंत्रक निरीक्षक नाही: तो प्रत्येक जोडणारे क्लायंट उदाहरण घेतो आणि त्या उदाहरणाला पुढे जाता येईल का याचे उत्तर देतो. उत्तर स्थापनेपूर्वी येते, म्हणून नाकारणे सध्याचे सत्र अस्पर्शित ठेवते. तोच चॅनेल डिस्कनेक्टची माहिती देतो, आणि अशा प्रकारे नियंत्रकाला कळते की स्लॉट कायदेशीरपणे सोडला गेला.

प्रत्येक नवीन उदाहरणाला या द्वारातून जावे लागते, त्यात पुनर्जोडणी आणि सूचनेशिवाय पुन्हा प्रमाणीकरण करणारा कोणताही मार्ग समाविष्ट आहे. ज्या द्वारापर्यंत काही उदाहरणे कधीही पोहोचत नाहीत ते काहीही संरक्षित करत नाही, आणि कोणीतरी बायपास वापरून पाहेपर्यंत ही चूक अदृश्य राहते.

टोकन द्वाराच्या बाजूने जाऊ शकतात

टोकन जारी झाल्यानंतर, सर्व्हर ते अंतर्गतपणे वैध करू शकतो आणि त्या कनेक्शनसाठी बाह्य प्रमाणीकरण वगळू शकतो. व्यवस्थापन कॉल कधीही होत नाही, म्हणून फक्त तिथे राबवलेली स्लॉट तपासणी नवीन उदाहरण कधीही पाहत नाही. हे वर्तन वापरकर्त्यांसाठी सोय आणि एकाचवेळीपणाच्या धोरणासाठी भोक आहे. टोकन-प्रमाणित कनेक्शनना समतुल्य अधिकृत तपासणीतून जाऊ द्या, किंवा धोरणाने प्रत्येक कनेक्शनवर निर्णय मागितल्यास टोकन मार्ग बंद करा.

प्रत्येक टोकन विनाशर्त स्वीकारून याची भरपाई करू नका. कालबाह्य किंवा अवैध टोकनला तरीही अयशस्वी व्हावे लागते, आणि बाकी सर्वांप्रमाणे त्याच निर्णय-बिंदूतून अयशस्वी व्हावे लागते.

आरक्षण उदाहरणाशी बांधा, पत्त्याशी नाही

पत्ता ही कमकुवत ओळख आहे: त्याच लॅपटॉपवरून पुनर्जोडणी दुसऱ्या पत्त्यावरून येऊ शकते, आणि कॉपी केलेली ओळखपत्रे त्याच पत्त्यावरून येऊ शकतात. आरक्षण सर्व्हरने दिलेल्या क्लायंट उदाहरणाशी बांधा, जेणेकरून आधीच स्वीकारलेल्या उदाहरणाचे पुनर्प्रमाणीकरण मालक म्हणून ओळखले जाईल. नवीन उदाहरण ओळखकर्त्याला तेच टोकन सादर केल्यावरही पहिला जिंकतो या निर्णयातून स्वतःचा स्लॉट मिळवावा लागतो.

फक्त अयशस्वी प्रयत्नाचे आरक्षण सोडा. जुन्या प्रयत्नातील उशिरा आलेली डिस्कनेक्ट घटना नव्या मालकाचा स्लॉट पुसू नये, म्हणून सोडणे खात्याऐवजी उदाहरणाचे नाव घेते. नियंत्रक पुन्हा सुरू झाल्यावर कोणालाही स्वीकारण्यापूर्वी सक्रिय सत्रांची जुळवणी करा, आणि खात्याची सेवा करणाऱ्या प्रत्येक गेटवेवर तोच नियम लागू करा.

खरोखर जुना झालेला स्लॉट कसा पुनर्प्राप्त होईल हे वेगळे ठरवा. प्रशासकाला तो साफ करण्याचा दस्तऐवजी मार्ग हवा, आणि तो मार्ग फक्त पुन्हा जोडा वर क्लिक करणाऱ्या वापरकर्त्याला उपलब्ध नसावा.

महत्त्वाच्या जोड्या तपासा: जवळजवळ एकाच वेळी दोन लॉगिन, स्वच्छ खंडनंतर पुनर्जोडणी, सध्याच्या सत्राचे पुनर्प्रमाणीकरण, नाकारलेला नवीन येणारा आणि नियंत्रकाचा पुनःप्रारंभ. प्रत्येक बाबतीत सध्याचे सत्र वापरण्यायोग्य राहिले पाहिजे आणि नवीनला इतर खात्यांना हानी न पोहोचवता नाकारले पाहिजे.