Rekeying в VPN по-взрослому: как часто менять ключи и зачем это спасает сеть

Введение: rekeying в VPN без скуки, но с практической пользой

Что вообще такое rekeying простыми словами

Rekeying в VPN — это запланированная и аккуратная смена рабочих криптографических ключей, которыми шифруется ваш трафик. Представьте, что у вас есть переговорная комната. Мы закрываем дверь на ключ, немного беседуем, а потом, не прерывая диалог, меняем замок на новый. Никто посторонний не войдет, разговор не оборвется, а безопасность вырастет. Вот и вся магия. Только вместо замков — криптографические ключи, а вместо дверей — туннели IPsec, WireGuard или OpenVPN.

Зачем нам эта суета? Ответ простой: ключи стареют. Чем дольше они используются и чем больше данных шифруют, тем выше риск. От банального истощения энтропии и повторного использования неудачных параметров до серьезных угроз при попытках криптоанализа и утечек. Регулярный rekeying снижает поверхность атаки и делает ваши туннели максимально стойкими к взлому, даже если один из ключей когда-то «засветится».

Лично мне нравится сравнение с ремнями безопасности: вроде все спокойно, но вы пристегиваетесь, потому что это разумно. Точно так же и с ротацией ключей. Это привычка, которая однажды просто спасает.

Где именно он происходит: IPsec, WireGuard, OpenVPN и TLS VPN

В реальной жизни rekeying — это не одна вещь, а целое семейство механизмов. В IPsec (особенно с IKEv2) есть жизненные циклы для SA (Security Association): IKE_SA и CHILD_SA. Они управляют, когда и как обновляются ключи и параметры шифрования. В WireGuard ротация происходит прозрачно на основе времени и объема сообщений, почти без настроек. В OpenVPN мы гибко задаем reneg-sec или reneg-bytes, чтобы обновлять ключи по времени или количеству данных. Даже в TLS VPN и QUIC с 1-RTT парадигмой можно управлять пересозданием сессионных секретов, чтобы держать модель угроз под контролем.

Снаружи это выглядит как стабильный туннель. Внутри — оркестровка короткоживущих сеансов, обменов и хендшейков. И это отлично: нам не нужны «вечные» ключи. Нам нужны живые, быстро обновляемые и от этого более безопасные.

Термины без боли: сессионные ключи, перехват, рукопожатия

Давайте быстро разберем базовые термины, чтобы говорить на одном языке. Сессионный ключ — это временный секрет, которым шифруется текущий поток данных. ИKE_SA — канал управления в IKEv2 для обмена параметрами и ключевым материалом, а CHILD_SA — конкретные политики и ключи для шифрования пользовательского трафика. Рекейинг — процесс перевыпуска таких ключей. Ренег — почти то же самое в терминологии OpenVPN и TLS.

Рукопожатие (handshake) — это момент, когда стороны договариваются о параметрах и генерируют секреты. В идеале, с использованием диффи-хеллмана или его эллиптических вариантов, дающих нам пресловутую Perfect Forward Secrecy (PFS). Если говорить по-человечески, PFS означает: даже если кто-то украдет ваш долгоживущий ключ, он все равно не сможет прочитать прошлый трафик. Красота.

Ошибки восприятия: «у меня и так все шифруется, зачем усложнять»

Часто слышу: «Да у нас уже AES-256, чего дергаться?». Но один алгоритм не спасает от плохой операционки. Если вы шифруете месяцами одним и тем же набором ключей, вы создаете жирную цель для атакующего и повышаете вероятность криптоошибок. Или другая иллюзия: «Rekeying все роняет». Неправда, если настроить грамотно. Современные стековые реализации меняют ключи без простой и без разрывов туннеля, благодаря перекрывающимся жизненным циклам ассоциаций.

Третья ошибка — ставить чрезмерно агрессивные интервалы «ради безопасности», не считаясь с инфраструктурой. В результате — лишняя нагрузка, лишние рукопожатия, а на мобильных клиентах — проседание батареи. Баланс, только баланс. Именно ради этого и пишется это руководство.

Криптографическая основа rekeying: на чем держится безопасность

Энтропия, PRNG и диффи-хеллман: кратко о главном

