Сертификат VPN на Mac: какую учётную запись видит шлюз?

Профиль показывает ваше имя, видимая метка сертификата говорит другое, а журнал шлюза фиксирует третий идентификатор. Ни один из них не лжёт, и именно в этом проблема: три разных поля читаются так, будто отвечают на один вопрос. Подключение предъявляет учётные данные, идентификатор IKEv2 и учётную запись, и шлюз решает, что из этого что разрешает.

Три личности в одном подключении

Видимое имя профиля — это метка для людей. Она выбирает подключение и больше ничего. Сертификат — это учётные данные, и то, может ли он что-то доказать, зависит от того, есть ли у клиента соответствующий закрытый ключ. Поле учётной записи — это утверждение о субъекте, и сервер вправе сопоставить его с другой локальной личностью.

Когда аутентификация не удаётся, спросите, к чему из трёх относится ошибка. Отклонённые учётные данные, неизвестный идентификатор и отключённая учётная запись дают разные сообщения, а отношение к ним как к одной «проблеме сертификата» отправляет вас в неверную консоль.

Читайте собственные поля по их назначению

В управляемой собственной конфигурации IKEv2 ссылка на полезную нагрузку Apple разделяет значения, а метод аутентификации определяет, какая комбинация требуется:

Сертификат и вход по EAP могут иметь разные роли в одном подключении. Не заставляйте каждое поле содержать один и тот же текст только потому, что так делает одно из них, и не считайте, что изменение одного отменяет остальные. VPN-приложение третьей стороны может показывать совершенно другую модель; используйте его документированный выбор личности вместо переноса туда собственных имён полей.

Сертификат сервера — это не личность клиента

Сертификат, проверяющий шлюз, — это якорь доверия. Он доказывает, что вы попали на ожидаемый сервер. Личность клиента — это другой объект: она включает доступ к закрытому ключу, который доказывает, что подключающаяся сторона — та, за кого себя выдаёт. Переименование видимой учётной записи не может превратить одно в другое.

Именно здесь добросовестное исправление идёт не так. Импорт CA-сертификата шлюза в хранилище клиента ничего не даёт для аутентификации клиента, а пометка этой записи именем пользователя не делает её личностью пользователя. Два объекта живут в разных частях профиля и отвечают на разные вопросы.

Проследите субъект до сопоставления на шлюзе

Подтвердите, для чего выданы учётные данные: для этого пользователя, этого устройства или общей роли. Учётная запись входа Mac не обязательно является этим субъектом, а сертификат, скопированный с другой машины, сохраняет личность той машины, для которой он выдан.

Затем сравните фактические учётные данные, а не метку. Издатель, серийный номер и отпечаток позволяют вам и администратору убедиться, что речь об одном объекте. Отображаемые имена редактируемы и часто дублируются, что делает их худшим возможным идентификатором во время инцидента.

Последний шаг — на шлюзе. Попросите его владельца сопоставить одно подключение с предъявленными идентификаторами и с правилом сопоставления учётных записей, которое их использовало. Метка на стороне клиента не может установить, что решил сервер, а правило, сопоставляющее сертификат с отключённой учётной записью, будет давать сбой, пока все поля на стороне клиента выглядят правильно.

Исправьте слой, которому принадлежит несоответствие

Если профиль указывает на неверные учётные данные, исправьте ссылку или выбор. Если учётные данные принадлежат другому субъекту, пройдите повторную регистрацию у издателя, а не редактируйте метки. Если шлюз привязывает действительные учётные данные к неверной учётной записи, её владелец политики должен исправить сопоставление. Это три разных изменения с тремя разными согласующими.

Продление заслуживает такой же аккуратности. Замена сертификата, переименование его видимой метки и перемещение человека между системами учётных записей не обязательно влияют на сопоставление одинаково. Запишите, что именно из трёх вы изменили, потому что следующий сбой будет выглядеть одинаково со стороны клиента и иначе в журнале шлюза.

Передавайте только минимальные публичные идентификаторы, которые нужны поддержке. Закрытый ключ или полный пакет личности никогда не входят в этот обмен, как бы удобно это ни делало диагностику.