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 பயன்படுத்தலும் ஒத்துப்போகவில்லை.
அந்தக் கலவைக்கு தனிச் சோதனை தேவை, ஏனெனில் சரியாகத் தெரியும் கோப்பு அமைதியாக பயன்பாட்டில் உள்ள கோப்பு அல்லாதது அங்கேதான். ஒப்புக்கொள்ளப்பட்ட நிலையை சுயவிவரத்தில் பதிவு செய்யப்பட்ட நோக்கத்துடன் ஒப்பிடுங்கள், ஏனெனில் இரண்டில் ஒன்று மட்டுமே பதிவில் தெரிகிறது.
ஒரு கொள்கையைத் தேர்ந்தெடுத்து, பின்னர் ஒப்புக்கொள்ளப்பட்ட முடிவைச் சரிபார்க்கவும்
இரு முனைகளையும் மாற்ற முடிந்தால் கடுமையான மறுப்பை, இன்னும் முடியவில்லை என்றால் சமச்சீரற்ற ஏற்பை, வெளிப்பாடு ஏன் ஏற்றுக்கொள்ளத்தக்கது என்று விளக்க முடிந்தால் மட்டும் முழு சுருக்கத்தைத் தேர்ந்தெடுங்கள். பின்னர் கோப்பு என்ன சொல்கிறது என்பதல்ல, என்ன ஒப்புக்கொள்ளப்பட்டது என்பதைச் சரிபார்க்கவும். அமைதியான பதிவு நீங்கள் பயன்படுத்த விரும்பிய கொள்கையுடன் பொருந்தினால் மட்டுமே சான்று.
முடிவை அது பொருந்தும் சுயவிவரத்தின் அருகில், தேதி மற்றும் இன்னும் விலக்கப்பட்ட துணைவர்களுடன் வைத்திருங்கள். ஆறு மாதங்களுக்குப் பிறகு அந்தக் குறிப்பே வேண்டுமென்றே செய்யப்பட்ட விதிவிலக்குக்கும் யாரும் தேதி சொல்ல முடியாத விபத்துக்கும் இடையிலான வேறுபாடு. சுயவிவரத்தின் அதே களஞ்சியத்தில் அதை எழுதுங்கள், அடுத்த ஆசிரியர் அறிவுறுத்தலுக்கு முன் காரணத்தைப் பார்ப்பார்.