OpenVPN data-ciphers डेटा चॅनेलचा सिफर कसा निवडतो

बोगदा वर येतो, लॉग एक सिफर दाखवतो आणि प्रोफाइलचा आढावा पुढे सरकतो। मग एका सहकाऱ्यावर अपग्रेड येते आणि तोच प्रोफाइल कोणताही सामायिक सिफर नाही अशा संदेशासह अयशस्वी होतो, ज्यामुळे लोक हटवायचे निर्देश शोधायला जातात। समजून घेण्यासारखी उपयुक्त गोष्ट म्हणजे data-ciphers बोलणीचे वर्णन करतो, सेटिंग नाही। एक बाजू यादी देते, दुसरी त्यातून निवडते, आणि निकाल एकच अल्गोरिदम असतो ज्याला दोन्ही आधार देतात। त्या देवाणघेवाणीचे वाचन एक ओळ बदलण्यापूर्वी यापैकी बहुतेक अपयशांचे स्पष्टीकरण देते।

दोन चॅनेल, दोन कॉन्फिगरेशन

एका OpenVPN सत्रात एक नियंत्रण चॅनेल आणि एक डेटा चॅनेल असते। नियंत्रण चॅनेल ते TLS हस्तांदोलन चालवते जे सहकाऱ्यांची प्रमाणिती करते आणि किल्ल्या ठरवते। डेटा चॅनेल तुमचा रहदारी वाहणारी पॅकेट्स कूटबद्ध करते।

data-ciphers दुसऱ्याला कॉन्फिगर करतो। नियंत्रण चॅनेलला स्वतःचे पर्याय असतात, आणि प्रोफाइलच्या ओळखीच्या तपासण्या तिसरी, वेगळी गोष्ट आहेत। एकातील बदल दुसरे दुरुस्त करत नाही, म्हणून प्रोफाइल बरोबर दिसू शकते आणि तरीही विशिष्ट टप्प्यावर अयशस्वी होऊ शकते।

कॉन्फिगरेशन फाइल वाचताना हे तीन स्वतःच्या खोक्यांत ठेवा।

बोलणी लॉगमधून वाचा

कनेक्शन यशस्वी झाल्यावर क्लायंट लॉग दोन्ही निकाल सांगतो। एक ओळ नियंत्रण चॅनेल आणि त्याच्या TLS तपशीलांचा अहवाल देते, आणि दुसरी निवडलेल्या डेटा चॅनेल सिफरचा।

दोन्ही वाचा, कारण ते वेगवेगळ्या प्रश्नांची उत्तरे देतात। नियंत्रण चॅनेलचे अपयश कोणत्याही डेटा सिफरचे महत्त्व येण्यापूर्वी कनेक्शन थांबवते। डेटा चॅनेलची विसंगती यशस्वी हस्तांदोलनानंतर दिसते, कोणताही सामायिक सिफर नाही अशा संदेशासह।

मग दोन्ही बाजूंच्या दिलेल्या याद्या तुलना करा। जे नाव एका सहकाऱ्याची आवृत्ती किंवा त्याचा क्रिप्टो आधार देत नाही ते निवडता येत नाही, ते दुसऱ्या सहकाऱ्याच्या यादीत कितीही लवकर आले तरी।

निवड प्रत्यक्षात कशी होते

सर्व्हर हस्तांदोलनादरम्यान आपली data-ciphers यादी क्लायंटकडे ढकलतो, आणि क्लायंट त्या यादीतील पहिली नोंद निवडतो जिला तोही आधार देतो। म्हणून क्रम सर्व्हरच्या कॉन्फिगरेशनचा आहे, क्लायंटचा नाही।

हा तपशील गोंधळात टाकणाऱ्या निकालांचा एक वर्ग स्पष्ट करतो। सर्व्हरची यादी ठरवत असताना क्लायंटची यादी पुन्हा क्रमवारीत केल्याने काहीच बदलत नाही। क्लायंट देऊ शकत नाही असा सिफर जोडल्यानेही काहीच बदलत नाही, कारण क्लायंटला निवडलेली नोंद वापरता आली पाहिजे।

