OpenVPN हुक घटनाएँ: नाम और समय-चिह्न कोई कुंजी क्यों नहीं हैं

एक ही नाम के तहत दूसरा कनेक्शन शुरू हो जाने के बाद डिस्कनेक्ट रिकॉर्ड आता है, और उस उपयोगकर्ता की नवीनतम पंक्ति अपडेट करने वाला हैंडलर गलत सत्र बंद कर देता है। गलती समय-चिह्न की तुलना में नहीं है। गलती इस मान्यता में है कि एक नाम और एक पूरा सेकंड मिलकर एक सत्र की पहचान करते हैं। हुक घटनाएँ कनेक्शनों का वर्णन करती हैं, और एक कनेक्शन को ऐसी कुंजी चाहिए जो केवल उसी की हो।

डिस्कनेक्ट चर का वास्तव में क्या अर्थ है, इससे शुरू करें। तभी पहचानकर्ता का चयन अर्थपूर्ण होता है।

डिस्कनेक्ट हुक वास्तव में क्या ले जाता है

Community OpenVPN 2.6 में, हुक संदर्भ time_unix को उस क्षण के रूप में परिभाषित करता है जब क्लाइंट जुड़ा; यह कनेक्ट हुक चलने से पहले सेट होता है, और बाद में डिस्कनेक्ट हुक सक्रिय होने पर इसे फिर से परिभाषित नहीं किया जाता। time_duration उस सत्र की लंबाई सेकंडों में देता है, इसलिए अंत लगभग कनेक्शन का समय और अवधि का योग है। दोनों पूरे सेकंड हैं, और इनमें से कोई भी वह क्षण नहीं है जब आपके डेटाबेस ने घटना को संसाधित किया। इन तीन समयों को अलग रखना ही किसी सहसंबंध को टिकने देता है, केवल परीक्षण के दौरान सही दिखने देता नहीं।

यह गणित लिखे जाने योग्य है, क्योंकि यही वह अंतिम समय है जो हुक स्वयं प्रदान करता है। प्रसंस्करण विलंब और मेज़बानों के बीच घड़ी के अंतर अभी भी इससे बाहर हैं।

स्पष्ट जोड़ी अद्वितीय क्यों नहीं है

नाम को कनेक्शन के समय के साथ जोड़ना खोज को सीमित करता है और फिर भी सत्र की पहचान नहीं करता। एक क्लाइंट उसी सेकंड के भीतर फिर से जुड़ सकता है, इसलिए दो सत्र दोनों मान साझा कर सकते हैं। दो डेमन इंस्टेंस, या वही कॉन्फ़िगरेशन रखने वाला सर्वर प्रतिस्थापन, उस जोड़ी को अलग-अलग प्रक्रियाओं से बना सकते हैं। टनल पते भी इसी कारण पुनःचक्रित होते हैं, जिससे वे किसी सत्र के गुण बन जाते हैं, उसके पहचानकर्ता नहीं।

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

स्थिर पहचान कहाँ से आती है

प्रबंधन इंटरफ़ेस हर क्लाइंट को क्लाइंट-इंस्टेंस पहचानकर्ता देता है, और वह पहचानकर्ता उस डेमन इंस्टेंस तक सीमित है जिसने उसे जारी किया। एक व्यावहारिक बाहरी कुंजी एक स्थिर सर्वर पहचानकर्ता, डेमन शुरू होने पर बदलने वाला युग, और वह क्लाइंट ID जोड़ती है। युग इसलिए महत्वपूर्ण है क्योंकि पहचानकर्ता प्रक्रिया के साथ फिर से शुरू होते हैं, और एक नंगा प्रक्रिया ID बाद में किसी असंबंधित चीज़ द्वारा पुनः उपयोग किया जा सकता है।

चाइल्ड कनेक्ट स्क्रिप्ट के भीतर सेट किए गए पर्यावरण चर मूल डेमन की बाद की डिस्कनेक्ट स्क्रिप्ट तक नहीं जाते, क्योंकि वे स्क्रिप्ट अपने स्वयं के परिवेशों वाली अलग प्रक्रियाओं के रूप में चलती हैं। इसलिए कनेक्शन के समय UUID उत्पन्न करना आधा समाधान है। डिस्कनेक्ट पक्ष को वही UUID नाम देने में सक्षम होना चाहिए, जिसका अर्थ है कि पहचान को ऐसी जगह रहना चाहिए जहाँ दोनों घटनाएँ पहुँच सकें।

सेवानिवृत्ति को सशर्त और इडेम्पोटेंट बनाएं

सत्र स्वामी के अनुसार सेवानिवृत्त करें, उपयोगकर्ता के अनुसार नहीं। जो हैंडलर किसी नाम से वर्तमान में जुड़ा कोई भी आवंटन हटा देता है वह अंततः गलत को हटा देगा, और एकमात्र बचाव यह जाँचना है कि हटाया जा रहा रिकॉर्ड वही रिकॉर्ड है जिसका यह घटना वर्णन करती है।

प्रबंधन इंटरफ़ेस एक बार में केवल एक जुड़ा प्रबंधन क्लाइंट स्वीकार करता है, इसलिए उसी सॉकेट के लिए प्रतिस्पर्धा करने वाला दूसरा पर्यवेक्षक जोड़ने के बजाय उसके साथ एकीकृत हों जो पहले से इसका स्वामी है।

दोहराई गई घटनाओं को परिणाम दो बार बदले बिना संभालें, और बिना जोड़ी वाली घटनाओं को फेंकने के बजाय मेल-मिलाप के लिए रखें। डिस्कनेक्ट कॉलबैक में प्रलेखित जीवनचक्र शर्तें हैं और क्रैश या कठोर रोक के बाद वह कभी नहीं भी आ सकता है, इसलिए डिज़ाइन को ऐसा सत्र दर्शाने का तरीका चाहिए जिसकी अंतिम घटना अनुपस्थित है।

मुश्किल मामलों को जानबूझकर परखें: एक सेकंड के भीतर दो पुनःकनेक्शन, दो डेमन इंस्टेंस, वह कनेक्शन जिसका प्रसंस्करण विफल रहा, और सत्र के बीच में डेमन का पुनःआरंभ। जो कुंजी चारों को झेल ले वही भरोसे के योग्य कुंजी है।