Сжатие в 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 — нет.
Это сочетание заслуживает отдельного теста, потому что именно там файл, который выглядит правильным, молча оказывается не тем, который используется. Сравните согласованное состояние с намерением, записанным в профиле, потому что только одно из них видно в журнале.
Выберите политику, затем проверьте согласованный результат
Выбирайте строгий отказ, когда можно изменить обе стороны, асимметричный приём, когда это пока невозможно, и полное сжатие только тогда, когда можете объяснить, почему экспозиция приемлема. Затем проверьте, о чём договорились, а не то, что написано в файле. Более тихий журнал — доказательство только тогда, когда он соответствует политике, которую вы собирались применить.
Держите решение рядом с профилем, к которому оно относится, с датой и партнёрами, которые всё ещё освобождены. Через полгода эта заметка — разница между намеренным исключением и происшествием, которое никто не может датировать. Напишите её в том же репозитории, что и профиль, чтобы следующий редактор увидел причину до директивы.