Любая ротация ключей опирается на качественные случайные числа. Хороший PRNG и достаточная энтропия — фундамент. Плохая генерация случайности бьет по безопасности сильнее, чем устаревший алгоритм. Поэтому в 2026 году нормой стало использовать системные источники (например, современные ядра Linux предоставляют быстрые и криптостойкие источники случайности) и дополнительные аппаратные энтропийные модули там, где это критично: в HSM, SGX или TPM.

Обмен на базе Диффи–Хеллмана (DH) или ECDH создает общий секрет без передачи его по сети. Выбор группы — вопрос баланса. Модные эллиптические кривые вроде Curve25519 или NIST P-256 быстры и достаточно надежны для большинства случаев, а группы MODP высокой степени обеспечивают совместимость в IPsec-наследии.

Perfect Forward Secrecy: почему без нее никуда

PFS — ключевая идея. Если злоумышленник добудет ваш долгоживущий ключ (например, ключ сервера или сертификат), он не расшифрует прошлые сессии, потому что для каждой сессии применялась свежая диффи-хеллман-эпемералка и были созданы уникальные краткоживущие ключи. Это то, что реально спасает ретроспективу: ваши вчерашние разговоры не станут общедоступными завтра. Звучит как магия, но это просто здоровая криптографическая гигиена.

В контексте rekeying PFS усиливает смысл ротации: каждая новая сессия и даже каждая новая CHILD_SA не наследует уязвимость прошлого. Секреты живут недолго, не застаиваются и «не пахнут» для аналитика, который мечтает собрать огромную матрицу шифротекста и найти закономерности.

AEAD, повтор nonces и риск больших объемов данных

Современные шифры AEAD вроде AES-GCM и ChaCha20-Poly1305 требуют осторожности с нонсами. Повтор nonce для одного ключа критичен: это не просто «плохо», это путь к компрометации целостности. Поэтому производители и сообщества закладывают лимиты на объемы и количество пакетов, после которых нужно обновлять ключ. Отсюда вырастают «Rekey-After-Messages» или «reneg-bytes».

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

Когда и зачем менять ключи: практические критерии

Пределы по объему и количеству пакетов

Сколько данных должен «прожевать» один ключ, прежде чем уйти на пенсию? В 2026 году хорошие практики для AEAD рекомендуют ориентироваться на пределы уровней гигабайт, а не десятков терабайт, особенно если трафик однообразный или у вас высокие пиковые потоки. В WireGuard вычисление идет по сообщениям (пакетам), а в OpenVPN удобно задавать байтовые лимиты. IPsec же традиционно опирается на lifebytes, если вы хотите контролировать именно объем.

Здравый смысл такой: как только приближаетесь к верхним границам для безопасного использования конкретного шифра и nonce-политики, инициируйте rekeying. Не держите ключи «под нагрузкой» слишком долго. Это не «перестраховка», а нормальная эксплуатация.

Пределы по времени: lifetimes и окна перехвата

Второй ориентир — время. Даже если трафик невелик, ключи должны жить ограниченно. Многие организации выбирают интервалы 30-60 минут для пользовательских туннелей и 2-8 часов для магистральных S2S. Зачем? Уменьшаем окно, когда компрометация способна навредить. Мы сознательно урезаем период, в котором один секрет может стать единой точкой отказа для анализа трафика.

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

Инциденты, компрометация и гуманная ротация

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

Также есть «гуманная ротация» — плановые окна, когда вы снижаете время жизни ключей во время пиковых угроз (например, предполагаемых кампаний атак) и возвращаете более щадящий режим позже. Эти временные меры помогают пройти турбулентность без стресса для пользователей.

Автоматический rekeying: как это выглядит в популярных стэках

IPsec IKEv2: lifetimes, rekeymargin, reauth и DPD

В IPsec с IKEv2 мы настраиваем lifetime для CHILD_SA (обычно в секундах) и запасное окно rekeymargin, в котором начинается мягкое перевыпуск ключей до истечения срока. Добавим rekeyfuzz, чтобы не все туннели уходили на обновление одновременно, и получим стабильную, «не дергающуюся» систему. Важно понимать разницу между rekey и reauth: первое меняет ключи для того же сеанса, второе полностью переаутентифицирует. В большинстве сценариев rekey достаточно.

