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 ओळ केवळ कॉन्फिगरेशनच्या हेतूचा पुरावा आहे, आणि हेतू तपासणीचा सर्वात स्वस्त भाग आहे।