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