OpenVPN हुक इव्हेंट: नाव आणि वेळेची छाप ही किल्ली का नाही

त्याच नावाखाली दुसरे कनेक्शन सुरू झाल्यानंतर डिस्कनेक्ट रेकॉर्ड येतो, आणि त्या वापरकर्त्याची नवीनतम ओळ अद्ययावत करणारा हँडलर चुकीचे सत्र बंद करतो। चूक वेळेच्या छापांच्या तुलनेत नाही। चूक ह्या गृहीतकात आहे की नाव आणि एक पूर्ण सेकंद मिळून एक सत्र ओळखतात। हुक इव्हेंट कनेक्शनांचे वर्णन करतात, आणि कनेक्शनला अशी किल्ली हवी जी फक्त त्याचीच असेल।

डिस्कनेक्ट चलांचा प्रत्यक्ष अर्थ काय आहे यापासून सुरुवात करा। तेव्हाच ओळखकर्त्याची निवड अर्थपूर्ण होते।

डिस्कनेक्ट हुक प्रत्यक्षात काय वाहतो

Community OpenVPN 2.6 मध्ये, हुक संदर्भ time_unix ला क्लायंट जोडला गेल्याचा क्षण म्हणून परिभाषित करतो; तो कनेक्ट हुक चालण्यापूर्वी सेट केला जातो आणि नंतर डिस्कनेक्ट हुक सक्रिय झाल्यावर पुन्हा परिभाषित केला जात नाही। time_duration त्या सत्राची लांबी सेकंदांमध्ये देतो, त्यामुळे शेवट अंदाजे कनेक्शनची वेळ आणि कालावधी यांची बेरीज असतो। दोन्ही पूर्ण सेकंद आहेत, आणि दोन्हीपैकी कोणताही तुमच्या डेटाबेसने इव्हेंट प्रक्रिया केलेला क्षण नाही। हे तीन वेळा वेगळे ठेवणेच सहसंबंध केवळ चाचणीत बरोबर दिसण्याऐवजी प्रत्यक्षात टिकून राहू देतो।

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

स्पष्ट जोडी एकमेव का नाही

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

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

स्थिर ओळख कुठून येते

व्यवस्थापन इंटरफेस प्रत्येक क्लायंटला क्लायंट-उदाहरण ओळखकर्ता देतो, आणि तो ओळखकर्ता तो जारी करणाऱ्या डीमन उदाहरणापुरता मर्यादित असतो। वापरण्यायोग्य बाह्य किल्ली स्थिर सर्व्हर ओळखकर्ता, डीमन सुरू झाल्यावर बदलणारा युग आणि तो क्लायंट ID एकत्र करते। युग महत्त्वाचे आहे कारण ओळखकर्ते प्रक्रियेसोबत पुन्हा सुरू होतात, आणि उघडा प्रक्रिया ID नंतर असंबंधित गोष्टीकडून पुनर्वापरला जाऊ शकतो।

चाइल्ड कनेक्ट स्क्रिप्टमध्ये सेट केलेले पर्यावरण चल पालक डीमनच्या नंतरच्या डिस्कनेक्ट स्क्रिप्टपर्यंत जात नाहीत, कारण त्या स्क्रिप्ट स्वतःच्या पर्यावरणांसह वेगळ्या प्रक्रिया म्हणून चालतात। म्हणून कनेक्शनच्या वेळी UUID तयार करणे अर्धाच उपाय आहे। डिस्कनेक्ट बाजूने तोच UUID नाव देता आला पाहिजे, म्हणजे ओळख अशा ठिकाणी राहिली पाहिजे जिथे दोन्ही घटना पोहोचू शकतील।

निवृत्ती अटींची आणि इडेम्पोटेंट करा

सत्राच्या मालकानुसार निवृत्त करा, वापरकर्त्यानुसार नाही। जो हँडलर नावाशी सध्या जोडलेले कोणतेही वाटप हटवतो तो शेवटी चुकीचेच हटवेल, आणि एकमेव संरक्षण म्हणजे काढले जाणारे रेकॉर्ड हे या घटनेने वर्णन केलेले रेकॉर्ड आहे का हे तपासणे।

व्यवस्थापन इंटरफेस एका वेळी एकच जोडलेला व्यवस्थापन क्लायंट स्वीकारतो, म्हणून त्याच सॉकेटसाठी स्पर्धा करणारा दुसरा निरीक्षक जोडण्याऐवजी आधीच त्याचा मालक असलेल्यासोबत एकत्रित व्हा।

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

अवघड प्रकरणे जाणीवपूर्वक तपासा: एका सेकंदात दोन पुनर्जोडणी, दोन डीमन उदाहरणे, ज्याची प्रक्रिया अयशस्वी झाली असे कनेक्शन, आणि सत्राच्या मध्ये डीमन पुन्हा सुरू होणे। चारही टिकून राहणारी किल्लीच विश्वासार्ह किल्ली आहे।