auth डाइजेस्ट किन OpenVPN पैकेटों की रक्षा करता है?
auth विकल्प प्रोफ़ाइल के संकेत से कम कवर करता है। डाइजेस्ट नीति तय करने से पहले चैनल, AEAD स्थिति और कंट्रोल-चैनल सुरक्षा को समझें।
OpenVPN डाइजेस्ट पर अधिकांश बहस गलत पैकेट से शुरू होती है। auth SHA256 को “केवल वे ही पीयर स्वीकार करें जो SHA256 देते हैं” के रूप में पढ़ना पहली चीज़ है जिसे भूलना है। विकल्प कुछ खास पैकेटों के लिए एक डाइजेस्ट का नाम देता है, और वे पैकेट कौन-से हैं यह चैनल पर और इस पर निर्भर करता है कि वह चैनल AEAD है या नहीं। नीचे दिए चार प्रश्न क्रम से लें; हर एक यह सीमित करता है कि आपकी परिनियोजन में सेटिंग का क्या अर्थ हो सकता है।
उस चैनल का नाम लें जिसकी रक्षा सेटिंग को करनी है
OpenVPN में एक कंट्रोल चैनल है जो TLS हस्तमिलन ट्रैफ़िक ढोता है और एक डेटा चैनल है जो टनल का पेलोड ढोता है। auth डाइजेस्ट दोनों में भूमिका निभाता है, पर एक जैसी नहीं, और प्रोफ़ाइल अंतर को शायद ही दृश्य बनाती है। कॉन्फ़िग फ़ाइल छूने से पहले लिख लें कि आप दोनों में से किसे सीमित करना चाहते हैं।
नीचे दी तालिका इस बात का संक्षिप्त रूप है कि वही विकल्प हर संदर्भ में कैसे पहुँचता है।
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
उस पर निर्भर होने से पहले जाँचें कि डेटा चैनल AEAD है या नहीं
यदि बातचीत से तय डेटा साइफ़र AES-GCM या CHACHA20-POLY1305 है, तो डेटा चैनल स्वयं को प्रमाणित करता है और अलग डाइजेस्ट वह काम नहीं करता जो आप शायद सोच रहे हैं। दोनों AEAD संरचनाएँ हैं, इसलिए अखंडता उसी क्रिया से बनती है जो पेलोड को एन्क्रिप्ट करती है। यह कोई अवनति नहीं है, पर इसका अर्थ है कि “हर डेटा पैकेट HMAC-SHA256 है” के रूप में उचित ठहराई नीति उस टनल पर तथ्यात्मक रूप से गलत है। नीति फिर से लिखने से पहले सर्वर लॉग या क्लाइंट स्थिति आउटपुट में तय मान की पुष्टि करें।
प्रोफ़ाइल की सूची के बजाय वास्तव में तय हुए साइफ़र की जाँच करें, क्योंकि बातचीत समुच्चय के किसी दूसरे सदस्य पर पहुँच सकती है। data-ciphers AES-256-GCM:AES-128-GCM एक बातचीत सूची है, और दोनों प्रविष्टियाँ AEAD हैं, इसलिए इनमें से कोई पेलोड सुरक्षा के लिए auth डाइजेस्ट का उपभोग नहीं करता।
कंट्रोल-चैनल सुरक्षा को अलग निर्णय मानें
tls-auth कंट्रोल-चैनल पैकेटों में HMAC जोड़ता है और अपना डाइजेस्ट auth सेटिंग से लेता है, इसीलिए AEAD टनल में भी सार्थक डाइजेस्ट कॉन्फ़िगर हो सकता है। tls-crypt अपनी निश्चित सुरक्षा वाली भिन्न व्यवस्था है, इसलिए यह न मानें कि वह tls-auth का हर गुण विरासत में लेता है। मान्यताओं को एक-दूसरे पर स्थानांतरित करने के बजाय चुने गए तंत्र का दस्तावेज़ पढ़ें।
दोनों पीयर को व्यवस्था और कुंजी की दिशा पर भी सहमत होना चाहिए। मेल खाता डाइजेस्ट पर गलत दिशा में प्रयुक्त कुंजी फ़ाइल ऐसा हस्तमिलन बनाती है जो ऐसे कारणों से विफल होता है जिन्हें डाइजेस्ट सेटिंग समझा नहीं सकती।
auth को साइफ़र बातचीत और प्रमाणपत्रों से अलग रखें
तीन सेटिंगें लगातार मिलाई जाती हैं: auth डाइजेस्ट, डेटा-साइफ़र सूची और प्रमाणपत्र का हस्ताक्षर एल्गोरिदम। पहली बदलने से प्रमाणपत्र फिर जारी नहीं होता, उसका हस्ताक्षर डाइजेस्ट चयनित नहीं होता, और उपयोगकर्ता-पासवर्ड विधि नहीं बनती। प्रोटोकॉल विकल्प की परिभाषाएँ OpenVPN 2.6 स्रोतों में हर एक को अपने अनुभाग में बताती हैं, जो एक उपयोगी स्मरण है कि वे स्वतंत्र नॉब हैं।
डाइजेस्ट बदलने के बाद जब पीयर जुड़ने से मना करता है, तो कारण सामान्यतः अन्य दो सेटिंगों में से एक में असंगति होता है। कोई भी बदलने से पहले दोनों सिरे पढ़ें।
नीति लिखें और चालू कॉन्फ़िगों से उसकी तुलना करें
फ़्लीट-स्तरीय वक्तव्य को अनुमत डेटा-चैनल मोड और चुनी गई कंट्रोल-चैनल सुरक्षा को एक ही वाक्य में स्पष्ट रूप से नाम देना चाहिए। वह वाक्य परीक्षण योग्य है; “हम SHA256 का उपयोग करते हैं” नहीं। फिर उसकी तुलना प्रभावी सर्वर और क्लाइंट प्रोफ़ाइलों से करें, किसी रिपॉज़िटरी के टेम्पलेट से नहीं।
हर टनल ने वास्तव में क्या तय किया और किस तंत्र ने उसके पैकेट प्रमाणित किए, यह दर्ज करके समाप्त करें। प्रोफ़ाइल में दिखने वाली auth पंक्ति केवल कॉन्फ़िगरेशन के इरादे का प्रमाण है, और इरादा जाँच का सबसे सस्ता हिस्सा है।