OpenVPN data-ciphers ले डेटा च्यानलको साइफर कसरी छान्छ

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

दुई च्यानल, दुई कन्फिगरेसन

एउटा OpenVPN सत्रमा एउटा नियन्त्रण च्यानल र एउटा डेटा च्यानल हुन्छ। नियन्त्रण च्यानलले त्यो TLS हात मिलाउने प्रक्रिया चलाउँछ जसले साथीहरूलाई प्रमाणित गर्छ र कुञ्जीहरू तय गर्छ। डेटा च्यानलले तपाईंको ट्राफिक बोक्ने प्याकेटहरू इन्क्रिप्ट गर्छ।

data-ciphers ले दोस्रो कन्फिगर गर्छ। नियन्त्रण च्यानलका आफ्नै विकल्पहरू छन्, र प्रोफाइलको पहिचान जाँच तेस्रो, अलग कुरा हो। एउटामा गरिएको परिवर्तनले अर्कोलाई सुधार्दैन, त्यसैले प्रोफाइल सही देखिन सक्छ र फेरि पनि कुनै विशेष चरणमा असफल हुन सक्छ।

कन्फिगरेसन फाइल पढ्दा यी तीनलाई आ-आफ्नै बाकसमा राख्नुहोस्।

वार्तालाप लगबाट पढ्नुहोस्

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

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

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

छनोट वास्तवमा कसरी हुन्छ

सर्भरले हात मिलाउने क्रममा आफ्नो data-ciphers सूची क्लाइन्टतर्फ धकेल्छ, र क्लाइन्टले त्यो सूचीमा पहिलो प्रविष्टि छान्छ जसलाई उसले पनि समर्थन गर्छ। त्यसैले क्रम सर्भरको कन्फिगरेसनको हो, क्लाइन्टको होइन।

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

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

सूची अमूर्त अर्थमा शक्तिको क्रम होइन। यो उम्मेदवारहरूको समूह हो, र छानिएको प्रविष्टि सर्भरको क्रममा पहिलो पारस्परिक समर्थित प्रविष्टि हो। त्यसैले फरक देखिने दुई सूची एउटै साइफरमा सहमत हुन सक्छन्। त्यसैले नै एउटै देखिने दुई सूची पनि असफल हुन सक्छन्।

पुराना साथीहरूलाई जानाजान बनाइएको ब्याकअप चाहिन्छ

जो साथी बिल्कुलै वार्तालाप गर्न सक्दैन, किनकि ऊ संयन्त्रभन्दा पुरानो छ वा उसले त्यो बन्द गरेको छ, उसलाई कागजातमा लेखिएको अनुकूलता व्यवस्था चाहिन्छ। ब्याकअप विकल्प ठ्याक्कै त्यही अवस्थाका लागि छ र वार्तालापमा सहभागी नहुने साथीहरूलाई लागू हुन्छ।

यो सन्देश हराउन हरेक पुरानो साइफर सक्षम गर्नुजस्तै होइन। फराकिलो सूचीले हरेक साथीका लागि सत्र कमजोर बनाउँछ, केही बलियो कुरा तय गर्नेहरूसमेत।

असम्बन्धित एल्गोरिदम नाम सम्पादन गर्नुको साटो दुवै पक्ष समन्वय गर्नुहोस्। यदि सर्भर अपग्रेडले पुरानो विकल्प हटायो भने, सुधार संस्करण योजनामा पर्छ, क्लाइन्टमा हतारमा होइन।

प्रमाणीकरण अक्षुण्ण राख्नुहोस्

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

तय भएको डेटा साइफर, क्लाइन्ट संस्करण र सर्भर संस्करण सँगै अभिलेख गर्नुहोस्, ताकि अर्को तुलना तथ्यबाट सुरु होस्, प्रोफाइल फाइलबाट होइन।

समर्थित सुधारपछि सुरुको जडान र पुनः वार्तालाप परीक्षण गर्नुहोस्, किनकि एकचोटि स्थापित सत्र कुञ्जी नवीकरणमा अझै असफल हुन सक्छ।

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