DH फ़ाइल या tls-auth कुंजी? दो OpenVPN फ़ाइलों में अंतर

दो फ़ाइलें, दो निर्देश, और दोनों को उसी चीज़ के नाम से पुकारने की आदत जिसे वे कॉन्फ़िगर करते हैं। इसी तरह dh.pem tls-auth पंक्ति पर पहुँचती है और क्लाइंट अप्रत्याशित कुंजी प्रारूप वाले संदेश के साथ विफल हो जाता है। आपके सामने निर्णय यह नहीं है कि कौन-सी फ़ाइल अधिक मज़बूत है। यह है कि परिनियोजन को वास्तव में कौन-सी भूमिका चाहिए, और तीन शर्तें इसे तय करती हैं: आपका TLS स्टैक कौन-सा कुंजी विनिमय बातचीत करेगा, क्या आपको नियंत्रण-चैनल प्रमाणीकरण चाहिए, और क्या सामग्री को गोपनीय रहना चाहिए।

इनका क्रम से उत्तर दें और फ़ाइल का प्रश्न स्वयं उत्तर दे देगा। इन्हें छोड़ दें तो निर्देशों के नाम विनिमेय दिखने लगते हैं, और गलती ठीक उसी स्थिति से आती है।

फ़ाइल के नाम से पहले लेबल पढ़ें

फ़ाइल की पहली पंक्ति उसके नाम से अधिक जानकारी देती है, क्योंकि नाम मानवीय परंपरा है और लेबल औज़ार बनाता है। Diffie-Hellman पैरामीटर BEGIN DH PARAMETERS का PEM लेबल रखते हैं। OpenVPN की स्थिर कुंजी पूरी तरह भिन्न संरचना है, जिसका अपना हेडर और हेक्स पेलोड है।

नाम बदलने से कुछ परिवर्तित नहीं होता। ta.key नाम की पैरामीटर फ़ाइल अब भी पैरामीटर है, और dh.pem नाम की स्थिर कुंजी अब भी स्थिर कुंजी है; पार्सर सामग्री पढ़ता है और असंगति अस्वीकार करता है। प्रोफ़ाइल संपादित करने से पहले जाँचें:

head -n 1 dh.pem
head -n 1 ta.key

कौन-सी फ़ाइल चाहिए, यह तय करने वाली तीन शर्तें

पहली शर्त विनिमय है। परिमित क्षेत्र का Diffie-Hellman हस्तमिलन एक समूह चाहता है, और dh निर्देश वह जगह है जहाँ सर्वर उसके लिए पैरामीटर नाम देता है। दीर्घवृत्तीय वक्र का हस्तमिलन उस फ़ाइल की ज़रूरत ही नहीं रखता, क्योंकि वक्र ही पैरामीटर समुच्चय है। यदि आपका सर्वर केवल ECDHE सूट पर बातचीत करता है, तो DH फ़ाइल अतिरिक्त शक्ति नहीं बल्कि मृत भार है।

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

तीसरी शर्त गोपनीयता और वितरण है। DH पैरामीटर सत्र को कमज़ोर किए बिना प्रकाशित किए जा सकते हैं, क्योंकि गोपनीय मान प्रत्येक हस्तमिलन के लिए बनते हैं और पक्षों को कभी नहीं छोड़ते। स्थिर कुंजी प्रकाशित नहीं की जानी चाहिए: यह दोनों सिरों पर एक ही बाइट है, स्वयं नहीं घूमती, और जिसके पास यह है वह नियंत्रण-चैनल के वैध हस्ताक्षर बना सकता है। ये दो उत्तर पूरी तरह भिन्न व्यवहार नियमों की ओर इशारा करते हैं, इसीलिए एक फ़ाइल भंडार में रह सकती है और दूसरी नहीं।

हर भूमिका के लिए सही सामग्री बनाएँ

