OpenVPN tls-ciphersuites बनाम tls-version-min: कुनले के लागू गर्छ

TLS 1.3 सूट सूचीले प्रोटोकल संस्करण सीमित गर्दैन, र show-tls ले स्थानीय समर्थन मात्र देखाउँछ। नीति, सूट र वार्तामा टुंगिएका नतिजा अलग-अलग जाँच्नुहोस्।

अधिकांश OpenVPN TLS छलफलमा तीन फरक तथ्य एकै लाइनमा मिलाइन्छ: तपाईंको क्लाइन्ट बिल्डले के गर्न सक्छ, प्रोफाइलले के अनुमति दिन्छ र सत्रले वास्तवमा के कुरा मिलाएको थियो। छोटो TLS 1.3 सूट सूचीले बीचको प्रश्नको आधा मात्र उत्तर दिन्छ, र प्रोटोकल संस्करणको तल्लो सीमाबारे केही भन्दैन। तलका जाँचहरू क्रमैसँग गर्नुहोस् र पहिलो असफल हुने ठाउँमा रोकिनुहोस्, किनकि प्रत्येक पछिल्लो जाँचले अघिल्ला टुंगिएका छन् भन्ने मान्छ।

कुनै पनि सूची पढ्नुअघि बिल्ड जाँच्नुहोस्

कन्फिगरेसन निर्देशनले प्रोटोकल समर्थन नभएको बाइनरीमा त्यो थप्न सक्दैन। कम्पाइल गरिएको क्रिप्टो लाइब्रेरीको नाम दिने संस्करण ब्यानरबाट सुरु गर्नुहोस्:

openvpn --version

OpenSSL सँग लिंक गरिएको 2.6 बिल्डले tls-cipher र tls-ciphersuites दुवै स्वीकार गर्छ। mbed TLS सँगको बिल्डमा TLS 1.3 सूट चयन नै छैन, र 2.6 म्यानुअलले tls-ciphersuites लाई OpenSSL विकल्पका रूपमा चिन्ह लगाउँछ। यदि सर्भर अर्को ब्याकइन्डसँग पुनर्निर्माण गरियो भने, त्यही प्रोफाइलले कन्फिगरेसनको एक पनि लाइन नबदली व्यवहार बदल्न सक्छ।

यहाँ हुँदा openvpn --show-tls चलाउनुहोस् र आउटपुट राख्नुहोस्। त्यही पछि तुलना गर्ने सूची हो, र कसैले प्रोफाइल सम्पादन गर्न थाल्नुअघि त्यो टिप्नु सस्तो हुन्छ।

ब्यानर र सूची च्याट विन्डोमा होइन, परिवर्तन टिकटमा लेख्नुहोस्। छ हप्तापछि क्लाइन्टले सूट दिन सक्छ कि भनेर दुई जना झगडा गर्दा, टिपिएको आउटपुटले एकै लाइनमा त्यो टुंग्याउँछ।

संस्करण सीमाहरू साइफर सूचीबाट अलग राख्नुहोस्

2.6 म्यानुअलमा यी एक होइन, तीन नियन्त्रण हुन्:

  • tls-cipher ले TLS 1.2 र त्यसअघिका लागि साइफर नीति तोक्छ र OpenSSL को साइफर सूचीमा पठाइन्छ;
  • tls-ciphersuites ले TLS 1.3 सूट छान्छ;
  • tls-version-min र tls-version-max ले जडानले प्रयोग गर्न सक्ने प्रोटोकल संस्करण सीमित गर्छन्।

त्यसैले ध्यानपूर्वक छाँटिएको TLS 1.3 सूट सूचीले पुरानो संस्करण अझै अनुमति छ भन्ने केही प्रमाणित गर्दैन। यदि आवश्यकता «TLS 1.3 मात्र» हो भने, त्यसलाई संस्करणको तल्लो सीमाले बोक्छ, र सूट सूचीले त्यो सीमाभित्रका विकल्प मात्र साँघुरो बनाउँछ:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

यो जोडीले दुई काम गर्छ। एउटा लाइन मेट्दा अर्कोले तपाईं सोचेभन्दा कम लागू गर्छ, र यही त्यो असफलता हो जसका लागि यो सम्पूर्ण जाँच छ।

डाटा च्यानल चौथो नियन्त्रण हो। data-ciphers ले सुरुङभित्रको सममित साइफरमा कुरा मिलाउँछ, र त्यसको नतिजाले नियन्त्रण च्यानलको TLS संस्करणबारे केही भन्दैन। सत्र सारांशमा AES-256-GCM देख्नु कुनै पनि दिशामा TLS 1.3 को प्रमाण होइन।

show-tls लाई स्थानीय सूचीका रूपमा पढ्नुहोस्

