Вхідний IPsec-пір не відповідає жодному профілю? Перевірте чотири поля

Ваш пір повідомляє, що тунель піднято, ваша сторона не показує жодної асоціації безпеки, а файл конфігурації явно містить відповідну назву з'єднання. Усі три твердження можуть бути правдивими одночасно. Вхідні переговори зіставляються з робочою конфігурацією за адресою піра, ідентичністю, яку він подає, і трафіком, який він пропонує. Файл на диску, який так і не було завантажено, ідентичність, що не збігається з очікуваним значенням, або пара селекторів, зсунута на один префікс — кожен із них дає тишу. Пройдіть чотири групи полів у тому порядку, у якому діє відповідач.

Почніть із пакета, а не з файлу

Відповідач отримує запит IKE, шукає визначення, здатне прийняти цього піра, і далі переходить до автентифікації та вибору трафіку. Якщо на першому кроці жодне завантажене визначення не збігається, переговори завершуються раніше, ніж будь-яка корисна помилка дійде до користувача.

Тому «конфігурація виглядає правильно» не є доказом. Питання в тому, що завантажила робоча служба і який запис вона вибрала для цієї спроби. Список стану відповідає на це однією командою, а буфер редактора відповідає на інше питання. Перевірте список, перш ніж знову змінювати файл.

Перша група полів: визначення, яке справді завантажене

Перевірте робочий стан інструментом, якому належить демон: командою стану, що перелічує завантажені з'єднання, а не буфером редактора. Переконайтеся, що очікуваний запис присутній, увімкнений для потрібної вам поведінки під час запуску і завантажений після вашої останньої правки. Збережений, але не перезавантажений файл — найчастіша причина фрази «я виправив, і нічого не змінилося».

Переконайтеся також, який файл читає служба. Дистрибутиви різняться, і з'єднання, записане в неправильний include, мовчки ігнорується, а не відхиляється. Якщо список стану взагалі не показує ваш запис, підозрюйте шлях включення раніше за синтаксис.

Друга група полів: кінцеві точки — це не ідентичності

Адреса, з якої підключається пір, і ідентичність, якою він автентифікується, — це окремі поля. Ім'я хоста, відмітне ім'я, ідентифікатор ключа й адреса можуть служити ідентичністю IKE залежно від конфігурації, і вони зовсім не мусять виглядати як публічна адреса.

Зіставлення кінцевих точок може включати й подання NAT: адреса, видима в мережі, може відрізнятися від адреси, яку пір вважає своєю. У моделі з'єднань libreswan left і right — це позначки двох учасників, а не фіксований порядок локального й віддаленого, тому копіювання робочої конфігурації з іншого майданчика із заміною адрес не є надійним перекладом.

Запишіть очікувану ідентичність обох сторін і посвідчення, яке її перевіряє. Якщо ці два рядки розходяться, жодне підлагодження адрес не дасть збігу.

Третя група полів: трафік, що захищається

Селектори описують внутрішні діапазони джерела й призначення, їхню сім'ю адрес і будь-яке обмеження протоколу чи порту. Пропозиція для адреси одного хоста — не той самий запит, що для всієї підмережі, і відповідач, налаштований на підмережу, може відхилити її або звузити.

Коли два кінці не збігаються, порівняйте передбачуваний потік з обох точок зору, а не розширюйте кожен селектор, щоб щось з'єдналося. Запитайте кожного адміністратора, який потік він, на його думку, захищає, а потім порівняйте дві відповіді. Розбіжність зазвичай полягає в префіксі хоста з одного боку й підмережі з іншого. Тунель, що збігається, бо тепер захищає все, — це інше рішення щодо безпеки, і його ніхто не схвалював.

Четверта група полів: ви читаєте одну реалізацію

Libreswan, старий Openswan і strongSwan мають різні інструменти керування, різний синтаксис конфігурації та різний порядок зіставлення. Робочий приклад одного нічого точного не каже про пріоритет вибору профілю або формулювання помилок іншого, тож перевіряйте за документацією демона на цьому хості.

Пов'яжіть одну спробу від початку до кінця: адресу джерела ініціатора, запропоновану ідентичність і запропоновані селектори — із повідомленням вибору відповідача та завантаженим записом, який воно називає. Нульові лічильники інкапсуляції й декапсуляції кажуть лише те, що спостережувані асоціації не несли ці пакети; вони не називають кінцеву точку, яка відхилила пропозицію, і не доводять, що в той момент існував відповідний запис.

Після узгодженого виправлення підтвердьте вибраний профіль і асоціацію, потім перевірте фактично дозволену службу та шлях її відповіді. Збіг профілю уможливлює переговори, а переговори — не остання перевірка доступу.