OpenVPN लॉग: नियंत्रण चॅनेलचा सिफर विरुद्ध डेटा चॅनेलचा सिफर

DHE-RSA-AES256-SHA चे नाव घेणारी लॉग ओळ संपूर्ण कनेक्शनचा सारांश नाही। ती TLS हँडशेकशी संबंधित आहे जो नियंत्रण चॅनेलचे संरक्षण करतो, आणि टनेलच्या आतील ट्रॅफिक पूर्णपणे वेगळ्या पद्धतीने एन्क्रिप्ट केलेले असू शकते। त्याला VPN चा डेटा सिफर म्हणून सादर करणे ही टाळायची चूक आहे।

दोन निकाल महत्त्वाचे आहेत, आणि ते वेगवेगळ्या प्रश्नांची उत्तरे देतात। एक नियंत्रण चॅनेलसाठी ठरलेला TLS संच आहे; दुसरा टनेल वाहून नेणाऱ्या पॅकेट्सचा डेटा सिफर आहे।

दोन निकाल, दोन प्रश्न

नियंत्रण चॅनेल हँडशेक आणि सहकार्यांमधील व्यवस्थापन संदेश वाहून नेते। त्याचा सिफर TLS स्टॅक निवडतो, म्हणून नाव TLS परंपरांचे पालन करते। डेटा चॅनेल वापरकर्त्याचे ट्रॅफिक वाहून नेते आणि ते OpenVPN च्या स्वतःच्या सिफर वाटाघाटीद्वारे कॉन्फिगर केले जाते।

दोन्हीपैकी कोणतीही ओळ वाचण्यापूर्वी तुम्ही कोणत्या प्रश्नाचे उत्तर देत आहात ते ठरवा। टनेल एन्क्रिप्टेड आहे का आणि हँडशेक मजबूत आहे का, हे एकच प्रश्न नाहीत।

दोन्ही ओळी दाखवणारा लॉग उतारा उपयुक्त आहे। नियंत्रण ओळ TLS आवृत्ती आणि संचासाठी वाचा, आणि डेटा ओळ ज्या अल्गोरिदमसाठी जो खरोखर पेलोडचे संरक्षण करतो त्यासाठी वाचा।

TLS संचाचे नाव त्याच्या स्वतःच्या संदर्भात उलगडा

OpenSSL शैलीच्या ऐतिहासिक नावात, जसे DHE-RSA-AES256-SHA, प्रत्येक घटक वेगळा निर्णय सांगतो। DHE अल्पकालिक Diffie-Hellman किल्ली करार आहे, RSA प्रमाणीकरण पद्धत आहे, AES256 TLS रेकॉर्डसाठी CBC मोडमधील AES-256 आहे, आणि SHA SHA-1 आधारित रेकॉर्ड MAC आहे।

शेवटचा घटक प्रमाणपत्राचा फिंगरप्रिंट नाही, आणि तो असा वाचणे सामान्य चूक आहे। नाव स्वतःहून प्रोटोकॉल आवृत्तीही सांगत नाही, कारण TLS 1.3 पूर्णपणे वेगळी नामकरण योजना वापरते। TLS_AES_256_GCM_SHA384 त्या नव्या स्वरूपाचे अनुसरण करते, ज्यात शेवटचा हॅश संचाच्या रचनेचा भाग आहे, MAC ची निवड नाही। घटकानुसार वाचन फक्त जुन्या नामकरण शैलीवर लागू करा।

OpenSSL संच संदर्भ ही नावे त्यांच्या व्याख्यांशी जोडते जर कोणताही घटक अपरिचित असेल।

वाहून नेल्या जाणाऱ्या ट्रॅफिकसाठी डेटा चॅनेलचा निकाल वाचा

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

AES-GCM सारखा AEAD सिफर स्वतःची अखंडता तपासणी सोबत ठेवतो, म्हणून वेगळा डेटा चॅनेल HMAC त्या मार्गाचा भाग नाही।

auth निर्देश TLS, प्रमाणपत्रे किंवा डेटा सिफर उन्नत करत नाही। तो प्रोटोकॉलच्या ज्या भागांमध्ये अजूनही एक वापरला जातो त्यांच्यासाठी डायजेस्ट निवडतो, आणि AEAD डेटा सिफरसह कॉन्फिगर करण्यासाठी वेगळा डेटा HMAC नाही।

ओळख तपासण्या सिफरच्या निकालाबाहेर ठेवा

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

या तपासण्या पुनरावलोकन नोट्समध्ये सिफरच्या निकालाजवळ ठेवा, त्यात विलीन करू नका।

चालू सत्राचे ठरलेले निकाल नोंदवा

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

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