--show-tls ले यो बाइनरी जससँग लिंक भएको क्रिप्टो लाइब्रेरीले समर्थन गर्ने सूटहरू प्राथमिकता क्रममा सूचीबद्ध गर्छ। यो गेटवेबाट आएको रिपोर्ट होइन। म्यानुअलले स्पष्ट भन्छ कि सूची स्थानीय लाइब्रेरीबाट आउँछ, अर्थात् OpenSSL 3.x भएको ल्यापटप र पुरानो बिल्ड भएको राउटरले एउटै सर्भरसँग बोल्दा फरक सूची छाप्नेछन्।

EvidenceWhat it actually describes
--show-tls outputCapabilities of this client build and its library
Profile directivesWhat this attempt is allowed to offer
Session log lineWhat this one negotiation selected

मान्नुहोस् क्लाइन्टले A, B र C सूट समर्थन गर्छ र एउटा सत्रले B छान्छ। त्यसले सर्भरले A वा C लाई अनुमति दिन्छ कि भन्ने वा B नै यसको एकमात्र अनुमत विकल्प हो कि भन्ने केही स्थापित गर्दैन। तीनै लाइन अलग राख्नुहोस्, र धेरै अलमल्याउने TLS विषय आफैं टुंगिनेछन्।

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

गेटवेलाई यस्तो कुरा सोध्नुहोस् जसको उत्तर दिन सक्छ

यदि तपाईं सेवा व्यवस्थापन गर्नुहुन्छ भने, डिस्कको फाइल होइन, चलिरहेको इन्स्ट्यान्सको प्रभावकारी कन्फिगरेसन जाँच्नुहोस्। OpenVPN अर्को --config बाटोसँग सुरु भएको, इन्क्लुड तान्ने, वा सम्पादनपछि पुनः सुरु नगरिएको हुन सक्छ। क्लाइन्टले भेट्ने कुरा चलिरहेको डिमनको नीति हो।

यदि तपाईंले यो व्यवस्थापन गर्नुहुन्न भने, अपरेटरसँग समर्थित क्लाइन्ट आवश्यकता वा सीमित स्वीकृति परीक्षण माग्नुहोस्। अस्वीकृत प्रयास स्वतः अस्वीकृत सूट होइन: संस्करणको तल्लो सीमा, remote-cert-tls जस्ता प्रमाणपत्र पहिचान जाँच, वा tls-auth र tls-crypt बीचको बेमेलले सूट चयन महत्त्वपूर्ण हुनुअघि नै आदानप्रदान अन्त्य गर्न सक्छ। क्लाइन्टको सूची बदल्नुअघि सर्भरको त्रुटि पढ्नुहोस्, किनकि «handshake failed» ले चार फरक कारण समेट्छ र तीमध्ये एउटा मात्र साइफर बेमेल हो।

VPN पोर्टतर्फ openssl s_client ताक्नाले पनि प्रश्न पुनरुत्पादन गर्दैन। नियन्त्रण च्यानल OpenVPN को आफ्नै फ्रेमिङभित्र चल्छ, त्यसैले कच्चा TLS प्रोबले अरू केही अपेक्षा गर्ने पोर्टमा फरक प्रोटोकल जाँच्छ। त्यसबाट निकालिएको कुनै पनि निष्कर्ष प्रोबबारे हो, सुरुङबारे होइन।

दुई नतिजा लिपिबद्ध गर्नुहोस् र ती अलग राख्नुहोस्

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

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

त्यसपछि ती दुई लाइन स्मृतिबाट होइन, त्यही फाइलबाट पढ्नुहोस्। जोडी नै प्रमाण हो; सूट नाम मात्र प्राथमिकता हो, र संस्करण सीमा सर्भरले के अस्वीकार गर्छ भन्नेबारे अलग कथन हो।

जाँचहरू यही क्रममा गर्नुहोस्। --version ले बिल्ड र ब्याकइन्ड पुष्टि गर्नुहोस्। केही बदल्नुअघि --show-tls टिप्नुहोस्। आवश्यक संस्करण तल्लो सीमा सूट सूचीबाट अलग भन्नुहोस्। चलिरहेको इन्स्ट्यान्सको प्रभावकारी नीति यसको मालिकसँग पुष्टि गर्नुहोस्। एउटा अनुमत सत्र र योजनाले अनुमति दिए पुरानो संस्करणको एउटा अस्वीकृत प्रयास अवलोकन गर्नुहोस्। नियन्त्रण च्यानल र डाटा च्यानलका नतिजा अलग निष्कर्षका रूपमा लिपिबद्ध गर्नुहोस्।

आवश्यक क्लाइन्टले नयाँ न्यूनतम पूरा गर्न नसके, रोलआउट सकिएको देखाउन असम्बन्धित स्वीकृति नियम चुपचाप तल झार्नुको सट्टा त्यो स्थानान्तरण वा अपवाद निर्णय स्पष्ट रूपमा गर्नुहोस्।

सम्बन्धित लेखहरू