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 संस्करण और सूट, चुना गया डेटा सिफर और प्रमाणपत्र सत्यापन सेटिंग्स एक साथ दें। उस परत को बदलें और फिर नए सहमत मानों की पुष्टि के लिए ताज़ा लॉग पढ़ें।