ठूलो OpenVPN कुञ्जीले रिकी टाइमर किन हटाउँदैन

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

साइफर छुनुअघि रिकी सेटिङ पढ्नुहोस्, र त्यसो गर्दा दुवै पक्ष पढ्नुहोस्।

कुञ्जीको बल र कुञ्जीको आयुले फरक प्रश्नको उत्तर दिन्छन्

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

परिनियोजन टिप्पणीमा दुवै लेख्नुहोस्: डेटा च्यानललाई केले सुरक्षित राख्छ र त्यसका कुञ्जीको प्रतिस्थापन केले सुरु गर्छ।

रिकीसँग तीन ट्रिगर छन्, र कुनै पनि पक्षले ती चलाउन सक्छ

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

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

रिकीले प्रमाणीकरण प्रवाह उदाङ्ग पार्छ

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

यसलाई अपरेटरसँग समाधान गर्नुपर्ने कार्यप्रवाह समस्या मान्नुहोस्, नवीकरण बन्द गर्नुपर्छ भन्ने प्रमाण होइन।

नवीकरण भारमुनि परीक्षण गर्नुहोस्, एक मिनेटको सत्रमा होइन

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

सफल ठूलो स्थानान्तरणलाई क्रिप्टोग्राफिक सीमाको प्रमाणका रूपमा नपढ्नुहोस्। यसले बाटो र गणकहरूले त्यति ट्राफिक सहन सकेको मात्र देखाउँछ।

दुवै छनोट अभिलेख गर्नुहोस्

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

यदि अनुकूलताले अपवाद जबरजस्ती गर्छ भने, त्यसलाई एक संस्करण र एक अन्त्य मितिमा सीमित गर्नुहोस्। आफ्नै कारणभन्दा लामो बाँच्ने अपवाद नै त्यो नीति बन्छ जुन कसैले छानेको सम्झँदैन।