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 तैनाथी मिल्दैनन्।
त्यो संयोजन आफ्नै परीक्षणको योग्य छ, किनभने ठीक त्यहीँ सही देखिने फाइल चुपचाप प्रयोगमा रहेको फाइल नहुन सक्छ। प्रोफाइलमा अभिलेख गरिएको मनसायसँग वार्ता भएको अवस्था तुलना गर्नुहोस्, किनभने दुईमध्ये एउटा मात्र लगमा देखिन्छ।
नीति रोज्नुहोस्, त्यसपछि वार्ता भएको नतिजा प्रमाणित गर्नुहोस्
दुवै छेउ बदल्न सक्नुहुन्छ भने कडा अस्वीकार, अझै सक्नुहुन्न भने असमान स्वीकार, र एक्स्पोजर किन स्वीकार्य छ भन्न सक्नुहुन्छ भने मात्र पूर्ण कम्प्रेसन रोज्नुहोस्। त्यसपछि फाइलले के भन्छ होइन, के वार्ता भयो त्यो प्रमाणित गर्नुहोस्। शान्त लग त्यतिबेला मात्र प्रमाण हो जब तपाईंले तैनाथ गर्न खोज्नुभएको नीतिसँग मिल्छ।
निर्णयलाई त्यो लागू हुने प्रोफाइलको छेउमा, मिति र अझै छुट पाएका साथीहरूसहित राख्नुहोस्। छ महिनापछि त्यो टिप्पणी नै जानाजान गरिएको अपवाद र कसैले मिति भन्न नसक्ने दुर्घटनाबीचको फरक हो। प्रोफाइलकै उही रिपोजिटरीमा लेख्नुहोस्, ताकि अर्को सम्पादकले निर्देशनअघि कारण देखोस्।