IKEv2-клиент (KN-1011, 5.1.8) игнорирует INVALID_KE_PAYLOAD и жёстко использует MODP_1024

[oakiselev]

Модель: Keenetic Giga (KN-1011), регион EAEU
Прошивка: KeeneticOS 5.1.8
Компонент: «IKEv1/IPsec и IKEv2/IPsec VPN-клиенты»
Сценарий: роутер как IKEv2-клиент (EAP-MSCHAPv2) к серверу strongSwan 6.0.4 (Ubuntu 26.04)

Суть проблемы
Клиент не устанавливает соединение с сервером, у которого в proposals нет MODP_1024.
При этом клиент сам предлагает MODP_2048 и ECP_384 (они есть в его списке предложений),
но после INVALID_KE_PAYLOAD продолжает присылать KE с группой MODP_1024, то есть
нотификацию игнорирует. Соединение не устанавливается никогда, статус в веб-интерфейсе —
«неизвестно».

Как воспроизвести
1. Сервер strongSwan 6.0.4, proposals = default (в 6.0 это AES_GCM_16-256/PRF_SHA2-256/ECP_256).
2. Роутер: IKEv2-клиент, EAP-MSCHAPv2, адрес vpn.<domain>, логин/пароль — корректные
   (те же учётные данные с macOS/iOS/Android подключаются без ошибок).
3. Роутер ретраится каждые 5–15 секунд, каждый раз с одинаковым результатом.

Лог сервера (повторяется циклически, интервал 5–15 с):

  parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ... ]
  received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
    IKE:AES_CBC_128/.../MODP_1024, ..., IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_384,
    IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048,
    IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, ...
  selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
  key exchange method in received payload MODP_1024 doesn't match negotiated MODP_2048
  key exchange method MODP_1024 unacceptable, requesting MODP_2048
  generating IKE_SA_INIT response 0 [ N(INVAL_KE) ]
  --> роутер снова присылает IKE_SA_INIT с KE MODP_1024

То же самое при ECP_384: сервер просит ECP_384 (группа есть в списке роутера),
роутер ответ не меняет.

Ожидаемое поведение
По RFC 7296 (п. 1.2 и 2.6) инициатор, получив INVALID_KE_PAYLOAD с указанной группой,
должен повторить IKE_SA_INIT с KE этой группы, выбрав из своего списка предложение
с соответствующей DH-группой. Клиент этого не делает.

Обходной путь, который пришлось применить
Добавление MODP_1024 в proposals сервера — соединение сразу устанавливается.
Но это вынужденный downgrade: DH-1024 не рекомендуется (RFC 8247) и даёт возможность
downgrade-атаки на общем профиле, которым пользуются и современные клиенты.
Хотим вернуться к MODP_2048/ECP-256.

Просьбы
1. Исправить обработку INVALID_KE_PAYLOAD в IKEv2-клиенте (переинициировать с
   запрошенной группой из собственного списка предложений). Это дефект
   интероперабельности, из-за него клиент совместим только с серверами,
   принимающими MODP_1024.
2. Если исправление требует времени — рассмотреть возможность выбора
   proposals/DH-группы в профиле IKEv2-клиента (сейчас в интерфейсе только сервер,
   логин, пароль, Server identity, Nailed-up, DPD).
3. Уточнить, воспроизводится ли на актуальных dev-сборках и куда сообщить
   для проверки.

Дополнительно
- На этом же сервере IKEv2/EAP с macOS/iOS/Android работает, proposals GCM-256/ECP-256 —
  значит проблема на стороне клиента роутера, а не сервера.
- Site-to-site IPsec-клиент этого же роутера с тем же сервером договаривается
  до AES-GCM-256/ECP-256 без ошибок, то есть затронут именно EAP-клиент.

Готов предоставить: self-test, полный лог сервера за попытку подключения,
дамп трафика UDP/500 при необходимости.