iPhone IKEv2 до RouterOS: який ідентифікатор куди ставиться
Чотири окремі твердження визначають тунель IKEv2 на iOS: адреса, яку набирають, очікувана ідентичність сервера, заявлена ідентичність клієнта та сертифікатний матеріал.
Досягнення шлюзу MikroTik вирішує лише транспортну половину розгортання IKEv2 і більше нічого. Далі чотири окремі твердження визначають, чи сформується тунель: адреса, яку набирає телефон, ідентичність сервера, якої він очікує, ідентичність, яку він заявляє для себе, і сертифікатний матеріал, що підкріплює це твердження. Перевіряйте їх у цьому порядку й зупиніться на першому, що не збігається з тим, що представляє шлюз. Кожне редагується в іншому місці, тому неправильне редагування зазвичай переносить відмову, а не усуває її.
| Setting | What it decides | What it has to agree with |
|---|---|---|
| Remote address | where IKE packets are sent | a reachable name or address for the gateway |
| Remote Identifier | which server identity is expected | the gateway certificate name and the peer identity RouterOS presents |
| Local Identifier | who the phone claims to be | the client certificate name and the RouterOS identity entry |
| Certificate payload | trust plus proof of key possession | the issuing chain and a usable client private key |
Перевірте поля профілю в тому порядку, у якому їх використовує обмін
Віддалена адреса — це призначення першого пакета IKE і більше нічого. Віддалений ідентифікатор — це те, чим телефон очікує побачити шлюз, і це ім'я, а не маршрут. Заповнення обох одним і тим самим іменем хоста працює, коли сертифікат шлюзу містить це ім'я, і дає збій так, що він виглядає як проблема маршрутизації, коли не містить. Читайте профіль як послідовність тверджень, а не як список полів для заповнення.
Локальний ідентифікатор — це власне твердження телефона, і він має бути іменем, яке запис ідентичності RouterOS приймає для клієнтського сертифіката, який пред'являє телефон. Якщо вони не збігаються, шлюз відхиляє з'єднання після того, як сам сертифікат пройшов перевірку, і журнал виглядає як проблема авторизації, а не іменування.
Перевірте ідентифікатори щодо того, що представляє шлюз
Запис вузла в RouterOS, налаштований для автентифікації за сертифікатом, пред'являє власний сертифікат, і його ідентичність береться з цього сертифіката, якщо ви не налаштували інакше. Якщо віддалений ідентифікатор телефона називає DNS-ім'я шлюзу, сертифікату шлюзу потрібне це ім'я в місці, яке телефон прийме, зазвичай в альтернативному імені суб'єкта. Сертифікат, виданий на інше загальне ім'я, не пройде перевірку, навіть якщо ключ і ланцюг бездоганні.
Керовані профілі Apple можуть також нести обмеження імені сертифіката, яке оцінюється додатково до полів ідентифікатора. Вивчайте вміст, а не виводьте ім'я для перевірки з того, що показує екран налаштувань, бо це не те саме налаштування.
Перевірте, що клієнтський сертифікат — це ключ, а не лише якір довіри
Імпорт сертифіката CA дає телефону те, чим можна перевірити шлюз. Він не дає телефону клієнтської ідентичності, а автентифікація за сертифікатом потребує клієнтського кінцевого сертифіката та його закритого ключа, доставлених разом схваленим шляхом реєстрації. PKCS#12, зібраний без закритого ключа, дає профіль, який чисто встановлюється і нічого не автентифікує.
Клієнтському кінцевому сертифікату потрібна також ідентичність, якої очікує сторона RouterOS, тобто суб'єкт або альтернативне ім'я суб'єкта мають збігатися з відповідною конфігурацією ідентичності. Випуск клієнтських і серверних сертифікатів з одного CA робить ланцюг зручним і не робить два кінцеві сертифікати взаємозамінними.
Перевірте, що політика RouterOS приймає це ім'я
На шлюзі запис вузла задає режим обміну й метод автентифікації, а запис ідентичності пов'язує прийняту віддалену ідентичність із сертифікатом і з політикою, що йде за нею. У RouterOS v7 ця пара виражається записами вузла й ідентичності IPsec, наприклад вузол IKEv2 з auth-method=digital-signature. Перевіряйте фактичний вміст меню в установленій версії, а не посібник, написаний для старішої.
Тут же невідповідність найдешевше виправити, бо шлюз може повідомити і отриману ідентичність, і бажану. Розширення прийнятої ідентичності, щоб приглушити помилку, прибирає зв'язок, який надавав розгортанню сенсу.
Перевірте, на якому етапі стався збій, перш ніж щось редагувати
Прочитайте спробу з обох боків і класифікуйте її, перш ніж змінювати пропозицію. Невідповідність пропозиції, відсутній ключ підпису, недовірений видавець, неправильний ідентифікатор вузла й відхилена авторизація клієнта виглядають з телефона як мертвий тунель, і кожен має іншого відповідального. Зміна всіх п'яти налаштувань одразу гарантує, що ви нічого не дізнаєтеся з результату.
Запишіть пред'явлену ідентичність, очікувану ідентичність, видавця й серійний номер сертифіката та назву відповідної політики, тримаючи закриті ключі й секрети профілю поза цим записом. Коли автентифікація вдасться, перевірте приватну службу та її відповідь, бо призначення адрес, селектори, DNS і політика доступу все ще мають працювати після завершення обміну IKE.