Сплануйте налаштування IKEv2, що підходять більш ніж одному клієнту
Робочий профіль на одному комп’ютері — це успішний тест одного клієнта. Узгодьте контракт ідентичності, виберіть підтримуваний перетин, потім перевірте оновлення й сон для кожної платформи.
Робочий профіль на одному комп’ютері — це успішний тест одного клієнта. Це не розгортання на кількох платформах, і якщо ставитися до нього так, виникає знайомий шаблон підтримки: Windows підключається, телефон зривається на перевірці ідентичності, а керований ноутбук перепідключається щоразу після пробудження. Відмінності реальні й здебільшого передбачувані, тому план має бути матрицею, а не скриншотом.
Спочатку визначте контракт ідентичності
Задокументуйте ідентичність сервера, довіру до сертифіката та метод автентифікації клієнта до обговорення алгоритмів. Ці три визначають, чи може клієнт взагалі автентифікуватися, і саме їх платформи виражають по-різному.
Перевірте, як кожна платформа називає очікуваний ідентифікатор і як поводиться з альтернативними іменами суб’єкта. Профіль, що приймає ім’я сервера на одному клієнті, може відхилити той самий сертифікат на іншому, бо поле ідентифікатора заповнюється іншим значенням.
| Contract element | What to decide | Where platforms diverge |
|---|---|---|
| Server identity | Name or address the client must see | Identifier field and SAN matching |
| Client authentication | Certificate, EAP method or both | Which EAP variants exist and how prompts appear |
| Trust anchor | Which CA and how it is delivered | Store location and provisioning path |
Далі виберіть криптографічний перетин
Порівняйте пропозиції, які може надати кожен підтримуваний клієнт, і виберіть сучасний перетин, який дозволяє також шлюз. Не вмикайте надмірно великий застарілий список, щоб підключився один старий пристрій, бо цей список стає типовим для шлюзу для всіх наступних. Запишіть, чому кожен застарілий варіант досі там. Якщо ніхто не може назвати пристрій, якому він потрібен, це не вимога.
Тримайте налаштування IKE і CHILD окремо в плані. Пропозиція, прийнятна для обміну IKE, не стає автоматично прийнятною для захищеного трафіку, і ці дві узгоджуються окремо. Шлюз, що приймає пропозицію на одному рівні, все ще може відхилити її на іншому, і журнал покаже збій, який виглядає так, ніби перший рівень успішно пройшов.
Надавайте облікові дані через перевірений процес і тримайте пароль користувача, спільний секрет і приватний ключ клієнта в окремих полях. Проби й помилки на однойменних блоках — це шлях, яким робочий тест стає невідтворюваним.
Перевіряйте життєвий цикл, а не стійкий стан
Для кожного клієнта перевірте початкову автентифікацію, цільовий застосунок, розв’язання DNS і покриття родин адрес. Потім відпрацюйте частини, які з’являються лише пізніше: оновлення, сон і звичайну зміну мережі.
Підтримка MOBIKE й поведінка під час повторної автентифікації можуть відрізнятися від щойно виміряного стійкого результату. Записуйте подію та стан асоціації на той момент, а не лише те, чи інтерфейс зрештою виглядає підключеним.
Визначте, що може робити прямий трафік, поки VPN недоступний. Це рішення про політику, окреме від того, чи клієнт перепідключиться, і більшість розгортань відповідає на друге питання, ігноруючи перше. Запишіть відповідь у нотатках про розгортання поруч із назвами профілів. Комусь вона знадобиться під час збою, і в нього не буде часу відновлювати її.
Використовуйте перевірки ідентичності сервера, коли одна платформа не погоджується
Коли профіль працює на одній платформі, а інша відхиляє його ім’я, порівняйте ідентифікатор, який клієнт справді надіслав, з ідентифікаторами, які несе сертифікат. Це порівняння розв’язує більшість таких випадків швидше, ніж зміна списків шифрів.
Зберігайте перевірену матрицю разом із джерелом конфігурації та процедурою оновлення. Коли підтримка старого клієнта завершується, навмисно вилучіть його виняток, а не залишайте слабші налаштування сумісності прихованими у шлюзі для наступного аудиту. Документація strongSwan щодо IKEv2 — корисне джерело про те, як налаштовуються обміни.