Проблемы с клиентом Libreswan и Mac OS X Big Sur
Я прибегаю к помощи после того, как потратил много времени на устранение проблем с соединением между клиентом и сервером.
Проблемы
Клиенты Mac OS X Catalina и Linux прекрасно работают при подключении к серверу, а Big Sur — нет. Я еще не тестировал Mojave (который в любом случае теоретически был бы более слабым с точки зрения безопасности), а также не тестировал Windows 10. Причина появления всех разных клиентов сложна, но по сути мы небольшая консалтинговая компания, где люди могут выбирать. их платформа, хотя и более старая, Mojave, просто потому, что они еще не обновились. В любом случае это значительно усложняет мою работу (как системного администратора), но это так.
Серверы
- РедХат 8.2. Один настроен в режиме FIPS, другой нет из-за OpenVPN. Оба, конечно, управляют Либресуаном.
- Установка 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 Configurationator 2, обе Catalina/Big Sur — одинаковые данные/конфигурация)
- Тип подключения: IKEv2
- Идентификатор сервера/удаленного сервера: IP-адрес сервера (сертификат сервера имеет IP-адрес субъектаAltName: IP-адрес сервера)
- Локальный идентификатор: адрес электронной почты пользователя здесь хорошо работает, если предположить, что это не Биг-Сур. Установка его как пустого тоже одно время работала. Я не уверен, что я изменил и сделал ли это вообще я, но теперь электронная почта должна присутствовать. Я также начал добавлять это в качестве клиентского поля электронной почты subjectAltName по предложению коллеги.
- Аутентификация компьютера — это сертификат, тип RSA и имя издателя центра сертификации установлены правильно.
- Все остальные элементы безопасности, такие как параметры DH и криптография, относятся к среднему классу, AES-256 и DH21. Первоначально я настроил AES-256-GCM, чтобы избежать всего, что связано с ошибкой усечения SHA2. Это тоже не работает.
Вкладка «Полезные данные сертификатов»
- Я настроил это по-разному. Однако здесь применяются стандартные вещи: идентификатор .p12 с паролем закрытого ключа для пользователя, а также паролем экспорта (оба длиной 23 символа). Продолжительность 920 дней. Я где-то читал, что это может быть проблемой, но журналы, которые я нашел на стороне клиента, не отражают недовольства продолжительностью времени, в течение которого они действительны. Кроме того, я протестировал более короткий срок действия сертификата, около 500 дней, чтобы посмотреть, принесет ли это что-нибудь хорошее; Это не так.
- Корневой/промежуточный ЦС был включен в две конфигурации при создании PKCS12: только промежуточный ЦС и полную цепочку ЦС. Ни одна из конфигураций не работала в Биг-Суре.
- Вручную импортировали корневые/промежуточные центры сертификации; Я пометил оба как доверенные для всех случаев использования. Я импортировал/скопировал их из цепочки для ключей входа в цепочку для ключей системы. Я сделал все, что мог найти по этой теме, и ничего не помогло.
Конфигурация на стороне сервера
auto=add
authby=rsasig
dpddelay=30
dpdtimeout=120
dpdaction=clear
fragmentation=no (Big sur gives a different error with this on)
modecfgpull=yes
modecfgdns="Internal DNS"
pfs=yes
rekey=yes
salifetime=8h
ikelifetime=8h
left=PUBLIC IP
leftcert=PUBLIC IP (I've tried varied forms here; @PUB... etc)
leftid=PUBLIC IP
leftsendcert=always
leftsubnet=0.0.0.0/0
leftrsasigkey=%cert
leftmodecfgserver=yes
rightaddresspool=Internal address pool
right=%any
rightrsasigkey=%cert
rightmodecfgclient=yes
Журналы на стороне клиента
Во-первых, единственное всплывающее окно с ошибкой графического интерфейса, которое я вижу здесь при попытке подключения, — это «Ошибка аутентификации пользователя». Затем я использую следующую команду для получения более качественных/более полезных журналов в Mac OS X:
log show --start DATE --predicate 'senderImagePath contains[cd] "NetworkExtension"'
Эти логи по большей части представляют собой 1000 строк мусора. Тем не менее, это кажется актуальным:
2021-08-10 0x1aa44 Error 0x0 2375 0 NEIKEv2Provider: (NetworkExtension) [com.apple.networkextension:] Certificate evaluation error = kSecTrustResultRecoverableTrustFailure
2021-08-10 0x1aa44 Error 0x0 2375 0 NEIKEv2Provider: (NetworkExtension) [com.apple.networkextension:] Certificate is not trusted
2021-08-10 0x1aa44 Error 0x0 2375 0 NEIKEv2Provider: (NetworkExtension) [com.apple.networkextension:] Certificate authentication data could not be verified
2021-08-10 0x1aa44 Default 0x0 2375 0 NEIKEv2Provider: (NetworkExtension) [com.apple.networkextension:] IKEv2IKESA[2.2, C4CABCADAB06C2CF-75E7F26177F83187] state Connecting -> Disconnected error (null) -> Error Domain=NEIKEv2ErrorDomain Code=8 "Authentication: Certificate authentication data could not be verified" UserInfo={NSLocalizedDescription=Authentication: Certificate authentication data could not be verified}
2021-08-10 0x1aa44 Error 0x0 2375 0 NEIKEv2Provider: (NetworkExtension) [com.apple.networkextension:] IKEv2Session[2, C4CABCADAB06C2CF-75E7F26177F83187] Failed to process IKE Auth packet (connect)
Примечания
Как описано в предыдущих комментариях о конфигурации клиента... Кажется, я проделал работу, чтобы сделать это правильно. Даже на экране конфигуратора Apple видно, что это приемлемый пакет конфигурации. Очевидно, что он не подписан Apple, но это неудивительно. Стандартная ручная настройка IKEv2 просто недостаточно полна для наших нужд. И, конечно, это тоже не работает. По крайней мере, для чего-то более сложного, чем детская игрушка-сервер.
Я также исследовал проблему прозрачности сертификатов; К сожалению, это не решение для Mac OS X. Это решение применимо только к таким устройствам, как iPad и т. д. Попытка установить mobileconfig в OS X с включенным CT и исключением определенных сертификатов отклоняется и не устанавливает mobileconfig.
Журналы на стороне сервера
У меня внешний сервер находится в режиме отладки, чтобы генерировать больше журналов, чем обычно. Тем не менее, в данном случае сервер, похоже, совершенно доволен транзакцией, а клиентская сторона ненавидит… Что-то. Я не знаю что.
Хотя вот что я вижу:
Aug 10 serverName pluto[]: | offered CA: 'C=US, ST=US, O=companyName, OU=OUCA, CN=CAName, E=sysadmin@email.domain'
Aug 10 serverName pluto[]: "remote"[51] serverIP #90: IKEv2 mode peer ID is ID_USER_FQDN: 'user@email.domain'
Aug 10 serverName pluto[]: | received v2N_INITIAL_CONTACT
Aug 10 serverName pluto[]: | Received unknown/unsupported notify v2N_NON_FIRST_FRAGMENTS_ALSO - ignored
Aug 10 serverName pluto[]: | received v2N_MOBIKE_SUPPORTED while it did not sent
Aug 10 serverName pluto[]: | received CERTREQ payload; going to decode it
Aug 10 serverName pluto[]: | CERT_X509_SIGNATURE CR:
Aug 10 serverName pluto[]: | 10 81 9a c1 4c a6 94 70 ca d1 7d 77 e1 5a ab 36
Aug 10 serverName pluto[]: | 93 3d cd 39
Aug 10 serverName pluto[]: | cert blob content is not binary ASN.1
Aug 10 serverName pluto[]: | verifying AUTH payload
Aug 10 serverName pluto[]: | required RSA CA is '%any'
Aug 10 serverName pluto[]: | checking RSA keyid 'serverIP' for match with 'user@email.domain'
Aug 10 serverName pluto[]: | checking RSA keyid 'C=US, ST=US, L=City, O=companyName, OU=OUCA, CN=UserCN, E=user@email.domain' for match with 'user@email.domain'
Aug 10 serverName pluto[]: | checking RSA keyid 'user@email.domain' for match with 'user@email.domain'
Aug 10 serverName pluto[]: | trusted_ca_nss: trustee A = 'C=US, ST=US, O=companyName, OU=OUCA, CN=CAName, E=sysadmin@email.domain'
Aug 10 serverName pluto[]: | key issuer CA is 'C=US, ST=US, O=companyName, OU=OUCA, CN=CAName, E=sysadmin@email.domain'
Aug 10 serverName pluto[]: | an RSA Sig check passed with *AwEAAbi14 [remote certificates]
Aug 10 serverName pluto[]: "remote"[51] serverIP #90: Authenticated using RSA
Журналы сервера показывают, что клиент Mac OS X Big Sur проходит проверку подлинности правильно. Затем происходит построение отношений SA и т. д., как вы обычно видите. Клиент — это тот, кто сразу отвергает соединение. Чего я не понимаю, так это того, что изменилось между Каталиной и Биг-Суром ??
Я не нашел никакой информации об этом изменении ОС. Я не понимаю, почему это не выделено жирным шрифтом размером 60 пунктов на первой странице веб-сайта Apple и, о да, забавный факт, мы полностью изменили способ работы IPSEC в этой версии ОС. И я устал кровоточить голову, выдергивать волосы или постоянно стучать ими о стену.
Любая помощь будет оценена по достоинству.