AES-256-GCM नहीं मिला: क्लाइंट की क्षमता या बातचीत?

जो OpenVPN प्रोफ़ाइल कहीं और काम करती है, वह बताती है कि AES-256-GCM नहीं मिला, या सहकर्मियों के पास कोई साझा सिफर नहीं है, और पहली प्रवृत्ति प्रोफ़ाइल संपादित करने की होती है। ये दो संदेश अलग-अलग विफलताएँ बताते हैं। एक कहता है कि स्थानीय प्रोग्राम में ऐसा एल्गोरिदम नहीं है; दूसरा कहता है कि दोनों पक्षों के पास एल्गोरिदम हैं पर साझा चुनाव नहीं। प्रोफ़ाइल संपादित करने से कोई भी ठीक नहीं होता जब तक आपको पता न हो कि आपके पास कौन-सी है।

त्रुटि का ठीक-ठीक पाठ और वह प्रोग्राम पढ़ें जिसने उसे बनाया।

तय करें कि आपके पास कौन-सी त्रुटि है

न मिलने वाले सिफर का संदेश स्थानीय मशीन पर विकल्प विश्लेषण से आता है, कोई पैकेट भेजे जाने से पहले। इसका अर्थ है कि आपके सामने की निष्पादन योग्य फ़ाइल या वह लाइब्रेरी जिससे वह जुड़ी है, वह एल्गोरिदम नहीं देती। साझा सिफर न होने का संदेश बाद में, बातचीत के दौरान आता है, और बताता है कि दोनों पक्ष सिफर समर्थित करते हैं पर एक पर सहमत नहीं हो पाते।

यह अंतर महत्वपूर्ण है क्योंकि एक सॉफ़्टवेयर संस्करण की समस्या है और दूसरी कॉन्फ़िगरेशन की। पहली संस्करण संख्या से तय होती है। दूसरी दो सूचियों की तुलना से तय होती है।

स्थानीय क्षमता की कमी

पुराने समुदाय बिल्ड आधुनिक डिफ़ॉल्ट से पहले के हैं, और डेस्कटॉप अनुप्रयोग अपना इंजन साथ ला सकता है जो बगल में स्थापित कमांड-लाइन पैकेज से अलग है। जाँच उसी निष्पादन योग्य फ़ाइल पर करें जिसने वास्तव में कनेक्शन शुरू किया, फिर पुराने प्रोग्राम को नया एल्गोरिदम सिखाने के बजाय समर्थित बिल्ड चुनें।

openvpn --version
openvpn --show-ciphers | grep -i gcm
openvpn --show-tls | head -5

यदि उस सूची में AES-256-GCM नहीं है, तो कोई प्रोफ़ाइल पंक्ति उसे नहीं जोड़ेगी। समाधान नया क्लाइंट या दूसरा बिल्ड है, और पुराने पक्ष की सीमाएँ अलग डिज़ाइन प्रश्न बन जाती हैं।

OpenVPN 3 आधारित क्लाइंट में इंजन और स्वीकार्य निर्देश समुदाय की 2.x पंक्ति से भिन्न हैं, इसलिए वही प्रोफ़ाइल पाठ उन कारणों से विफल हो सकता है जिनका सिफर सूची से कोई संबंध नहीं।

बातचीत की कमी

जब दोनों सहकर्मी एल्गोरिदम सूचीबद्ध करते हैं, तो शेष प्रश्न यह है कि कौन-सा पक्ष कौन-सी सूची देता है। समुदाय के OpenVPN ने बातचीत निर्देश का नाम बदला: 2.4 में ncp-ciphers 2.5 में data-ciphers बना, और 2.6 में पुरानी cipher पंक्ति मुख्यतः संगतता और फ़ॉलबैक के लिए काम करती है, तय किए गए समूह को परिभाषित करने के लिए नहीं।

इसीलिए केवल पुरानी cipher पंक्ति बदलने से बातचीत की सूची अछूती रह सकती है। पुरानी पंक्ति फ़ॉलबैक के लिए अब भी महत्वपूर्ण है, और वह अलग काम है। दोनों को मिलाने से ऐसे संपादन बनते हैं जो दिखने में कुछ नहीं बदलते।

openvpn --version | head -2
grep -n -E '^(data-ciphers|ncp-ciphers|cipher|tls-cipher)' server.conf client.ovpn

दोनों सिरों की सूचियाँ और सर्वर का अस्वीकृति संदेश तुलना करें। यदि प्रतिच्छेद खाली है, तो दूसरे संस्करण के लिए लिखे पोस्ट से मान नकल करने के बजाय सूचियाँ जानबूझकर मिलाएँ। बहुत उदार सूची हर कनेक्शन को चुपचाप कमज़ोर करती है। बहुत संकरी सूची उस सहकर्मी को बाहर कर देती है जिसे आप रखना चाहते थे।

संगतता स्पष्ट रखें

एक पुराने सहकर्मी के लिए फ़ॉलबैक लागत वाला निर्णय है: पूरी तैनाती कमज़ोर विकल्प स्वीकार करती है ताकि एक उपकरण जुड़ सके। इसे वैसे ही लिखें, और जिस सहकर्मी को आवश्यकता है उसी तक सीमित रखें।

दो शर्तें परिणाम तय करती हैं। यदि त्रुटि स्थानीय है, तो बिल्ड बदलें। यदि त्रुटि बातचीत की है, तो दोनों सिरों पर सूचियाँ मिलाएँ और लिखें कि किन संस्करणों का समर्थन करते हैं।

फिर संस्करण और क्षमता का आउटपुट संलग्न करके सटीक त्रुटि की रिपोर्ट करें। यह जोड़ी अनुपस्थित एल्गोरिदम को मतभेद से अलग करती है, और अनुमानित संपादन का अगला दौर शुरू होने से पहले रोक देती है।