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 വിന്യാസവും യോജിക്കുന്നില്ല.
ആ സംയോജനത്തിന് സ്വന്തം പരിശോധന അർഹമാണ്, കാരണം ശരിയായി തോന്നുന്ന ഫയൽ നിശബ്ദമായി ഉപയോഗത്തിലുള്ള ഫയൽ അല്ലാതാകുന്നത് കൃത്യമായി അവിടെയാണ്. ചർച്ച ചെയ്ത അവസ്ഥയെ പ്രൊഫൈലിൽ രേഖപ്പെടുത്തിയ ഉദ്ദേശവുമായി താരതമ്യം ചെയ്യുക, കാരണം രണ്ടിൽ ഒന്ന് മാത്രമാണ് ലോഗിൽ കാണുന്നത്.
ഒരു നയം തിരഞ്ഞെടുത്ത്, പിന്നീട് ചർച്ച ചെയ്ത ഫലം പരിശോധിക്കുക
രണ്ട് അറ്റങ്ങളും മാറ്റാൻ കഴിയുമ്പോൾ കർശന വിസമ്മതം, ഇപ്പോഴും കഴിയാത്തപ്പോൾ അസമമിത സ്വീകരണം, എക്സ്പോഷർ എന്തുകൊണ്ട് സ്വീകാര്യമെന്ന് പറയാൻ കഴിയുമ്പോൾ മാത്രം പൂർണ്ണ കംപ്രഷൻ എന്നിവ തിരഞ്ഞെടുക്കുക. പിന്നീട് ഫയൽ പറയുന്നതല്ല, ചർച്ച ചെയ്തത് പരിശോധിക്കുക. നിങ്ങൾ വിന്യസിക്കാൻ ഉദ്ദേശിച്ച നയവുമായി യോജിക്കുമ്പോൾ മാത്രമാണ് ശാന്തമായ ലോഗ് തെളിവ്.
തീരുമാനം അത് ബാധകമാകുന്ന പ്രൊഫൈലിന് അടുത്ത്, തീയതിയും ഇപ്പോഴും ഒഴിവാക്കപ്പെട്ട പങ്കാളികളുമായി സൂക്ഷിക്കുക. അര വർഷത്തിന് ശേഷം ആ കുറിപ്പാണ് ബോധപൂർവമായ ഒഴിവാക്കലും ആർക്കും തീയതി പറയാൻ കഴിയാത്ത അപകടവും തമ്മിലുള്ള വ്യത്യാസം. പ്രൊഫൈലിന്റെ അതേ റിപ്പോസിറ്ററിയിൽ അത് എഴുതുക, അടുത്ത എഡിറ്റർ നിർദ്ദേശത്തിന് മുമ്പ് കാരണം കാണട്ടെ.