Компресия в 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 не.
Тази комбинация заслужава отделен тест, защото точно там файл, който изглежда правилен, тихо се оказва не този, който се използва. Сравнете договореното състояние с намерението, записано в профила, защото само едно от двете се вижда в журнала.
Изберете политика, после проверете договорения резултат
Изберете строг отказ, когато можете да промените двете страни, асиметрично приемане, когато още не можете, и пълна компресия само когато можете да кажете защо експозицията е приемлива. После проверете какво е договорено, а не какво пише файлът. По-тихият журнал е доказателство само когато съвпада с политиката, която сте възнамерявали да разгърнете.
Дръжте решението до профила, за който се отнася, с датата и партньорите, които все още са освободени. След половин година тази бележка е разликата между съзнателно изключение и инцидент, който никой не може да датира. Напишете я в същото хранилище като профила, за да види следващият редактор причината преди директивата.