Вопрос или проблема
У нас есть действительно неловкая проблема со следующим
Настройка выглядит так:
Клиентская сторона
- Windows 11 Клиент 23H2
- Windows VPN Нативный клиент с использованием нижеуказанной конфигурации VPN
- Установлен Yubikey Minidriver (пробовали и без него, результат тот же)
- Yubikey 5C NFC с прошивкой 5.7.1
Серверная сторона
- Debian 12 Strongswan 5.9.8 с swanctl (конфигурация ниже; все сертификаты действительны и доверенные)
У нас есть 2 клиента Windows (одинаковый образ), 2 Yubikey и несколько выданных сертификатов от одного и того же УЦ. Некоторые с 2048-битными RSA-ключами, некоторые с 4096 (оба поддерживаются с прошивкой yubikey 5.7.1 и Windows и известно, что работают, так как мы можем подключаться с обоими типами иногда)
Проблема совершенно случайная (для нас), поэтому происходят такие вещи:
Сценарий A
- Сертификат пользователя A загружен на Yubikey A и используется с клиентом A для подключения через IPSec -> Все работает хорошо; Успешное соединение IPSec
- Тот же сертификат A загружен на Yubikey B и используется с клиентом B для подключения -> Соединение не удалось
Сценарий B
- Сертификат пользователя B (тот же УЦ другой CN) загружен на Yubikey B и используется с клиентом B для подключения -> соединение успешно
- Сертификат пользователя B загружен на Yubikey A и используется с клиентом A для подключения -> соединение не удалось
Сценарий C
- Сертификат пользователя C (тот же УЦ другой CN) загружен на Yubikey A и используется с клиентом A для подключения -> соединение не удалось
- Сертификат пользователя C загружен на Yubikey B и используется с клиентом B для подключения -> соединение не удалось
Самое неловкое в том, что это может измениться со временем. В один день конфигурация (например, сертификат A, загруженный на Yubikey A, использованный на клиенте A), которая ранее не работала, может вдруг начать работать, даже если раньше не работала.
В strongswan это сообщение появляется, указывая, что клиент EAP-TLS (устройство Windows) сбросил соединение с фатальным предупреждением tls. До этого момента журналы идентичны рабочей попытке:
Журнал Strongswan
2024-12-09T10:35:22.392364+01:00 debian charon-systemd[15870]: 05[ENC] разобран запрос IKE_AUTH 7 [ EAP/RES/TLS ]
2024-12-09T10:35:22.392440+01:00 debian charon-systemd[15870]: 05[TLS] полезная нагрузка EAP_TLS => 17 байт @ 0x7f704c05d8a0
2024-12-09T10:35:22.392494+01:00 debian charon-systemd[15870]: 05[TLS] 0: 02 D4 00 11 0D 80 00 00 00 07 15 03 03 00 02 02 ................
2024-12-09T10:35:22.392546+01:00 debian charon-systemd[15870]: 05[TLS] 16: 31 1
2024-12-09T10:35:22.392625+01:00 debian charon-systemd[15870]: 05[TLS] обработка записи предупреждения TLS (2 байта)
2024-12-09T10:35:22.392700+01:00 debian charon-systemd[15870]: 05[TLS] получено фатальное предупреждение TLS 'доступ запрещен'
2024-12-09T10:35:22.392765+01:00 debian charon-systemd[15870]: 05[IKE] Метод EAP EAP_TLS не удался для соперника 192.168.30.114
2024-12-09T10:35:22.392841+01:00 debian charon-systemd[15870]: 05[ENC] генерируется ответ IKE_AUTH 7 [ EAP/FAIL ]
2024-12-09T10:35:22.392908+01:00 debian charon-systemd[15870]: 05[NET] отправка пакета: от 192.168.30.116[4500] к 192.168.30.1[64917] (88 байт)
2024-12-09T10:35:22.392985+01:00 debian charon-systemd[15870]: 05[IKE] IKE_SA eap-tls[9078] изменение состояния: ПОДКЛЮЧЕНИЕ => УНИЧТОЖЕНИЕ
2024-12-09T10:35:22.393082+01:00 debian charon-systemd[15870]: получен пакет: от 192.168.30.1[64917] к 192.168.30.116[4500] (104 байта)
2024-12-09T10:35:22.393214+01:00 debian charon-systemd[15870]: разобран запрос IKE_AUTH 7 [ EAP/RES/TLS ]
2024-12-09T10:35:22.393292+01:00 debian charon-systemd[15870]: получено фатальное предупреждение TLS 'доступ запрещен'
2024-12-09T10:35:22.393403+01:00 debian charon-systemd[15870]: Метод EAP EAP_TLS не удался для соперника 192.168.30.114
2024-12-09T10:35:22.393491+01:00 debian charon-systemd[15870]: генерируется ответ IKE_AUTH 7 [ EAP/FAIL ]
2024-12-09T10:35:22.393580+01:00 debian charon-systemd[15870]: отправка пакета: от 192.168.30.116[4500] к 192.168.30.1[64917] (88 байт)
Журналы SCHANNEL Windows
Журналы SCHANNEL показывают, как используется Microsoft Base Smart Card Crypto Provider, но процесс завершается неудачей.
Информация 09.12.2024 10:45:18 Schannel 36867 Нет
Создаются сведения о клиентской аутентификации TLS.
процесс SSPI-клиента svchost[EapHost] (PID: 5776).
Информация 09.12.2024 10:45:18 Schannel 36868 Нет
Закрытый ключ клиентских данных аутентификации для TLS имеет следующие характеристики:
CSP-имя: Microsoft Base Smart Card Crypto Provider
CSP-тип: 1
Имя ключа: 7d6ba0cb-8ab2-36e4-325b-bf23475fc105
Тип ключа: обмен ключами
Флаги ключа: 0x0
Приложенные данные содержат сертификат.
Информация 09.12.2024 10:45:18 Schannel 36888 Нет
Сгенерировано серьезное предупреждение и отправлено на удаленный узел. Это может привести к завершению соединения. Серьезное предупреждение, определенное протоколом TLS, имеет следующий код: 40.
Целевое имя:
Процесс SSPI-клиента svchost[EapHost] (PID: 5776).
Регистрация предупреждений TLS доступна по адресу: http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-6
Что странно, потому что при успешном соединении журнал schannel показывает, что вместо “Microsoft Base SmartCard Crypto Provider” используется “Microsoft Smart Card Key Storage Provider”, вот так
Информация 09.12.2024 10:45:18 Schannel 36867 Нет
Создаются сведения о клиентской аутентификации TLS.
процесс SSPI-клиента svchost[EapHost] (PID: 5776).
Информация 09.12.2024 10:48:44 Schannel 36868 Нет
Закрытый ключ клиентских данных аутентификации для TLS имеет следующие характеристики:
CSP-имя: Microsoft Smart Card Key Storage Provider
CSP-тип: 0
Имя ключа: 72c27e3d-737e-301e-c312-23a1ef5fc105
Тип ключа: Н/Д
Флаги ключа: 0x0
Приложенные данные содержат сертификат.
Информация 09.12.2024 10:48:46 Schannel 36880 Нет
Клиентский обмен для TLS выполнен успешно. Договоренные криптографические параметры:
Версия протокола: TLS 1.2
CipherSuite: 0xC030
Сила обмена: 384 бита
Указатель контекста: 0x1defdf9c800
Целевое имя:
Имя заявителя для локального сертификата: CN=######
Имя заявителя для удаленного сертификата: CN=#######
Мы не знаем, что вызывает такое случайное поведение и надеялись, что вы сможете помочь нам. Ничто не указывает на то, что yubikey или сервер strongswan делают что-то неправильно; вместо этого, похоже, Microsoft случайным образом решает, когда он действительно правильно отправляет закрытый ключ, используя провайдер хранения ключей.
Спасибо заранее за любую помощь.
Настройки VPN Windows
Название : test
АдресСервера : #########
ПодключениеДляВсехПользователей : False
Guid : {4E1CF7BC-B9B7-42BC-AC55-159E3143806E}
ТипТуннеля : Ikev2
МетодАутентификации : {Eap}
УровеньШифрования : Пользовательский
L2tpIPsecAuth :
ИспользоватьCredLogin : False
EapConfigXmlStream : #документ
СтатусПодключения : Отключено
ЗапомнитьCredential : False
СплитТуннелирование : True
DnsSuffix :
IdleDisconnectSeconds : 0
AuthenticationTransformConstants : SHA256128
CipherTransformConstants : AES256
DHGroup : ECP384
IntegrityCheckMethod : SHA384
PfsGroup : ECP384
МетодШифрования : AES256
Strongswan
соединения {
eap-tls {
пулы = ipv4
локально {
аутентификация = pubkey
сертификаты = servercert.pem
id = ###############
}
удаленно {
аутентификация = eap-tls
cacerts = cacertificate.pem
eap_id = %any
}
дети {
eap-tls {
local_ts = 0.0.0.0/0
esp_proposals = aes256-sha256
}
}
}
}
пулы {
ipv4 {
addrs = 10.10.1.64/26
}
}
Ответ или решение
Проблема с VPN-клиентом Windows и ошибками EAP-TLS при использовании YubiKey
Проблема, с которой вы столкнулись, связана с использованием VPN-клиента Windows 11 (существует вероятность, что это связано с версией 23H2) в сочетании с YubiKey 5C NFC и TLS-сертификатами различного размера (2048 и 4096 бит). Данная проблема характеризуется случайными сбоями подключения через EAP-TLS, что приводит к возникновению ошибки "access denied" в логах StrongSwan. В этом ответе будет рассмотрено возможные причины и решения данной проблемы.
1. Обзор проблемы
Из описания видно, что проблема проявляется случайным образом, когда клиентские сертификаты, загруженные на YubiKey, по-разному работают на различных клиентских устройствах. Если сертификат A работает на YubiKey A для клиента A, он может не работать на YubiKey B для клиента B, и наоборот. Это указывает на возможные проблемы с тем, как Windows обрабатывает криптографические операции для смарт-карт и сертификатов.
2. Анализ журналов
В журналах StrongSwan отображается сообщение о получении фатального TLS-уведомления "access denied", что указывает на проблемы с аутентификацией.
- Журналы Windows SCHANNEL подтверждают использование различных Поставщиков криптографии (CSP). Успешное подключение использует "Microsoft Smart Card Key Storage Provider", тогда как неудачные подключения независимо от используемого сертификата используют "Microsoft Base Smart Card Crypto Provider". Это может указывать на расхождение в конфигурации или ожиданиях системы о том, какие ключи будут использованы для аутентификации.
3. Возможные причины проблемы
-
Несоответствие версий драйверов: Убедитесь, что драйвера YubiKey Minidriver обновлены до последней версии и корректно установлены. Некоторые версии могут содержать ошибки, влияющие на работу с EAP-TLS.
-
Кэширование сертификатов: Сертификаты могут кешироваться неправильно. Пробуйте чистить кеш сертификатов между попытками подключения, что может помочь в устранении проблемы.
-
Состояние YubiKey: Проверьте, правильно ли работают оба YubiKey, так как физический дефект может привести к ошибкам. Попробуйте использовать их на других устройствах или с другими сертификатами.
-
Различия в конфигурации Windows: Убедитесь, что конфигурации VPN на обоих клиентах идентичны, включая настройки сети и локального хранилища сертификатов.
-
Проблема с криптографией: Существуют случаи, когда криптографические параметры, использующиеся на клиенте и сервере, могут различаться. Убедитесь, что протоколы и алгоритмы, используемые на стороне клиента, совпадают с требованиями на стороне сервера.
4. Рекомендации по решению проблемы
-
Обновление драйверов и ПО: Убедитесь, что все компоненты — от Windows до YubiKey и StrongSwan — актуальны и имеют последние обновления.
-
Постоянный мониторинг и изменение настроек: Попробуйте изменить настройки шифрования на стороне клиента и сервера, чтобы выяснить, влияет ли это на успешность подключения.
-
Проверка ключей и сертификатов: Убедитесь, что все ключи и сертификаты корректно загружены на YubiKey и валидны.
-
Тестирование комбинаций: Проведите тесты, используя различные комбинации ключей и сертификатов на каждом клиенте, и фиксируйте результаты. Это может помочь выявить определённые условия, при которых возникают ошибки.
-
Использование других провайдеров криптографии: Попробуйте изменить CSP на "Microsoft Smart Card Key Storage Provider", что может улучшить обработку ключей.
-
Логи: Обратите внимание на другие возможные журналы (например, системные журналы Windows), которые могут предоставить дополнительные сведения о проблемах с аутентификацией и криптографией.
Заключение
Проблема, с которой вы столкнулись, может быть связана с множеством факторов, включая настройки и маршрутизацию, драйвера, конфигурации и особенности взаимодействия с YubiKey и EAP-TLS. Предлагаемые рекомендации могут помочь в диагностике и устранении проблемы. Регулярный мониторинг и тестирование различных конфигураций могут помочь добиться стабильного и безопасного подключения.