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 |
Што значи no кај старата LZO опција
Кај застарената LZO опција no ја исклучува компресијата за локалната страна без да ѝ забрани на другата страна да ја вклучи таму каде политиката дозволува. Токму поради таа асиметрија преместувањето на профил на строго одбивање го менува однесувањето на начини што лабораториски тест со еден сервер можеби никогаш нема да ги открие.
Безбедносната грижа е условна, не апсолутна. Кога напаѓач може да постави избран отворен текст покрај тајна и да набљудува како компресијата ја менува големината на шифрираниот сообраќај, постои информациски канал. Преминот од LZO на LZ4 го менува алгоритмот и рамката, не тој механизам.
Затоа чесната рамка се однесува на тоа што сте подготвени да дозволите, а не на тоа кој алгоритам моментално се препорачува. Строгото одбивање е единствената опција што не зависи од соработката на другата страна.
Самото примање е состојба на миграција, не цел
Асиметричното прифаќање постои за да може едната страна да престане да компресира додека другата сѐ уште го очекува тоа. Тоа е мост, а мостовите бараат датум на завршување и сопственик. Забележете кои партнери сѐ уште праќаат компресиран сообраќај, зашто политиката дозволува токму таков сообраќај. Без тој список состојбата на миграција од инерција станува постојана конфигурација.
Клиентот не може да присили некомпатибилен сервер да го напушти старото рамкирање со уредување на сопствената датотека. Правецот на push се одлучува на серверот, па миграцијата всушност завршува во конфигурацијата на серверот и неговите датотеки по клиент.
Stub режимите ја задржуваат рамката, но ја прескокнуваат самата компресија и не се директен еквивалент на постарата опција. Тестирајте ги со најстариот партнер што сѐ уште треба да го поддржувате пред да се одлучите за еден.
Каде offload на податочниот канал го менува одговорот
Offload на податочниот канал ја преместува обработката на пакетите во јадрото, а профил што сѐ уште зависи од рамката за компресија може да не се вклопи во тој пат. Дефектот не е секогаш гласен: клиентот се поврзува и потоа се однесува поинаку од тунелот што сте го тестирале.
Проверете која имплементација е активна пред и по промената, не само дали врската успева. Кога патот со offload ја одбива рамката за компресија, строгата политика на одбивање и распоредувањето со offload се согласуваат, додека дозволувачката политика и распоредувањето со offload не.
Таа комбинација заслужува сопствен тест, зашто токму таму датотеката што изгледа исправно тивко не е онаа што се користи. Споредете ја преговараната состојба со намерата запишана во профилот, зашто само едната од двете е видлива во дневник.
Изберете политика, потоа проверете го преговараниот резултат
Изберете строго одбивање кога можете да ги смените двете страни, асиметрично прифаќање кога сѐ уште не можете, и целосна компресија само кога можете да објасните зошто изложеноста е прифатлива. Потоа проверете што е преговарано, а не што вели датотеката. Помалку бучниот дневник е доказ само кога се совпаѓа со политиката што планиравте да ја распоредите.
Држете ја одлуката покрај профилот на кој се однесува, со датумот и партнерите што сѐ уште се изземаат. По половина година таа белешка е разликата меѓу намерен исклучок и незгода што никој не може да ја датира. Запишете ја во истото складиште како профилот, за следниот уредник да ја види причината пред директивата.