Почему больший ключ OpenVPN не отменяет таймер перевыпуска ключей

Выбор AES-256 или более длинного ключа ничего не говорит о том, как долго этот ключ можно использовать. Стойкость ключа описывает алгоритм; политика перевыпуска решает, когда сеанс получит новый ключевой материал. Развёртывание может выбрать самый стойкий доступный шифр и всё равно ошибиться с обновлением, потому что эти два решения принимаются в разных местах. Их смешение даёт либо ненужную смену шифра, либо сеанс, который тихо переживает свою политику.

Прочитайте настройки перевыпуска, прежде чем трогать шифр, и читайте обе стороны, когда это делаете.

Стойкость ключа и срок жизни ключа отвечают на разные вопросы

Шифр и размер ключа ограничивают, насколько дорогой была бы атака на перехваченный трафик. Интервал перевыпуска ограничивает, сколько трафика защищает один ключ и как долго скомпрометированный ключ остаётся полезным. Это независимые настройки, и более стойкий шифр не продлевает безопасный срок жизни сеанса. Большинство рекомендаций «используйте AES-256» молчат об обновлении, потому что обновление — вопрос политики, а не выбора алгоритма.

Запишите и то и другое в заметки о развёртывании: что защищает канал данных и что запускает замену его ключей.

У перевыпуска три триггера, и любая сторона может их запустить

OpenVPN 2.6 документирует отдельные триггеры повторного согласования по байтам, пакетам и истёкшему времени. Триггер по времени — тот, который большинство развёртываний оставляет по умолчанию, а значит тихий туннель всё равно перевыпускает ключ по расписанию. Любая сторона может начать обмен, а сторона, которая его не начала, следует за ней. Поэтому смена таймера на одной стороне не задаёт поведение сеанса; действующим является значение той стороны, которая начинает первой.

Триггеры по байтам и пакетам важны при нагрузках с высокой пропускной способностью или мелкими пакетами, где политика только по времени позволила бы одному ключу защищать гораздо больше данных, чем задумано. Если эти счётчики остаются отключёнными, скажите об этом намеренно в заметках, а не оставляйте значение по умолчанию непроверенным.

Перевыпуск обнажает процесс аутентификации

Повторное согласование — это новое рукопожатие TLS, а значит путь аутентификации проходит снова. Развёртывания с одноразовыми кодами, аппаратными токенами или вызовом RADIUS узнают это тяжёлым путём: первое соединение работает, а через час сеанс умирает, когда второе рукопожатие запрашивает уже использованный код. auth-gen-token существует, чтобы закрыть этот пробел: сервер выдаёт краткоживущий токен для повторного согласования вместо требования нового интерактивного входа.

Относитесь к этому как к проблеме рабочего процесса, которую нужно решить с оператором, а не как к доказательству, что обновление следует отключить.

Проверяйте обновление под нагрузкой, а не в сеансе на минуту

Приёмочный тест, который подключается, один раз пингует и отключается, никогда не доходит до перевыпуска. Запустите сеанс достаточно долго, чтобы пересечь настроенный триггер, держите передачу всё это время и следите за журналами обеих сторон в поисках нового рукопожатия. Затем проверьте путь отказа: что клиент делает, если повторное согласование не удаётся завершить. Туннель, который падает чисто, диагностировать проще, чем тот, что продолжает отправлять в мёртвый сеанс.

Не читайте успешную большую передачу как доказательство криптографического порога. Она показывает лишь, что путь и счётчики выдержали такой объём трафика.

Задокументируйте оба выбора

Записи нужны две строки: как защищаются пакеты и когда эта защита заменяется. Добавьте основание для каждого значения, потому что шифр может происходить из умолчания дистрибутива, а таймер — из внутренней политики. Будущий оператор не должен выводить ни то ни другое из файла конфигурации.

Если совместимость вынуждает исключение, ограничьте его версией и датой окончания. Исключение, которое переживает свою причину, становится политикой, которую никто не помнит, что выбирал.