Архитектура ротации ключей (Rekeying) и причины сбоя LIFETIME_EXPIRED

Для предотвращения криптографического анализа и утечки ключей сессии стандарты RFC 7296 (IKEv2) и RFC 2409 (IKEv1) определяют механизм плановой ротации ключей (Rekeying) по истечении заданного времени жизни (Lifetime / Soft Lifetime) или объема переданных байт (Byte Limit). За 5–10% времени до окончания жесткого лимита (Hard Lifetime) инициатор начинает фоновое согласование новой ассоциации безопасности (New SA). Если из-за сетевых задержек, потери пакетов CREATE_CHILD_SA, блокировки портов UDP 500/4500 или несовпадения таймеров новый туннель не создается вовремя, старая ассоциация принудительно удаляется ядром по таймеру LIFETIME_EXPIRED, а весь трафик обрывается.

Бизнес-риски

Регулярные кратковременные или постоянные обрывы VPN-соединений ровно каждые 60 минут, 8 часов или 24 часа. Сброс активных терминальных сессий RDP/SSH, зависание транзакций в 1С и обрывы телефонных разговоров по IP-телефонии.

Временные пороги ротации ключей

Регламент устранения проблем при плановом пересогласовании ключей

Сценарий 1: Настройка правильного соотношения таймеров Lifetime (IKE SA vs Child SA)

Время жизни первой фазы (IKE SA Lifetime) ОБЯЗАНО быть больше времени жизни второй фазы (Child/IPsec SA) минимум в 2–3 раза:

# Настройка корректных таймеров на MikroTik RouterOS v7
# Фаза 1 (IKE SA): 24 часа (1d)
/ip ipsec profile set [find name="PROFILE_SITE_B"] lifetime=1d

# Фаза 2 (Child SA): 8 часов (08:00:00)
/ip ipsec proposal set [find name="PROPOSAL_STRONG"] lifetime=8h

Сценарий 2: Настройка асимметричного тайм-аута (Initiator vs Responder)

Если оба шлюза пытаются запустить Rekeying строго в одну и ту же секунду, возникает криптографическая коллизия (Rekey Glare). Разнесите тайм-ауты на разных концах:

# Конфигурация strongSwan (Responder)
connections {
   vpn-tunnel {
      # Добавление разброса времени (rand_time) для исключения одновременного рекея
      rekey_time = 8h
      rand_time = 30m
      over_time = 1h
   }
}

Сценарий 3: Проверка прохождения больших UDP-пакетов через межсетевые экраны

В момент пересогласования ключей (особенно при аутентификации по сертификатам X.509) размер пакета IKE превышает MTU и фрагментируется. Убедитесь, что провайдер не дропает фрагментированные UDP-пакеты:

# Разрешение служебных портов IKE и NAT-T без тайм-аутов в фаерволе
/ip firewall filter add chain=input protocol=udp port=500,4500 action=accept comment="Allow IKE/IPsec Control"

Типовые ошибки администраторов

• Установка одинакового таймера (например, ровно 3600с) для Phase 1 и Phase 2: В момент одновременного истечения обоих таймеров стек не успевает пересоздать Phase 2, так как родительская Phase 1 уже уничтожена.
• Игнорирование таймеров по объему данных (Lifetime Bytes): На гигабитных каналах лимит байт может исчерпаться за 10 минут, вызывая непрерывный шторм пересогласований.