बड़ी OpenVPN कुंजी रीकी टाइमर को क्यों नहीं हटाती

AES-256 या लंबी कुंजी चुनना इस बारे में कुछ नहीं कहता कि उस कुंजी का कितने समय तक उपयोग किया जा सकता है। कुंजी की ताकत एल्गोरिदम का वर्णन करती है; रीकी नीति तय करती है कि सत्र कब नई कुंजी सामग्री प्राप्त करेगा। कोई परिनियोजन सबसे मज़बूत उपलब्ध साइफ़र चुन सकता है और फिर भी नवीनीकरण में गलत हो सकता है, क्योंकि दोनों फैसले अलग-अलग जगह लिए जाते हैं। इन्हें मिलाने से या तो अनावश्यक साइफ़र परिवर्तन होता है या ऐसा सत्र बनता है जो चुपचाप अपनी नीति से अधिक जीता है।

साइफ़र को छूने से पहले रीकी सेटिंग पढ़ें, और ऐसा करते समय दोनों पक्ष पढ़ें।

कुंजी की ताकत और कुंजी का जीवनकाल अलग सवालों के जवाब देते हैं

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

परिनियोजन नोट में दोनों लिखें: डेटा चैनल की रक्षा क्या करता है, और उसकी कुंजियों का प्रतिस्थापन क्या शुरू करता है।

रीकी के तीन ट्रिगर हैं, और कोई भी पक्ष उन्हें चला सकता है

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

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

रीकी प्रमाणीकरण प्रवाह को उजागर करती है

फिर से बातचीत एक नया TLS हैंडशेक है, यानी प्रमाणीकरण का रास्ता दोबारा चलता है। एक बार वाले कोड, हार्डवेयर टोकन या RADIUS चुनौती उपयोग करने वाले परिनियोजन यह मुश्किल तरीके से जानते हैं: पहला कनेक्शन काम करता है और एक घंटे बाद सत्र मर जाता है, जब दूसरा हैंडशेक पहले ही इस्तेमाल हो चुका कोड माँगता है। auth-gen-token इस अंतर को पाटने के लिए मौजूद है, ताकि सर्वर नया इंटरैक्टिव लॉगिन माँगने के बजाय फिर से बातचीत के लिए थोड़े समय का टोकन जारी कर सके।

इसे ऑपरेटर के साथ सुलझाने वाली वर्कफ़्लो समस्या मानें, नवीनीकरण बंद किया जाना चाहिए इसका सबूत नहीं।

नवीनीकरण को भार के नीचे जाँचें, एक मिनट के सत्र में नहीं

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

सफल बड़े स्थानांतरण को क्रिप्टोग्राफ़िक सीमा का सबूत न पढ़ें। वह केवल दिखाता है कि रास्ते और गणकों ने इतना ट्रैफ़िक झेला।

दोनों चुनाव दर्ज करें

रिकॉर्ड को दो पंक्तियाँ चाहिए: पैकेट कैसे सुरक्षित होते हैं, और वह सुरक्षा कब बदली जाती है। हर मान के लिए अधिकार जोड़ें, क्योंकि साइफ़र वितरण के डिफ़ॉल्ट से आ सकता है जबकि टाइमर आंतरिक नीति से आता है। भविष्य के ऑपरेटर को कॉन्फ़िग फ़ाइल से दोनों में से कोई भी अनुमान नहीं लगाना पड़े।

अगर संगतता अपवाद थोपती है, तो उसे एक संस्करण और एक अंतिम तिथि तक सीमित करें। जो अपवाद अपने कारण से अधिक जीता है, वही वह नीति बन जाता है जिसे किसी को याद नहीं कि उसने चुना था।