SECLEVEL=0 लक्षण ठीक करता है, प्रमाणपत्र नहीं

OpenVPN कनेक्शन विफल होता है, कोई एक पंक्ति का सुधार ढूँढता है जो SECLEVEL=0 जोड़ता है, और सुरंग ऊपर आ जाती है। जो बदला वह न प्रमाणपत्र था और न साइफ़र सूट; पुस्तकालय-व्यापी स्वीकृति की सीमा खिसक गई, और इसके बाद प्रक्रिया जो कुछ भी करती है वह नई सीमा विरासत में लेती है। यह समझना इससे पहले ज़रूरी है कि वही पंक्ति परिवेश की हर प्रोफ़ाइल में नक़ल की जाए।

तय करें कौन-सा पुस्तकालय और कौन-सी नीति लागू है

SECLEVEL एक OpenSSL अवधारणा है, इसलिए पहला सवाल यह है कि क्या आपका बिल्ड OpenSSL का उपयोग करता है भी। OpenVPN को एक से अधिक क्रिप्टोग्राफ़ी पुस्तकालयों से जोड़ा जा सकता है, और जो सेटिंग उनमें से एक पर लागू होती है वह बाक़ी के लिए अर्थहीन है। बाइनरी से पूछें कि यह किससे बना है, फिर पुस्तकालय से पूछें कि उसने कौन-सा संस्करण और विन्यास लोड किया:

openvpn --version | head -3
openssl version -a

संस्करण का आउटपुट ध्यान से पढ़ें, क्योंकि वितरण डिफ़ॉल्ट पैच करते हैं। कुछ ऐसा सिस्टम विन्यास भेजते हैं जो न्यूनतम स्तर को अपस्ट्रीम डिफ़ॉल्ट से ऊपर उठाता है, और इसीलिए एक जैसे OpenVPN पैकेजों वाली दो मशीनों पर वही प्रोफ़ाइल अलग व्यवहार करती है। प्रभावी नीति वही है जो चल रही प्रक्रिया ने लोड की, अपस्ट्रीम मैनुअल वाली नहीं।

फिर उन दो परतों को अलग करें जिन्हें लोग मिला देते हैं। OpenVPN के अपने TLS नियंत्रण हैं, जिनमें प्रमाणपत्र प्रोफ़ाइल सेटिंग और स्पष्ट साइफ़र सूचियाँ शामिल हैं, और वे पुस्तकालय जो लागू करती है उसके ऊपर बैठते हैं। पुस्तकालय का स्तर घटाने से यह नहीं बदलता कि आपका OpenVPN विन्यास कौन-से साइफ़र सूचीबद्ध करता है, और OpenVPN सूची को संकरा करने से पुस्तकालय की सीमा नहीं बढ़ती। यह जानना कि किस परत ने आपको अस्वीकार किया, वही है जो सुधार को अनुमान बने रहने से रोकता है।

अस्वीकार हो सकने वाली तीन चीज़ों को अलग करें

पहला उम्मीदवार पहचान सामग्री है: ऐसा प्रमाणपत्र जिसकी कुंजी बहुत छोटी है या जिसके हस्ताक्षर एल्गोरिदम को नीति अब स्वीकार नहीं करती। दूसरा कुंजी-विनिमय पैरामीटर है, जैसे कोई समूह जिसे नीति बहुत कमज़ोर मानती है। तीसरा ऐसा साइफ़र सूट है जिसे नीति बाहर रखती है। तीनों हैंडशेक विफलता पैदा कर सकते हैं, और केवल त्रुटि पाठ और वार्ता का चरण ही उन्हें अलग करते हैं।

इन तीनों में से कोई भी डेटा-चैनल का साइफ़र नहीं है। OpenVPN अपने सुरंग एन्क्रिप्शन पर TLS हैंडशेक से अलग बातचीत करता है, इसलिए सुरक्षा स्तर बदलने के बाद सफल होने वाला कनेक्शन इस बारे में कुछ नहीं कहता कि आपका पेलोड किस साइफ़र से सुरक्षित है। अगर आप वास्तव में डेटा की गोपनीयता के बारे में पूछ रहे हैं, तो आप बिल्कुल ग़लत नियंत्रण देख रहे हैं।

