OpenVPN tls-ciphersuites बनाम tls-version-min: कौन क्या लागू करता है

अधिकांश 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 वाला लैपटॉप और पुराने बिल्ड वाला राउटर एक ही सर्वर से बात करते हुए अलग सूचियाँ छापेंगे।

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

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