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 ડિપ્લોયમેન્ટ મળતાં નથી.
એ સંયોજન પોતાની અલગ ચકાસણીને લાયક છે, કારણ કે બરાબર ત્યાં જ સાચી દેખાતી ફાઇલ ચૂપચાપ એ ફાઇલ નથી હોતી જે વપરાય છે. પ્રોફાઇલમાં નોંધાયેલા ઇરાદા સાથે વાટાઘાટ થયેલી સ્થિતિની તુલના કરો, કારણ કે બેમાંથી ફક્ત એક જ લોગમાં દેખાય છે.
એક નીતિ પસંદ કરો, પછી વાટાઘાટ થયેલું પરિણામ ચકાસો
બંને છેડા બદલી શકો ત્યારે કડક નકાર પસંદ કરો, હજી ન શકો ત્યારે અસમપ્રમ સ્વીકાર, અને પૂર્ણ કમ્પ્રેશન ફક્ત ત્યારે જ જ્યારે તમે કહી શકો કે એક્સપોઝર કેમ સ્વીકાર્ય છે. પછી ફાઇલ શું કહે છે તેને બદલે શું વાટાઘાટ થયું તે ચકાસો. શાંત લોગ ફક્ત ત્યારે જ પુરાવો છે જ્યારે તે તમે ડિપ્લોય કરવા માંગતા હતા તે નીતિ સાથે મેળ ખાય.
નિર્ણયને જે પ્રોફાઇલ પર તે લાગુ પડે છે તેની બાજુમાં રાખો, તારીખ અને હજી મુક્તિ મેળવેલા સાથીઓ સાથે. છ મહિના પછી એ નોંધ જ જાણી જોઈને કરેલા અપવાદ અને કોઈ તારીખ ન કહી શકે એવા અકસ્માત વચ્ચેનો તફાવત છે. તેને પ્રોફાઇલ સાથે જ સમાન રિપોઝિટરીમાં લખો, જેથી આગલો સંપાદક સૂચના પહેલાં કારણ જોઈ શકે.