ГОСТ, сетевые протоколы и Linux XFRM¶
Linux Kernel Crypto API предоставляет алгоритмы для совместимых сетевых подсистем. В частности, XFRM/IPsec использует криптографические преобразования ядра при обработке ESP, если соответствующий алгоритм и режим поддерживаются согласованным профилем соединения.
Что предоставляет НАЙС.ОС¶
Встроенные «Магма», «Кузнечик», «Стрибог» и исторические алгоритмы ГОСТ доступны потребителям Kernel Crypto API. Это криптографическая основа для разработки сетевых решений.
Почему не достаточно одного шифра в /proc/crypto¶
IPsec использует IKEv2 для согласования ключей и параметров, а ESP — для защиты пользовательского трафика. Каждая сторона должна согласовать точные преобразования IKE и ESP, идентификаторы алгоритмов, формат nonce, ключевой обмен, механизм аутентификации и смену ключей. Простое наличие kuznyechik или magma в ядре не включает конкретный ГОСТ-IPsec профиль автоматически.
В рамках стандартных ГОСТ-профилей современные алгоритмы и процедуры описаны в RFC 9227 и RFC 9385. Эти документы включают требования, выходящие за рамки базовых блочных алгоритмов: MGM-KTREE, алгоритмы IKE, параметры подписи и ключевой обмен.
Проверить XFRM на сервере без изменения соединений¶
Это операции чтения. Команды не устанавливают SA и не меняют сетевой трафик.
Реализованный системный IPsec с ГОСТ¶
На испытанной НАЙС.ОС CLOUD 5.2 готовый strongswan-6.1.0-1.niceosc5 обеспечивает ГОСТ IKEv2 и ESP через пользовательский kernel-libipsec + TUN ipsec0, а не через XFRM ядра. Поэтому отсутствие ГОСТ ESP state в ip xfrm state не означает отсутствие установленного защищённого канала. Проверяйте swanctl --list-sas, ip -s link show ipsec0 и увеличение счётчиков.
Пошаговая инструкция: ГОСТ IKEv2/IPsec из RPM.
OpenVPN и встроенный ГОСТ¶
В НАЙС.ОС также доступен OpenVPN с «Кузнечиком» и HMAC «Стрибог». В ранее испытанном туннеле шифрование канала данных выполнялось через OpenSSL, а не автоматически через Crypto API ядра. Подробности — OpenVPN с ГОСТ.