При инициализации подключения к высоконагруженному шлюзу VPN наблюдаются задержки:

• В логах клиента фиксируется сообщение: received COOKIE_REQUIRED notify error, repeating IKE_SA_INIT with cookie payload.
• Увеличение времени установления туннеля (требуется 4 пакета вместо 2 в Фазе 1).
• Некоторые клиенты со старыми реализациями IPsec не могут подключиться и падают с таймаутом.

1. Механизм защиты IKEv2 Cookie (RFC 7296 Section 2.6)

Для защиты от DoS-атак с подделкой IP-адреса отправителя (IP Spoofing) шлюз-ответчик при превышении порога полуоткрытых соединений отказывается выполнять ресурсоемкие операции вычисления ключей Диффи-Хеллмана. Вместо ответа IKE_SA_INIT он отправляет легкое уведомление COOKIE_REQUIRED (Notify 1), содержащее криптографический хеш (Cookie). Инициатор обязан повторить исходный запрос, включив полученную Cookie без изменений. Это гарантирует, что IP-адрес инициатора реален и доступен по маршруту.

2. Анализ логов обмена Cookie

# Лог strongSwan на стороне инициатора
[IKE] peer requested cookie exchange
[IKE] re-initiating IKE_SA_INIT with cookie: 7f8a9b...
[IKE] IKE_SA established successfully

3. Настройка порогов активации Cookie на сервере (strongSwan)

Отредактируйте /etc/strongswan.d/charon.conf:

charon {
    # Порог полуоткрытых сессий для активации механизма Cookie
    # Значение 0 = включен всегда, 10 = активировать при 10 сессиях в очереди
    cookie_threshold = 30
    
    # Секретный ключ для генерации хешей (ротируется автоматически)
    # dos_protection = yes
}

4. Настройка Cisco ASA / Firepower

# Настройка защиты от IKE DoS на Cisco ASA
crypto ikev2 limit max-half-open 100
crypto ikev2 cookie-challenge 50

5. Траблшутинг клиентов, не поддерживающих Cookie

Если устаревший клиент не умеет обрабатывать Cookie, временно увеличьте cookie_threshold на сервере, чтобы исключить генерацию запроса при нормальной нагрузке.