Я обращаюсь за помощью после жестокого устранения проблем с подключением между клиентом и сервером.
Проблемы
Клиенты Mac OS X Catalina и Linux нормально подключаются к серверу, но Big Sur — нет. Я еще не тестировал Mojave (который в любом случае теоретически был бы более слабым с точки зрения безопасности) и не тестировал Windows 10. Причина существования всех разных клиентов сложна, но, по сути, мы небольшая консалтинговая компания, где люди могут выбирать их платформа, хотя и более старая, Мохаве просто потому, что они еще не обновились. В любом случае это значительно усложняет мою работу (как системного администратора), но это так.
Серверы
- Редхэт 8.2. Один настроен в режиме FIPS, другой нет из-за OpenVPN. Оба, конечно же, управляют Libreswan.
- Установка Libreswan по умолчанию из yum. Версия: 3.29-7
- IKEv2 с использованием NSS с сертификатами RSA для аутентификации.
- Настраиваемая корневая/промежуточная инфраструктура ЦС. CRL действителен, интегрирован и хранится в NSS.
- Брандмауэр, таблица маршрутизации, настройки sysctl и т. д., похоже, настроены правильно. Я использую iptables с собственным набором правил, а не firewalld.
Клиенты
- Mac OS X Mojave, Catalina и Big Sur
- Windows 10
- Клиенты Ubuntu и RedHat Linux
Конфигурация
Клиентская сторона (Mobileconfig для упаковки всего вместе)
Я использую встроенный сетевой клиент, никаких внешних клиентов для упрощения. Большинство платных клиентов в любом случае не поддерживают IKEv2, хотя я ненадолго попробовал GreenBow VPN.
Вкладка «Полезная нагрузка VPN» (Apple Configurator 2, Catalina/Big Sur с одинаковыми данными/конфигурацией)
- Тип подключения: IKEv2
- Идентификатор сервера/удаленного сервера: IP-адрес сервера (сертификат сервера имеет SubjectAltName IP-адрес: IP-адрес сервера)
- Локальный идентификатор: адрес электронной почты пользователя, кажется, хорошо работает здесь, если предположить, что это не Big Sur. Установка его как пустого также работала в свое время. Я не уверен, что я изменил, или даже я это сделал, но электронная почта должна присутствовать сейчас.Я также начал добавлять это в качестве клиентской части поля электронной почты subjectAltName по предложению коллеги.
- Аутентификация компьютера — это сертификат, RSA для типа и имя издателя CA задано правильно.
- Все остальные элементы безопасности, такие как параметры DH и крипто, среднего уровня, AES-256 и DH21. Первоначально я настроил AES-256-GCM, чтобы попытаться избежать всего, что связано с ошибкой усечения SHA2. Это тоже не работает.
Вкладка «Полезная нагрузка сертификатов»
- Я настроил это по-разному. Однако здесь применяются стандартные вещи: идентификатор .p12 с паролем закрытого ключа для пользователя, а также пароль экспорта (оба длиной 23 символа). Продолжительность 920 дней. Я где-то читал, что это может быть проблемой, но журналы, которые я нашел на стороне клиента, не отражают того, что я расстроен продолжительностью времени, в течение которого он действителен. Кроме того, я протестировал более короткое время действия сертификата, около 500 дней, чтобы посмотреть, принесет ли это что-то хорошее; Это не так.
- Корневой/промежуточный ЦС был включен в две конфигурации при создании PKCS12: только промежуточный ЦС или полная цепочка ЦС. Ни одна из конфигураций не работала в Биг-Суре.
- Ручной импорт корневого/промежуточного ЦС; Я отметил оба как доверенные для всех случаев использования. Я импортировал/скопировал их из цепочки для ключей входа в цепочку для ключей системы. Я сделал все, что я мог найти на эту тему, и ничего не работает.
Конфигурация на стороне сервера
авто=добавить
authby=rsasig
dpddelay=30
дпдтаймаут=120
dpdaction=очистить
фрагментация = нет (Big sur выдает другую ошибку при включении этого параметра)
modecfgpull=да
modecfgdns="Внутренний DNS"
пфс=да
ключ = да
срок службы = 8 часов
ikelifetime=8ч
слева = ПУБЛИЧНЫЙ IP-адрес
leftcert=PUBLIC IP (здесь я пробовал разные формы; @PUB... и т.д.)
leftid = ПУБЛИЧНЫЙ IP
leftsendcert=всегда
левая подсеть=0.0.0.0/0
leftrsasigkey=%сертификат
leftmodecfgserver=да
rightaddresspool=Внутренний пул адресов
справа=%любой
rightrsasigkey=%сертификат
rightmodecfgclient=да
Журналы на стороне клиента
Во-первых, единственное всплывающее окно с ошибкой графического интерфейса, которое я вижу здесь при попытке подключения, — «Ошибка аутентификации пользователя». Затем я использую следующую команду для получения лучших/более полезных журналов в Mac OS X:
log show --start DATE --predicate 'senderImagePath содержит [cd] "NetworkExtension"'
Эти журналы, по большей части, представляют собой 1000 строк хлама. Тем не менее, это кажется актуальным:
2021-08-10 0x1aa44 0x1aa44 Ошибка 0x0 2375 0 Â NEIKEv2Provider: (NetworkExtension) [com.apple.networkextension:] Ошибка оценки сертификата = kSecTrustFrustResultRecoverableTrust
2021-08-10 0x1aa44 Ошибка 0x0 2375 0 Â NEIKEv2Provider: (NetworkExtension) [com.apple.networkextension:] Сертификат не является доверенным
2021-08-10 0x1aa44 Ошибка 0x0 2375 0 Â NEIKEv2Provider: (NetworkExtension) [com.apple.networkextension:] Данные проверки подлинности сертификата не могут быть проверены
2021-08-10 0x1aa44 â default â â € â â € â â â € â â â € â â â € â â € â â € â â € â â € â â € â â € Â > Ошибка отключения (нулевая) -> Домен ошибки = NEIKEv2ErrorDomain Code = 8 «Аутентификация: не удалось проверить данные аутентификации сертификата» UserInfo = {NSLocalizedDescription = Аутентификация: не удалось проверить данные аутентификации сертификата}
2021-08-10 0x1aa44 â € â â â € â â â € â â € â â â € â â € â â € â â € â â € â â € â â € â â € â â € â â € Â обработать пакет аутентификации IKE (подключиться)
Примечания
Как описано в предыдущих комментариях о конфигурации клиента. Похоже, я проделал работу, чтобы сделать это правильно. Даже на дисплее Apple Configurator видно, что это приемлемый пакет конфигурации. Очевидно, что это не подписано Apple, но это неудивительно.Стандартная ручная настройка IKEv2 просто недостаточна для наших нужд. И это просто не работает, чтобы быть уверенным. По крайней мере, для чего-то более сложного, чем детская игрушка сервера.
Я также исследовал проблему прозрачности сертификатов; К сожалению, это не решение для Mac OS X. Это решение применимо только к таким устройствам, как iPad и т. д. Попытка установить mobileconfig в OS X с включенным CT и исключением определенных сертификатов отклоняется и не устанавливает mobileconfig.
Журналы на стороне сервера
У меня есть внешний сервер в режиме отладки, чтобы генерировать больше журналов, чем обычно. Тем не менее, в этом случае сервер, кажется, совершенно доволен транзакцией, это клиентская сторона, которая ненавидит ........ Что-то. Я не знаю что.
Хотя вот что я вижу:
10 августа serverName pluto[]: | предложенный CA: 'C=US, ST=US, O=companyName, OU=OUCA, CN=CANName, [email protected]'
10 августа serverName pluto[]: "remote"[51] serverIP #90: ID однорангового узла в режиме IKEv2: ID_USER_FQDN: '[email protected]'
10 августа serverName pluto[]: | получено v2N_INITIAL_CONTACT
10 августа serverName pluto[]: | Получено неизвестное/неподдерживаемое уведомление v2N_NON_FIRST_FRAGMENTS_ALSO — игнорируется
10 августа serverName pluto[]: | получил v2N_MOBIKE_SUPPORTED, но не отправил
10 августа serverName pluto[]: | получена полезная нагрузка CERTREQ; собираюсь расшифровать это
10 августа serverName pluto[]: | CERT_X509_SIGNATURE CR:
10 августа serverName pluto[]: | 10 81 9a c1 4c a6 94 70 ca d1 7d 77 e1 5a ab 36
10 августа serverName pluto[]: | 93 3д компакт-диск 39
10 августа serverName pluto[]: | содержимое большого двоичного объекта сертификата не является двоичным ASN.1
10 августа serverName pluto[]: | проверка полезной нагрузки AUTH
10 августа serverName pluto[]: | требуемый ЦС RSA: '%any'
10 августа serverName pluto[]: | проверка идентификатора ключа RSA «serverIP» на совпадение с «[email protected]»
10 августа serverName pluto[]: | проверка идентификатора ключа RSA 'C=US, ST=US, L=City, O=companyName, OU=OUCA, CN=UserCN, [email protected]' на совпадение с '[email protected]'
10 августа serverName pluto[]: | проверка идентификатора ключа RSA «[email protected]» на совпадение с «[email protected]»
10 августа serverName pluto[]: | trust_ca_nss: доверенное лицо A = 'C=US, ST=US, O=companyName, OU=OUCA, CN=CANName, [email protected]'
10 августа serverName pluto[]: | центр сертификации ключевого издателя: "C=US, ST=US, O=companyName, OU=OUCA, CN=CANName, [email protected]"
10 августа serverName pluto[]: | проверка RSA Sig прошла с *AwEAAbi14 [удаленные сертификаты]
10 августа serverName pluto[]: "remote"[51] serverIP #90: Аутентификация с использованием RSA
Журналы сервера показывают, что клиент Mac OS X Big Sur проходит проверку подлинности правильно. Затем он переходит к построению отношений SA и т. д., как вы обычно видите. Клиент, который отвергает соединение из-под контроля. Чего я не понимаю, так это того, что изменилось между Каталиной и Биг-Суром ??
Я не нашел информации об этом изменении ОС. Я не понимаю, почему это не выделено шрифтом 60 пунктов жирным шрифтом на первой странице веб-сайта Apple, о да, забавный факт, мы полностью изменили способ работы IPSEC в этой версии ОС. И я устал окровавлять свою голову, либо выдергивать волосы, либо постоянно биться ими о стену.
Любая помощь будет оценена по достоинству.
