दुई पियरबीचको OpenVPN लिङ्कका लागि स्थिर कुञ्जी कि TLS?

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

स्थिर-कुञ्जी मोडले के गर्न सक्दैन

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

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

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

लिङ्क पुनः डिजाइन नगरी TLS मा जाने

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

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

सुरक्षा बदलिँदा नेटवर्क सम्झौता अपरिवर्तित राख्नुहोस्। तीही सुरुङ ठेगाना, मार्ग र अनुमत सेवाहरू पहिले र पछि लागू हुनुपर्छ, ताकि स्थानान्तरणका क्रममा हुने असफलता छद्म राउटिङ आश्चर्य नभई सुरक्षा समस्या होस्। परिवर्तनअघि ठेगाना र मार्ग लेख्नुहोस्; पछि तिनको तुलना गर्नु स्मृतिबाट पुनः बनाउनुभन्दा छिटो हुन्छ।

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

कसले के नवीकरण गर्छ, र कहिले

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

त्यसैले एउटै कन्फिगरेसन फाइलबाट दोहोरिने पुनर्वार्ताको निदान भ्रामक हुन्छ। दुवै पियरको सेटिङ पढ्नुहोस्, त्यसपछि खराबी मान्नुभन्दा लगमा हुने संक्रमण हेर्नुहोस्। सफा रूपमा पूरा हुने नवीकरण नियन्त्रण च्यानल ट्राफिकको छोटो विस्फोटजस्तो देखिन्छ, विच्छेदजस्तो होइन।

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

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

परिवर्तन स्वीकार गर्ने

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

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

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