Плюс не забываем DPD (Dead Peer Detection) и MOBIKE для мобильности. DPD гарантирует, что зависшие стороны не ломают цикл ротации, а MOBIKE помогает пережить смену IP при роуминге, не теряя туннель и ритм rekeying.

WireGuard: минимум настроек, максимум практичности

WireGuard славится простотой: протокол сам применяет «Rekey-After-Seconds» и «Rekey-After-Messages», а также учитывает «Keepalive» для обхода NAT. По сути, он обязывает ключи жить недолго и не перерабатывать. Можно сказать, rekeying «вшит в ДНК» WireGuard, поэтому отдельные ручки для тонкой настройки ограничены. И честно — большинству этого хватает.

Практический совет: следите за метриками «latest handshake» и количеством пересозданий. Если видите аномалии или провалы при пиках нагрузки, корректируйте инфраструктуру — MTU, QoS, CPU, но не пытайтесь «выключить» ротацию. Она — не виновата, она — ваш друг.

OpenVPN: гибкая классика для смешанных сред

OpenVPN дает богатый набор опций: reneg-sec, reneg-bytes, reneg-pkts. На практике чаще всего ставят время в диапазоне 1800-3600 секунд, а для особо шумных каналов — лимиты по объему. Если используется tls-crypt-v2, добавляется защита от метаданных на уровне TLS, а полноценная PFS достигается при ECDHE-рукопожатиях.

Совет из жизни: синхронизируйте сервер и клиенты по времени (NTP), иначе ренег может случаться не там и не так, как задумано. Мелочь, но она «стреляет» в самый неожиданный момент.

Влияние rekeying на соединение и производительность

Нулевые простои: как достичь seamless-обновления

Правильно выполненный rekeying не рвет сессию. В IKEv2 старый CHILD_SA еще работает, пока новый уже установлен и принял трафик. В OpenVPN два ключа могут некоторое время сосуществовать, а в WireGuard переключение настолько быстрое, что пользователь его не замечает. Это как в Formula 1: быстрая смена шин во время пит-стопа — машина даже не успевает остыть.

Ключ к «безболезненности» — корректные окна пересечения, надежный канал управления и прогнозируемые интервалы. Плюс аккуратный MTU, чтобы не попасть в ловушки фрагментации именно в момент хендшейка.

Мобильность, NAT и роуминг: где тонко и рвется

Самый коварный момент — мобильные клиенты за NAT, которые скачут между сетями. MOBIKE в IKEv2 и keepalive в WireGuard помогают, но при слишком агрессивном rekeying вы получите лишние рукопожатия и «встряску» у абонента. Компромисс: не ставить экстремальные интервалы на мобильных профилях, а подстраивать их под реальную логику передвижения пользователей.

Практика показывает, что 45-60 минут для мобильных — сладкая точка, если нет сверхсекретного трафика. А еще важна корректная настройка NAT-T и запрет на «обрезание» UDP тайм-аутами посередине процедуры обновления.

CPU, батарея и стоимость рукопожатий

Каждое рукопожатие — это CPU-время и, на клиентских устройствах, батарея. В 2026 году даже смартфоны легко переваривают ECDH, но если у вас тысяча клиентов и агрессивный график rekeying, суммарная нагрузка может удивить. Мониторинг тут решает. Смотрите пиковые значения во время массовых обновлений, распределяйте окна (fuzz), и используйте профили шифров, где аппаратные ускорения работают по максимуму (AES-NI, ARMv8 Crypto Extensions).

И не забывайте про сервера. Узкие горлышки на стороне концентратора — частая причина микроразрывов во время rekey, и виноват не протокол, а банально недостаток ресурсов под спайки хендшейков.

Как выбрать интервалы rekeying в 2026: свежие практики

Нормативы и комплаенс: PCI DSS, ISO 27001, отраслевые гайды

Точные цифры редко прописаны в стандартах, но дух требований очевиден: минимизируйте окно компрометации и обеспечьте PFS. В 2026 году многие аудиторы смотрят на «короткоживущие ключи» как на норму. В финтехе типично 15-30 минут для пользовательских сессий и до 2 часов для бэкбон-каналов. В гос-секторе часто строже, но зависит от классификации данных.

Главное — задокументировать политику: какие интервалы, почему такие, как мониторим, как реагируем на инциденты. Наличие внятной политики иногда важнее, чем разница между 30 и 45 минутами.

