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 लाइन कन्फिगरेसनको मनसायको प्रमाण मात्र हो, र मनसाय जाँचको सबैभन्दा सस्तो भाग हो।