OpenVPN हुक घटनाहरू: नाम र समयछाप किन कुञ्जी होइनन्

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

डिस्कनेक्ट चरहरूको वास्तविक अर्थबाट सुरु गर्नुहोस्। तब मात्र पहिचानकर्ताको छनोट अर्थपूर्ण हुन्छ।

डिस्कनेक्ट हुकले वास्तवमा के बोक्छ

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

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

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

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

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

स्थिर पहिचान कहाँबाट आउँछ

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

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

अवकाशलाई सशर्त र इडेम्पोटेन्ट बनाउनुहोस्

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

व्यवस्थापन इन्टरफेसले एक पटकमा एउटा मात्र जोडिएको व्यवस्थापन क्लाइन्ट स्वीकार गर्छ, त्यसैले त्यही सकेटका लागि प्रतिस्पर्धा गर्ने दोस्रो पर्यवेक्षक जोड्नुभन्दा पहिले नै यसको मालिक भएको पक्षसँग एकीकृत हुनुहोस्।

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

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