Алгоритмы и профили шифров: AES-GCM vs ChaCha20-Poly1305

На железе с AES-NI—AES-GCM превосходен. На мобильных и ARM-платформах ChaCha20-Poly1305 часто быстрее и стабильнее. Выбор шифра влияет на стоимость rekeying, потому что именно на нем считаются хендшейки и шифрование трафика. Если вы используете ECDHE с Curve25519, получаете отличный баланс скорости и безопасности. Для IPsec обращайте внимание на группы DH и совместимость с peer, не тяните устаревшие MODP 1024.

Также подумайте о квантово-устойчивых гибридах в горизонте 2026–2027: некоторые вендоры внедряют гибриды ECDH+Kyber на стадии экспериментов и пилотов. Это не «волшебная таблетка», но уже пора включить в дорожную карту.

Типовые профили интервалов: S2S, Remote Access, DevOps, IoT

Рассмотрим усредненные профили, которые часто «заходят» в проде:

• S2S (магистраль): rekey 1-2 часа, rekeymargin 5-10 минут, lifebytes ограничен умеренно. При высокой плотности трафика — час.
• Remote Access: 30-60 минут, без экстремальных значений. На мобильных клиентах чаще 45-60 минут.
• DevOps/CI: короткие сессии, 15-30 минут — удобно для ephemeral-инфраструктуры и быстрых конвейеров.
• IoT: зависит от мощности. Для слабых устройств безопаснее увеличить интервал, но держать лимиты по объему данных. Например, 2-4 часа и ограничение по байтам.

Это не догма. Подстраивайте под топологию, железо и привычки пользователей. Никакая рекомендация извне не заменит вашу телеметрию.

Настройка на пальцах: примеры конфигураций без воды

IPsec IKEv2 strongSwan: базовый пример

В strongSwan вы задаете lifetimes в conn-профилях. Типично: lifetime 1h, rekeymargin 5m, rekeyfuzz 10 percent, dpdaction=restart, dpddelay=30s. Такой профиль обеспечивает мягкое обновление, упреждает истечение и обеспечивает устойчивость к «зависаниям» peer. При интенсивном трафике добавляйте ограничения по lifebytes, если требуется контролировать объем.

Полезная привычка: логируйте начало и завершение rekeying. На графиках станет видно, где у вас нежелательные синхронные пики и кто является «тяжелым» участником.

WireGuard: надежный минимум

WireGuard почти не требует ручной настройки ротаций: встроенные значения «Rekey-After-Seconds» и «Rekey-After-Messages» уже разумны. В бою часто добавляют PersistentKeepalive=25 на клиентах за NAT, чтобы туннель не остывал, и следят за «latest handshake». Если видите паузы при высокой нагрузке, проверьте MTU и качество канала, а не пытайтесь «растянуть» жизнь ключа.

И не забывайте про ограничение разрешений в конфиге (AllowedIPs — по минимуму). Это не напрямую про rekeying, но уменьшает последствия, если что-то пойдет не так.

OpenVPN: гибкая ротация по времени и объему

Реалистичный сетап: reneg-sec 1800, reneg-bytes 512m, tls-version-min 1.3, cipher AES-256-GCM или Chacha20-Poly1305, tls-crypt-v2 включен. Для серверов с высокой плотностью клиентов добавляйте «explicit-exit-notify» и следите за «auth-nocache» по требованиям безопасности. Балансируйте reneg-параметры, чтобы не вызывать массовые «переключки» одновременно.

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

Диагностика и отладка rekeying: как понять, что все хорошо

Логи и коды ошибок: ваш лучший друг

В IPsec смотрите события IKE_SA rekey, CHILD_SA rekey, предупреждения о lifetimes и DPD. В WireGuard — внимательно «wg show» и системные логи о рукопожатиях и переустановках. В OpenVPN — моменты reneg и возможные ошибки при пересоздании сессии. Если видите повторные попытки и таймауты — ищите узкие места в канале управления и на CPU.

Закладывайте структурированное логирование: метки времени, идентификаторы туннелей, счетчики пакетов. Так вы быстрее найдете место, где «стреляет» и что конкретно ломается.

Частые грабли: несоответствие lifetimes, NAT-T и фрагментация

