VPN-сертифікат на Mac: який обліковий запис бачить шлюз?
Мітка профілю, облікові дані та поле облікового запису відповідають на різні питання. Простежте суб’єкт до зіставлення на шлюзі, перш ніж щось перейменовувати.
Профіль показує ваше ім’я, видима мітка сертифіката каже інше, а журнал шлюзу фіксує третій ідентифікатор. Жоден із них не бреше, і саме в цьому проблема: три різні поля читають так, ніби вони відповідають на одне питання. З’єднання подає облікові дані, ідентифікатор IKEv2 та обліковий запис, і шлюз вирішує, що з них що дозволяє.
Три особи в одному з’єднанні
Видиме ім’я профілю — це мітка для людей. Воно вибирає з’єднання і більше нічого. Сертифікат — це облікові дані, і те, чи може він щось довести, залежить від того, чи має клієнт відповідний закритий ключ. Поле облікового запису — це твердження про суб’єкт, і сервер має право зіставити його з іншою локальною особою.
Коли автентифікація не вдається, запитайте, до чого з трьох належить помилка. Відхилені облікові дані, невідомий ідентифікатор і вимкнений обліковий запис дають різні повідомлення, а ставлення до них як до однієї «проблеми сертифіката» веде вас до неправильної консолі.
Читайте власні поля за їхнім призначенням
У керованій власній конфігурації IKEv2 посилання на корисне навантаження Apple розділяє значення, а метод автентифікації визначає, яка комбінація потрібна:
| Field | Identifies | Common misreading |
|---|---|---|
| AuthName | Username for the configured arrangement | Assuming it is the certificate subject |
| LocalIdentifier | IKEv2 client identifier | Assuming it must equal the username |
| PayloadCertificateUUID | Referenced credential payload | Assuming any installed certificate will do |
Сертифікат і вхід через EAP можуть мати різні ролі в одному з’єднанні. Не змушуйте кожне поле містити той самий текст лише тому, що так робить одне з них, і не припускайте, що зміна одного скасовує інші. VPN-програма третьої сторони може показувати зовсім іншу модель; використовуйте її задокументований вибір особи замість перенесення туди власних назв полів.
Сертифікат сервера — це не особа клієнта
Сертифікат, що перевіряє шлюз, є якорем довіри. Він доводить, що ви досягли очікуваного сервера. Особа клієнта — це інший об’єкт: вона включає доступ до закритого ключа, який доводить, що сторона, яка підключається, є тією, за кого вона себе видає. Перейменування видимого облікового запису не може перетворити одне на інше.
Саме тут добросовісне виправлення йде не так. Імпорт CA-сертифіката шлюзу до сховища клієнта нічого не дає для автентифікації клієнта, а позначення цього запису іменем користувача не робить його особою користувача. Два об’єкти живуть у різних частинах профілю й відповідають на різні питання.
Простежте суб’єкт до зіставлення на шлюзі
Підтвердьте, для чого видано облікові дані: для цього користувача, цього пристрою чи спільної ролі. Обліковий запис входу Mac не обов’язково є цим суб’єктом, а сертифікат, скопійований з іншої машини, зберігає особу тієї машини, для якої його видано.
Потім порівняйте фактичні облікові дані, а не мітку. Видавець, серійний номер і відбиток дають вам і адміністраторові змогу підтвердити, що йдеться про один об’єкт. Показані імена можна редагувати, і вони часто дублюються, що робить їх найгіршим можливим ідентифікатором під час інциденту.
Останній крок — на шлюзі. Попросіть його власника зіставити одне з’єднання з поданими ідентифікаторами та з правилом зіставлення облікових записів, яке їх використало. Мітка на боці клієнта не може встановити, що вирішив сервер, а правило, яке зіставляє сертифікат із вимкненим обліковим записом, зазнаватиме збою, поки всі поля на боці клієнта виглядають правильно.
Виправте шар, якому належить невідповідність
Якщо профіль указує на неправильні облікові дані, виправте посилання або вибір. Якщо облікові дані належать іншому суб’єктові, пройдіть повторну реєстрацію у видавця замість редагування міток. Якщо шлюз прив’язує дійсні облікові дані до неправильного облікового запису, його власник політики має виправити зіставлення. Це три різні зміни з трьома різними погоджувачами.
Продовження заслуговує такої ж уваги. Заміна сертифіката, перейменування його видимої мітки та переміщення людини між системами облікових записів не обов’язково впливають на зіставлення однаково. Запишіть, що саме з трьох ви змінили, бо наступний збій виглядатиме однаково з боку клієнта і інакше в журналі шлюзу.
Передавайте лише мінімальні публічні ідентифікатори, потрібні підтримці. Закритий ключ або повний пакет особи ніколи не є частиною цього обміну, хоч би як це полегшило діагностику.