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 टिपा। आवश्यक आवृत्ती खालची मर्यादा सूट यादीपासून वेगळी सांगा। चालू इन्स्टन्सचे प्रभावी धोरण त्याच्या मालकासह पुष्टी करा। एक परवानगीचे सत्र आणि योजना परवानगी देत असल्यास जुन्या आवृत्तीचा एक नाकारलेला प्रयत्न पाहा। नियंत्रण चॅनेल आणि डेटा चॅनेलचे निकाल वेगळे निरीक्षण म्हणून नोंदवा।

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

संबंधित लेख