Классика жанра: lifetimes на концах различаются настолько, что стороны не могут согласовать окно rekey без паузы. Решение простое — привести к одному знаменателю или дать достаточно rekeymargin. Второй враг — NAT-T с короткими тайм-аутами, который выгрызает контрольные пакеты. Увеличьте keepalive и проверьте stateful-файрволлы.

И осторожнее с MTU. В момент рукопожатия большие пакеты могут фрагментироваться и теряться, особенно в туннель-в-туннеле. Понизьте MTU на 60-80 байт и проверьте, как меняется стабильность в момент rekey.

Инструменты: tcpdump, Wireshark, профилирование

Ничто не заменит «tcpdump -ni any udp port 500 or udp port 4500» для IPsec и захват трафика управления. В WireGuard полезны счетчики и временные метки рукопожатий. В OpenVPN выручает повышенный уровень verb и ключевые события reneg. В 2026 году множатся готовые дашборды в системах наблюдаемости: соберите метрики по рукопожатиям, latencies и отказам именно в окна rekey.

Простой чек: делаете ручной rekey на тестовом туннеле и замеряете RTT и потери. Если показатели стабильны, значит конфигурация здорова.

Безопасность, комплаенс и квантовый горизонт

Гибридные схемы и PQC: взгляд на 2026

Квантовые угрозы не стучатся завтра, но дорожная карта нужна уже сегодня. В 2026-м часть вендоров экспериментирует с гибридами ECDH+Kyber для IKEv2 и TLS, где классическая эллиптическая криптография сочетается с квантово-устойчивой KEM. Это не означает немедленную миграцию, но разумно готовить профиль «на будущее»: тестовые лаб-сценарии, оценка производительности, совместимость с железом и HSM.

Плюс к этому — короткоживущие ключи и PFS. Даже если завтра появится продвинутая атака на конкретную кривую, ваш прошлый трафик останется защищенным благодаря частому rekeying. Это не панацея, но мощный слой обороны.

Zero Trust и короткие сессии

В Zero Trust-архитектуре короткие сессии — правило хорошего тона. Мы не верим по умолчанию, мы постоянно подтверждаем доверие и уменьшаем последствия компрометации. Rekeying идеально ложится в эту парадигму: частые ротации ключей плюс проверка политик доступа дают минимум шансов злоумышленнику закрепиться.

В проде это означает: автоматизируйте выдачу, отзыв и обновление сертификатов, храните секреты в менеджерах, а ключи держите ephemeral. Чем меньше «вечного», тем спокойнее спится.

Ключи и память: минимизируем риски на узлах

Ротация — это не только про сеть. Это про память, где живут секреты. В идеале ключи держатся в памяти как можно короче, с нулями при освобождении и без лишних копий. HSM и enclaves добавляют слой защиты, но помните о производительности и реальной стоимости интеграции. Не превращайте безопасность в тормоз, но и не экономьте на критическом.

Управляйте доступом к файлам ключей, следите за журналированием, и не оставляйте «debug dumps» с секретами — это частая человеческая ошибка.

Кейсы из жизни: как rekeying выручил команды

Финтех: взяли и укоротили окно

Финансовая компания столкнулась с требованием аудитора: уменьшить окно возможной компрометации. Поставили rekey 20 минут на клиентских сессиях и 1 час на S2S. Сначала боялись «штормов», но включили rekeyfuzz и распределили окно. Результат: нагрузка почти не изменилась, а соответствие требованиям выросло. Плюс приятный бонус — следы инцидентов стало легче ограничивать во времени, когда появились четкие «нарезки» трафика.

Люди остались довольны: пользователи ничего не заметили, а команда безопасности расслабила плечи.

Производство и IoT: компромисс без боли

Заводская сеть с IoT-узлами страдала от частых ротаций — слабые процессоры, долгое рукопожатие, иногда — замирание. Решили перейти на профили с 2-3 часами и лимитами по объему, а критические узлы перевели на облегченную криптографию с аппаратными ускорениями. В итоге rekey стал редким, но строго контролируемым событием. Безопасность не пострадала, а стабильность выросла.

Вывод простой: не все должны жить по одному графику. Тонкая настройка по классам устройств — наше все.

Удаленная команда: мобильность без сюрпризов

