OpenVPN कम्प्रेशन: इनकार, केवल प्राप्ति या पूर्ण LZO?
comp-lzo no कोई सख्त इनकार नहीं है। कम्प्रेशन से इनकार, माइग्रेशन के दौरान एकतरफा स्वीकृति और उसे बनाए रखने की तुलना करें, फिर देखें कि offload क्या करता है।
प्रोफ़ाइल में तीन पंक्तियाँ ऐसी दिखती हैं जैसे सभी कम्प्रेशन बंद कर देती हैं, और वास्तव में उनमें से केवल एक ही ऐसा करती है। अंतर मायने रखता है, क्योंकि जिस चेतावनी को आप शांत करना चाहते हैं वह लक्षण है, जबकि नीति तय करती है कि दूसरा पक्ष अभी भी कम्प्रेस कर सकता है या नहीं। विकल्पों को एक ही अक्ष पर तुलना करने से, यानी बदलाव के बाद हर एक क्या अनुमति देता है, अधिकांश अस्पष्टता हट जाती है। आपको कौन सा चाहिए यह इस पर निर्भर है कि आप माइग्रेट कर रहे हैं या स्थिर हो रहे हैं।
तीन नीतियाँ जो कॉन्फ़िग फ़ाइल में एक जैसी दिखती हैं
हर विकल्प अलग प्रश्न का उत्तर देता है। allow-compression no कम्प्रेस किए गए पेलोड को सीधे अस्वीकार करता है, allow-compression asym जो आता है उसे डीकम्प्रेस करता है और जो जाता है उसे कभी कम्प्रेस नहीं करता, और पुराना comp-lzo no दूसरे पक्ष के push को कम्प्रेशन चालू करने की जगह छोड़ता है। केवल पहला ही ऐसी नीति है जिसे सर्वर ओवरराइड नहीं कर सकता।
चुनने से पहले तीनों को एक तालिका में लिखें, क्योंकि नाम समीक्षक को भ्रमित करने के लिए काफ़ी करीब हैं। इनमें से दो अभी भी प्राप्त पैकेटों पर डीकम्प्रेशन कोड चलाते हैं, और सुरक्षा का तर्क ठीक इसी बारे में है। तीसरा दिशा सीमित करने के बजाय क्षमता ही हटा देता है। यदि परिवर्तन रिकॉर्ड कहता है कि कम्प्रेशन बंद है, तो ठीक एक पंक्ति उस वाक्य को पूरा करती है।
जिस चेतावनी से जाँच शुरू हुई वह लक्ष्य नहीं है। अनुमतिपरक नीति बनाए रखते हुए उसे शांत करने से साफ़ लॉग और अपरिवर्तित एक्सपोज़र मिलता है।
| Setting | What it permits | When it is the right answer |
|---|---|---|
allow-compression no | No compressed payloads, and no compression framing under offload | Both ends can be changed now |
allow-compression asym | Decompress inbound only | A dated migration while peers catch up |
comp-lzo no | Off locally, still pushable by a peer | Legacy compatibility you can still justify |
पुराने LZO विकल्प में no का क्या अर्थ है
अप्रचलित LZO विकल्प में no स्थानीय पक्ष के लिए कम्प्रेशन बंद करता है, पर दूसरे पक्ष को वहाँ उसे चालू करने से नहीं रोकता जहाँ नीति अनुमति देती है। यही असममिति कारण है कि प्रोफ़ाइल को सख्त इनकार पर ले जाने से व्यवहार ऐसे तरीक़ों से बदलता है जिन्हें एक-सर्वर प्रयोगशाला परीक्षण शायद कभी उजागर न करे।
सुरक्षा की चिंता सशर्त है, निरपेक्ष नहीं। जब कोई हमलावर किसी रहस्य के पास चुना हुआ स्पष्ट पाठ रख सकता है और देख सकता है कि कम्प्रेशन एन्क्रिप्टेड ट्रैफ़िक का आकार कैसे बदलता है, तो सूचना का मार्ग मौजूद रहता है। LZO से LZ4 पर जाना एल्गोरिद्म और फ़्रेमिंग बदलता है, वह तंत्र नहीं।
इसलिए ईमानदार ढाँचा इस बारे में है कि आप क्या अनुमति देने को तैयार हैं, न कि अभी कौन सा एल्गोरिद्म अनुशंसित है। सख्त इनकार ही एकमात्र विकल्प है जो दूसरे पक्ष के सहयोग पर निर्भर नहीं है।
केवल प्राप्ति एक माइग्रेशन अवस्था है, गंतव्य नहीं
असममित स्वीकृति इसलिए है कि एक पक्ष कम्प्रेस करना बंद कर सके जबकि दूसरा अभी भी उसकी अपेक्षा करे। यह एक पुल है, और पुलों को अंतिम तिथि और एक स्वामी चाहिए। दर्ज करें कि कौन से साथी अभी भी कम्प्रेस्ड ट्रैफ़िक भेज रहे हैं, क्योंकि नीति ठीक उसी ट्रैफ़िक की अनुमति देती है। उस सूची के बिना माइग्रेशन अवस्था जड़ता से स्थायी कॉन्फ़िगरेशन बन जाती है।
कोई क्लाइंट अपनी फ़ाइल संपादित करके असंगत सर्वर को पुरानी फ़्रेमिंग छोड़ने के लिए मजबूर नहीं कर सकता। push की दिशा सर्वर पर तय होती है, इसलिए माइग्रेशन वास्तव में सर्वर कॉन्फ़िगरेशन और प्रति-क्लाइंट फ़ाइलों में पूरा होता है।
Stub मोड फ़्रेमिंग बनाए रखते हैं पर कम्प्रेशन का काम ख़ुद छोड़ देते हैं, और वे पुराने विकल्प के सीधे समतुल्य नहीं हैं। किसी एक पर टिकने से पहले उन्हें उस सबसे पुराने साथी के सामने जाँचें जिसे अभी भी समर्थन देना है।
डेटा-चैनल offload कहाँ उत्तर बदलता है
डेटा-चैनल offload पैकेट प्रबंधन को कर्नेल में ले जाता है, और जो प्रोफ़ाइल अभी भी कम्प्रेशन फ़्रेमिंग पर निर्भर है वह उस पथ में फ़िट नहीं बैठ सकता। विफलता हमेशा ज़ोरदार नहीं होती: क्लाइंट जुड़ता है और फिर उस टनल से अलग व्यवहार करता है जिसे आपने जाँचा था।
बदलाव से पहले और बाद में कौन सा कार्यान्वयन सक्रिय है, यह जाँचें, केवल यह नहीं कि कनेक्शन सफल होता है। जब offload पथ कम्प्रेशन फ़्रेमिंग से इनकार करता है, तो सख्त इनकार नीति और offload परिनियोजन सहमत होते हैं, जबकि अनुमतिपरक नीति और offload परिनियोजन सहमत नहीं होते।
यह संयोजन अपनी अलग जाँच का हक़दार है, क्योंकि ठीक वहीं सही दिखने वाली फ़ाइल चुपचाप वह फ़ाइल नहीं होती जो उपयोग में है। प्रोफ़ाइल में दर्ज इरादे से बातचीत की गई स्थिति की तुलना करें, क्योंकि दोनों में से केवल एक ही लॉग में दिखती है।
नीति चुनें, फिर बातचीत किया गया परिणाम सत्यापित करें
जब दोनों सिरे बदल सकें तो सख्त इनकार चुनें, जब अभी नहीं कर सकें तो असममित स्वीकृति, और पूर्ण कम्प्रेशन केवल तब जब आप बता सकें कि एक्सपोज़र क्यों स्वीकार्य है। फिर यह सत्यापित करें कि क्या तय हुआ, न कि फ़ाइल क्या कहती है। शांत लॉग तभी प्रमाण है जब वह उस नीति से मेल खाता है जिसे आप परिनियोजित करना चाहते थे।
निर्णय को उस प्रोफ़ाइल के पास रखें जिस पर वह लागू होता है, तिथि और अब भी छूट प्राप्त साथियों के साथ। छह महीने बाद वही टिप्पणी जानबूझकर किए गए अपवाद और ऐसी दुर्घटना के बीच का अंतर है जिसकी तिथि कोई नहीं बता सकता। इसे प्रोफ़ाइल वाले ही रिपॉज़िटरी में लिखें ताकि अगला संपादक निर्देश से पहले कारण देख सके।