उस औज़ार का उपयोग करें जो निर्देश द्वारा अपेक्षित प्रारूप बनाता है, न कि उनके बीच रूपांतरण करें। OpenVPN 2.6 पर साझा कुंजी के लिए जनरेटर का टाइप किया गया रूप उद्देश्य स्पष्ट रूप से बताता है।

openvpn --genkey tls-auth ta.key

वह कमांड नई गोपनीय सामग्री बनाता है; यह मौजूदा कुंजी की मरम्मत या निरीक्षण नहीं करता, और दोबारा चलाने पर आपको भिन्न कुंजी मिलती है जो अन्य पक्षों के पास नहीं है। परिणामी फ़ाइल को उन पक्षों तक उस चैनल से प्रतिलिपि करें जिसे आप किसी भी साझा रहस्य के लिए उपयोग करते, और दिशा की परंपरा एक-सी रखें: tls-auth के साथ एक पक्ष key-direction 0 और दूसरा key-direction 1 उपयोग करता है।

DH पैरामीटर, जब आवश्यक हों, पैरामीटर निर्माण से आते हैं, कुंजी जनरेटर से नहीं, और परिणाम सार्वजनिक होने पर भी उनका स्रोत महत्वपूर्ण है। अज्ञात स्रोत से लिया गया समूह सार्वजनिक होने से भरोसेमंद नहीं हो जाता; उसे अब भी ऐसा समूह होना चाहिए जिस पर आपके पक्ष सहमत हों और जो अपने आकार या निर्माण से कमज़ोर न पड़े।

dh none क्या करता है और क्या नहीं

dh none संकीर्ण अर्थ वाला वास्तविक निर्देश है: कोई परिमित-क्षेत्र पैरामीटर फ़ाइल लोड नहीं होगी, क्योंकि हस्तमिलन दीर्घवृत्तीय वक्र का Diffie-Hellman उपयोग करता है। यह कुछ भी कमज़ोर करने के अर्थ में “DH चरण छोड़ें” का संक्षिप्त रूप नहीं है, और निश्चित रूप से OpenVPN से यह नहीं कहता कि किसी अन्य फ़ाइल को विकल्प के रूप में स्वीकार करे।

गलत पढ़ने से दो गलतियाँ निकलती हैं। पहली यह मानना कि dh none tls-auth की आवश्यकता हटा देता है, जबकि दोनों भिन्न चीज़ें नियंत्रित करते हैं। दूसरी यह कि केवल-वक्र कॉन्फ़िगरेशन के साथ पुरानी dh पंक्ति रखी जाए और फिर सोचा जाए कि सर्वर वास्तव में कौन-सी फ़ाइल उपयोग कर रहा है; यदि निर्देश मौजूद है तो फ़ाइल पढ़ी जाती है, और वहाँ का टूटा पथ उस कारण से प्रारंभ विफल कर देता है जिसका बातचीत होने वाले विनिमय से कोई संबंध नहीं है।

यदि गलत फ़ाइल पहले ही परिनियोजित हो चुकी है

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

फिर उन दो घटनाओं को अलग करें जिन्हें लोग मिला देते हैं। DH पैरामीटर फ़ाइल प्रकाशित करना लगभग हानिरहित है, क्योंकि पैरामीटर डिज़ाइन से ही सार्वजनिक थे। tls-auth कुंजी को उजागर करना दूसरी घटना है: कुंजी उसके पास रखने वाले हर पक्ष के लिए नियंत्रण-चैनल पैकेट प्रमाणित करती है, इसलिए प्रतिस्थापन पूरे परिनियोजन में समन्वित होना चाहिए, किसी एक होस्ट पर लागू नहीं।

पाँच मिनट की जाँच तय करती है कि आप किस स्थिति में हैं: हर फ़ाइल की पहली पंक्ति पढ़ें, उसका उल्लेख करने वाला निर्देश पुष्ट करें, और पुष्ट करें कि फ़ाइल का वितरण सामग्री की आवश्यकता से मेल खाता है। यह कार्यशील PKI को फिर से बनाने से छोटा काम है, और तीन शर्तें हर समय इसी ओर इशारा कर रही थीं।