У международной компании множество мобильных сотрудников. На старте поставили агрессивные 15 минут и поймали «качели» при смене Wi-Fi и LTE. Перенастроили на 45 минут, поправили Keepalive и MTU, включили MOBIKE. Стало тихо и спокойно, разрывы исчезли, а безопасность осталась на уровне благодаря PFS и регулярным обновлениям.

Вот вам и «золотая середина». Иногда меньше — не лучше, а хуже.

Чек-листы и лучшие практики: быстрое внедрение

Десять правил, которые экономят нервы

• Всегда включайте PFS.
• Используйте короткие, но разумные lifetimes.
• Разносите пики rekey с помощью margin и fuzz.
• Следите за MTU и фрагментацией, особенно при хендшейках.
• Учитывайте мобильность: MOBIKE и keepalive — не роскошь.
• Мерьте, а не гадайте: метрики хендшейков и отказов.
• Оптимизируйте шифры под железо (AES-NI, ARMv8).
• Храните секреты аккуратно, избегайте «вечных» ключей.
• Планируйте PQC-гибриды в RnD.
• Документируйте политику и обновляйте ее раз в полгода.

Контрольные вопросы для вашей команды

• Знаем ли мы текущие интервалы и почему выбрали именно их
• Как часто у нас происходят rekey и где их больше всего
• Есть ли у нас пики одновременных рукопожатий
• Мониторим ли мы ошибки и ретраи при rekey
• Готовы ли мы к мобильным сценариям и NAT
• Проводили ли мы «ручной rekey-тест» в рабочее время

План внедрения за неделю

День 1: инвентаризация туннелей и текущих интервалов. День 2: пилот на одном сегменте, включение PFS, корректные lifetimes. День 3: мониторинг и легкая коррекция MTU. День 4: включение rekeymargin и fuzz, распределение пиков. День 5: проверка логов, ретраи, стабильность. День 6: масштабирование на остальные сегменты. День 7: фиксация политики и графиков, обучение команды.

Не идеально? И не надо. Главное — сделать первый шаг и не бояться корректировать курс.

Часто задаваемые вопросы

Нужно ли делать rekeying, если у нас уже AES-256 и TLS 1.3

Да, нужно. Сильный шифр — это база, но операционная стойкость достигается короткими сессиями и PFS. Rekeying снижает окно компрометации и ограничивает объем данных на ключ, что важно для AEAD. Даже в TLS 1.3, где безопасность значительно выросла, ротация сессионных секретов остается разумной практикой, особенно для длительных соединений и высоконагруженных сервисов.

Как часто менять ключи на мобильных клиентах, чтобы не было разрывов

Практическая рекомендация — 45-60 минут для Remote Access. Это баланс между безопасностью и стабильностью при роуминге. Добавьте keepalive и MOBIKE для IKEv2, проверьте MTU. Поставите 15 минут — добьетесь более частых рукопожатий и возможных «качелей» при переходах между сетями. Чуть реже — и вы спокойно проживете пересадки между Wi-Fi и LTE без потерь.

Сколько данных можно шифровать одним ключом без риска для AEAD

Единой цифры для всех нет, зависит от шифра и реализации. Консервативный подход — не перешагивать пределы в несколько сотен гигабайт на сессию при AES-GCM и помнить о «Rekey-After-Messages» в WireGuard. Если у вас большой агрегированный поток, особенно повторяющийся, лучше снижать порог и чаще ротировать. В сомнительных случаях ограничивайте и по времени, и по объему одновременно.

Влияет ли rekeying на производительность и задержки

Да, но при грамотной конфигурации это влияние минимально и незаметно пользователю. Ключевые элементы: rekeymargin, разнесение по времени, корректный MTU, достаточные ресурсы CPU на концах. На практике при lifetimes 30-60 минут и аппаратных ускорениях overhead часто не выходит за пределы статистической погрешности.

Нужно ли делать reauth или достаточно rekey

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

Как готовиться к квантовой эре в контексте VPN

Сегодня — PFS и короткоживущие ключи. Завтра — пилоты с гибридными схемами (например, ECDH+Kyber) там, где это возможно. Начинайте с лабораторных тестов, проверяйте совместимость, измеряйте накладные расходы. Не бросайтесь в омут с головой, но и не откладывайте на «когда-нибудь». План на 12-18 месяцев вперед — разумный горизонт для крупных сетей.