Совместимость, безопасность и ограничения ГОСТ strongSwan¶
Проверенная система¶
- НАЙС.ОС CLOUD 5.2, Linux 6.12.114, x86_64.
strongswan-6.1.0-1.niceosc5, OpenSSL 3.5.9,openssl-gost-engine-3.0.5-2.- Два статических IPv4 узла,
kernel-libipsec, TUNipsec0, UDP 500/4500,/32защищённые адреса. - PSK и X.509 GOST512, локальная/HTTPS CRL,
revocation=strict, rekey, адресный fail-closed.
Новый release после смены plugin ABI, OpenSSL или ядра должен пройти повторную приёмку, особенно на предмет загрузки плагина, реальной ESP и CRL.
Что требует дополнительных тестов¶
| Функция | Статус документации |
|---|---|
| Группа/шифр Magma в реальном соединении | Алгоритм виден в списке, end-to-end здесь не подтверждён |
| ГОСТ OCSP | Плагины revocation/curl присутствуют, online responder испытанием не подтверждён |
| Антиоткат CRL с меньшим номером | Не подтверждён в системном RPM |
| CRL с повреждённой подписью | Отдельное отрицательное испытание требуется |
| Внешнее коммерческое VPN-оборудование | Совместимость не подтверждена |
| XFRM kernel ESP на ГОСТ | Проверенный ESP — через kernel-libipsec |
| Аппаратные токены/HSM/PKCS#11 | Требует отдельной PKI/driver квалификации |
| Развёртывание на Windows/macOS/Android/iOS | Протестирована только НАЙС.ОС ↔ НАЙС.ОС |
| IPv6, site-to-site FORWARD, roadwarrior, HA | Требуют дополнительных тестов |
| Высокая нагрузка и многосуточный soak | Результаты не представлены |
| Сертификация как СКЗИ | Не заявляется на основании этих тестов |
Особенности отзыва¶
Строгая CRL на новом IKE_AUTH запрещает подключение без достоверного статуса или с отозванным сертификатом. Но при уже установленной IKE SA в момент отзыва требуется отдельное решение о принудительном разрыве, потому что повторной аутентификации автоматически при каждом CHILD/IKE rekey может не быть.
Особенности НАЙС.ОС и доверия HTTPS¶
На установленной 5.2 различаются пути ввода доверия p11-kit (/etc/pki/anchors) и рабочий OpenSSL bundle. Испытания показали: update-ca-trust extract с новым CA в неверном каталоге не обновлял рабочий bundle; make-ca -r с CA в /etc/ssl/local успешно обновил его. При использовании новых RPM проверяйте текущую схему, а не переносите механически пути RHEL/Fedora.
Дополнительная проверка перед вводом в эксплуатацию¶
Составьте инвентаризацию peer/TS, правила firewall, план ротации сертификатов и CRL, процедуру отзывания/изъятия узлов, мониторинг и аварийный доступ. Только после этого формируйте организационный акт приёмки.