Перейти к содержанию

Современный ГОСТ в IKEv2 и IPsec: совместимость двух шлюзов

Что определяют RFC

RFC 9227 описывает использование «Кузнечика» и «Магмы» в ESP и IKEv2, включая MGM и внешнюю смену ключей KTREE. RFC 9385 дополнительно определяет ГОСТ-преобразования, необходимые для IKEv2: подписи, PRF и согласование ключей. Оба документа — информационные независимые публикации для межвендорной совместимости, а не утверждение, что ГОСТ входит в каждую установку strongSwan.

Два независимых уровня IPsec: IKEv2 создаёт и сопровождает защищённые ассоциации, а ESP защищает передаваемые IP-пакеты. Успешное согласование обычного IKEv2 с AES и RSA не доказывает использование ГОСТ внутри ESP. Равным образом наличие симметричного ГОСТ-шифра в Linux Crypto API не обеспечивает полный обмен IKEv2.

Ключевые идентификаторы RFC 9227

Transform ID Преобразование Роль
32 ENCR_KUZNYECHIK_MGM_KTREE AEAD: шифрование и аутентификация
33 ENCR_MAGMA_MGM_KTREE AEAD: шифрование и аутентификация
34 ENCR_KUZNYECHIK_MGM_MAC_KTREE Только защита подлинности в ESP
35 ENCR_MAGMA_MGM_MAC_KTREE Только защита подлинности в ESP

Это Type 1 Encryption Algorithm идентификаторы IKEv2. Их нельзя смешивать с номерами групп согласования ключей или PRF из других пространств IKEv2.

Почему «Кузнечик» в ядре — только фундамент

cbc(kuznyechik), xts(kuznyechik) и даже базовый mgm(kuznyechik) не тождественны MGM_KTREE из RFC 9227. Необходимы профиль nonce, дерево ключей, ограничения пакетов, управление порядковыми номерами, согласованные параметры SA и обработка rekey. Кроме того, strongSwan должен объявлять и реально выполнять соответствующие преобразования IKEv2.

На НАЙС.ОС отдельная задача совместимости включает:

  1. Криптографический backend strongSwan для PRF, подписи и обмена ключами ГОСТ.
  2. Кодирование и проверку ГОСТ-сертификатов, параметров кривых и идентификаторов алгоритмов.
  3. Реализацию согласованного ESP MGM-KTREE в пользовательском стеке или в Linux XFRM.
  4. Проверку переговоров SA, NAT-T, PFS, rekey, DPD, anti-replay и восстановления после обрыва.
  5. Испытания с конкретной версией российской реализации на обеих сторонах.

Чего нельзя обещать без испытаний

«Поддержка ГОСТ» у двух производителей не означает 100%-ю совместимость. Требуется совпадение точного профиля и подтверждение двустороннего обмена, переподключения, смены ключей и отрицательных тестов. Поддержка шифра не является эквивалентом статуса сертифицированного СКЗИ.

Реальная настройка в НАЙС.ОС

Для установленного RPM strongswan-6.1.0 доступны проверенные PSK и ГОСТ X.509, локальная и HTTPS CRL через charon, ESP на kernel-libipsec/ipsec0, rekey и fail-closed для защищённых адресов. Пошаговое руководство администратора и матрица приёмки.

Полная цепочка исполнения ГОСТ IKEv2

swanctl (управление профилями)
     |
     v
charon  ← VICI (локальный управляющий сокет)
     |
  IKEv2 (RFC 7296 + ГОСТ RFC 9385)
     ├── ГОСТ подпись / PSK
     ├── PRF HMAC Стрибог
     └── обмен ключами + SA negotiation
     |
     v
ESP (RFC 4303 + RFC 9227)
     ├── Кузнечик MGM-KTREE
     └── пакет, nonce, salt, SPI, seqno, ротация ключей
     |
     v
kernel-libipsec → TUN ipsec0 → IP-пакеты

Фактический профиль НАЙС.ОС 5.2: системный RPM strongswan-6.1.0-1.niceosc5 с ГОСТ-плагином, kernel-libipsec и интерфейсом ipsec0. Не подменяйте его абстрактным рецептом для Linux XFRM/ip xfrm. При подтверждённых испытаниях применялись KUZNYECHIK_MGM_KTREE, PRF_HMAC_STREEBOG_512, GOST3410_512; ESP — KUZNYECHIK_MGM_KTREE. Установка из RPM.

Обособленные свойства и границы проверки

IKE SA обеспечивает аутентификацию участников и контроль ключевого обмена, CHILD SA — параметры защиты полезного трафика. Установка IKE SA без CHILD SA не означает, что прикладные пакеты шифруются. Смена IKE SA и смена CHILD SA проверяются отдельно. ESP использует собственные счётчики и anti-replay; это нельзя считать свойством просто блочного «Кузнечика».

PSK: наличие успешного туннеля доказывает согласование профиля и ключа, но не проверяет X.509 PKI. X.509: подпись, цепочка доверия, CRL/OCSP, строгая политика статуса — отдельные этапы. Пример испытанной CRL 0x1002: отзыв тестового сертификата дал отказ IKE_AUTH; действующий исходный сертификат принят, а HTTPS CRL загружена непосредственно charon.

Политика отказа

Для корпоративного профиля требуется revocation = strict там, где применяется X.509. При отсутствии допустимой CRL и недоступном HTTPS при новом подключении испытанный charon вернул RULE_CRL_VALIDATION is FAILED, but requires at least GOOD. Это подтверждённый fail-closed в аутентификации, но не доказывает, что уже установленный туннель будет автоматически сброшен сразу при отзыве. Смотрите PKI-статус и практику revocation.

Межвендорная совместимость

Сверяют: номера трансформов IKEv2, параметры ECDH/подписи, OID сертификатов, ключевые параметры, ESP salt и nonce, длину ICV, профили NAT-T, фрагментацию, интервалы rekey, матрицу ограничений и реакции на несовместимость. Не объявляйте совместимость с продуктом другого производителя, пока два реальных экземпляра не прошли двусторонний тест.

Ориентиры: RFC 7296, RFC 4303, RFC 3948, RFC 9227, RFC 9385, MGM-KTREE и практика strongSwan.

Источники