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 संस्करण र सुट, छानिएको डाटा सिफर र प्रमाणपत्र प्रमाणीकरण सेटिङहरू सँगै दिनुहोस्। त्यो तह परिवर्तन गर्नुहोस् र त्यसपछि नयाँ सहमत मानहरू पुष्टि गर्न ताजा लग पढ्नुहोस्।