स्तर घटाना एक साथ तीनों इनपुट के लिए स्वीकृति का दायरा बढ़ाता है। यही वह हिस्सा है जो लोग चूक जाते हैं: जो सुधार पुराने प्रमाणपत्र को अनुमति देता है वह कमज़ोर समूह और ऐसे सूट को भी अनुमति देता है जिसे आपने शायद मंज़ूर करने का इरादा नहीं किया था। एक त्रुटि ने बदलाव को जन्म दिया, और बदलाव त्रुटि से व्यापक है। यही असमानता कारण है कि सीमित अपवाद पूरे परिवेश के डिफ़ॉल्ट से बेहतर है।

इनपुट बदलें, सीमा नहीं

विन्यास को छूने से पहले सटीक त्रुटि सुरक्षित रखें, जिसमें वह चरण भी शामिल है जिसने उसकी सूचना दी और वह वस्तु जिसका उसने नाम लिया। प्रमाणपत्र की समस्या उसे ऐसी चीज़ से बदलकर हल होती है जिसे वर्तमान नीति स्वीकार करती है, जिसका अर्थ आम तौर पर प्राधिकरण से उसे फिर से जारी कराना है, न कि वही फ़ाइल दोबारा स्थापित करना।

अगर अस्वीकृत इनपुट ऐसे सहकर्मी का है जिसे आप नियंत्रित नहीं करते, तो बातचीत उसके मालिक के साथ समर्थित प्रतिस्थापन सामग्री के बारे में है। ऐसी प्रणाली को समायोजित करने के लिए अपनी सीमा घटाना जिसकी कोई देखभाल नहीं करता, लागत उनसे उनके बाद जुड़ने वाले सब पर डाल देता है।

जहाँ सर्वर नीति लागू करता है, वहाँ पुस्तकालय को दोष देने से पहले जाँचें कि क्या OpenVPN-स्तरीय सेटिंग ही असली कारण है। ऐसी प्रमाणपत्र प्रोफ़ाइल जो तैनात प्रमाणपत्र की क्षमता से कड़ा वर्ग माँगती है, सुरक्षा स्तर जो भी हो, विफल होगी, और उस प्रोफ़ाइल को हटाना पुस्तकालय की जाँचें बंद करने से सँकरा बदलाव है।

अगर घटाना ही पड़े, तो सीमित करें और दर्ज करें

कभी-कभी स्वीकृत संगतता अपवाद ही सही उत्तर होता है, विशेषकर ऐसे पुराने सहकर्मी के लिए जिसकी सेवानिवृत्ति योजना तिथिबद्ध है। इसे पूरे होस्ट के बजाय उस सेवा तक सीमित करें जिसे इसकी ज़रूरत है: सेवा-विशिष्ट विन्यास फ़ाइल या समर्पित OpenSSL विन्यास का प्रभाव-दायरा वैश्विक प्रोफ़ाइल में निर्यात से छोटा होता है।

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

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

बाद में पहचान और सुरक्षा सत्यापित करें

सफल कनेक्शन केवल यह साबित करता है कि संशोधित शर्तों ने उसे स्वीकार किया। पुष्टि करें कि होस्टनाम और सहकर्मी सत्यापन अब भी अपना काम कर रहा है, उपयोग में लाया प्रमाणपत्र वही है जिसे आप तैनात करना चाहते थे, और वार्ता किया गया डेटा चैनल उस नीति से मेल खाता है जो आपके अनुसार है।

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

OpenSSL के सुरक्षा स्तरों का संदर्भ स्पष्ट कहता है कि ढाँचा कुंजियों, हस्ताक्षरों, समूहों और सूटों पर सीमाएँ एक साथ लगाता है, और शून्य स्तर वह सब अनुमति देता है जो कॉलबैक जाँचता है। आपने जो बदला उसका विस्तार यही है, और यही वह वाक्य है जो तब उद्धृत किया जाता है जब कोई पूछे कि सुधार सँकरा था या नहीं।

ऑडिट से बचने वाला हस्तांतरण बताता है कि किस नीति ने कौन-सा इनपुट अस्वीकार किया, क्या बदला गया और परिणामस्वरूप क्या स्वीकार्य रहता है। «यह SECLEVEL=0 के साथ काम करता है» एक कनेक्शन के बारे में अवलोकन है, तैनाती का सुरक्षा आकलन नहीं।