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 при необходимости.