नवीन आवृत्त्यांनी मूलभूत यादी बदलली आणि ती ठेवणारा पर्याय नाव बदलला, म्हणून वेगवेगळ्या आवृत्त्यांवरील दोन सहकारी कोणीही प्रोफाइल संपादित न करता असहमत होऊ शकतात। टायपिंगची चूक गृहीत धरण्यापूर्वी प्रत्येक बाजूला आवृत्ती तपासा।

यादी अमूर्त अर्थाने शक्तीची क्रमवारी नाही। ती उमेदवारांचा संच आहे, आणि निवडलेली नोंद सर्व्हरच्या क्रमाने पहिली परस्पर समर्थित नोंद आहे। म्हणून वेगळ्या दिसणाऱ्या दोन याद्या एकाच सिफरवर सहमत होऊ शकतात। म्हणूनच सारख्याच दिसणाऱ्या दोन याद्या देखील अयशस्वी होऊ शकतात।

जुन्या सहकाऱ्यांना जाणीवपूर्वक बॅकअप हवा असतो

जो सहकारी अजिबात बोलणी करू शकत नाही, कारण तो यंत्रणेपेक्षा जुना आहे किंवा त्याने ती बंद केली आहे, त्याला दस्तऐवजीकृत सुसंगतता व्यवस्था हवी असते। बॅकअप पर्याय नेमका त्याच प्रसंगासाठी आहे आणि जे सहकारी बोलणीत सहभागी होत नाहीत त्यांना लागू होतो।

हे प्रत्येक जुना सिफर सक्षम करण्यासारखे नाही जेणेकरून संदेश गायब होईल। विस्तृत यादी प्रत्येक सहकाऱ्यासाठी सत्र कमकुवत करते, ज्यांनी काही मजबूत ठरवले असते त्यांच्यासह।

असंबंधित अल्गोरिदम नावे संपादित करण्याऐवजी दोन्ही बाजूंचे समन्वय साधा। सर्व्हर अपग्रेडने जुना पर्याय काढला असेल, तर दुरुस्ती आवृत्ती योजनेतली आहे, क्लायंटवरील घाईतली नाही।

पडताळणी अभंग ठेवा

डेटा चॅनेलची विसंगती न पडताळलेला सर्व्हर स्वीकारण्याचे कारण नाही। प्रमाणपत्र पडताळणी, अपेक्षित सर्व्हर नाव आणि नियंत्रण चॅनेलच्या संरक्षण सेटिंग्ज सिफर निवडीपासून वेगळ्या आहेत आणि कोणत्याही सुसंगतता बदलातून टिकल्या पाहिजेत।

ठरलेला डेटा सिफर, क्लायंट आवृत्ती आणि सर्व्हर आवृत्ती एकत्र नोंदवा, जेणेकरून पुढील तुलना तथ्यांपासून सुरू होईल, प्रोफाइल फाइलपासून नाही।

समर्थित दुरुस्तीनंतर सुरुवातीचे कनेक्शन आणि पुन्हा बोलणी तपासा, कारण एकदा स्थापन झालेले सत्र किल्ल्या नूतनीकरणाच्या वेळी तरीही अयशस्वी होऊ शकते।

बोगदा स्थापन झाला आणि साइट्स तरीही अयशस्वी झाल्या, तर सिफर आता संशयित नाही। राउटिंग आणि DNS सह पुढे जा। कामाचा क्रम: लॉगच्या दोन्ही ओळी वाचा, दोन्ही याद्या तुलना करा, आवृत्त्या तपासा, बॅकअप फक्त गरज असलेल्या सहकाऱ्यासाठी जोडा, मग नूतनीकरण मार्ग पुन्हा तपासा।