Шифри Windows і strongSwan: узгодьте правильний рівень
Однакова довжина ключа ще не означає сумісний набір. Відокремте політику IKE від перетворень ESP і тримайте CBC і GCM у різних пропозиціях.
Обидві сторони кажуть AES-128, а тунель усе одно не піднімається. CBC і GCM — це різні перетворення, які випадково мають однакову довжину ключа, і клієнт, що пропонує одне, не задовольняє шлюз, який приймає лише інше. Слово AES описує родину, а не домовленість.
Є й друга вісь, і саме вона породжує заплутані помилки.
Два рівні, два незалежні списки
IKE захищає сам обмін, а дочірня асоціація захищає трафік, який вам справді важливий. Windows показує перше як метод шифрування й метод цілісності, а друге як константи перетворення шифру й автентифікації. Ці поля не є псевдонімами одне одного, і значення, припустиме в одному, може бути безглуздим або хибним в іншому. Читання профілю з цим поділом у голові прибирає більшість плутанини.
Практичний наслідок: у вас може бути цілком прийнятна політика обміну ключами й політика каналу даних, яку партнер не прийме. Один список веде переговори, другий захищає пакети. Зміна значення в першому ніяк не впливає на другий, хоч би як схоже вони виглядали в діалозі налаштувань.
Запишіть обидва списки, перш ніж порівнювати їх зі шлюзом. Порівняння з пам'яті — це спосіб двічі відредагувати одне поле й жодного разу не торкнути інше. Тримайте консоль шлюзу відкритою поруч із профілем.
Читайте помилку поруч із пропозиціями
Етап, на якому стався збій, підкаже, який список перевіряти. Відмова на етапі початкового обміну ключами — це проблема пропозиції IKE, і вона трапляється до появи будь-якої дочірньої асоціації. Збій під час узгодження асоціації захищеного трафіку — це проблема пропозиції ESP, а обмін ключами вже успішно завершився. Загальне повідомлення про невідповідність політики від клієнта не називає жодного з етапів, тому корисним є саме власний погляд шлюзу.
swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager
Порівняйте отриману пропозицію, налаштовану пропозицію та обрану для цієї єдиної спроби. Тут важливі три різні списки, і лише останній описує те, що реально використовувалося. Процитуйте його в заявці дослівно, а не переказуйте.
Тримайте CBC і GCM як окремі альтернативи
Шлюзу, якому навмисно дозволено приймати будь-яку з родин, потрібні дві пропозиції, а не одна. У strongSwan кома розділяє альтернативи, а дефіс з'єднує компоненти одного набору. Об'єднання обох родин дефісами дає одну неможливу пропозицію замість двох прийнятних.
proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256
Перша альтернатива несе автентифіковане шифрування й усе ще називає псевдовипадкову функцію, бо виведенню ключа вона потрібна навіть тоді, коли цілісність береться з шифру. Друга альтернатива — класичне шифрування з окремим алгоритмом цілісності. Обидві залишаються залежними від того, що підтримує завантажена реалізація криптографії.
Пропозиція ESP — це не перейменована пропозиція IKE
Токен шифру виглядає однаково в обох списках, і майже нічого більше не переноситься. У пропозиції ESP немає псевдовипадкової функції обміну ключами, а її вимоги до цілісності й прямої секретності обґрунтовуються проти політики Windows на іншому боці, а не копіюються з рядка IKE. Механічне перенесення одного списку в інший дає щось, що проходить перевірку і ніколи не узгоджується.
Виберіть напрямок і дотримуйтеся його. Або шлюз зберігає політику лише з GCM, і клієнт розгортає повністю сумісну політику, або шлюз приймає обидві родини, і клієнт зберігає свій наявний набір. Увімкнення резервного варіанта, який забороняє політика безпеки, не є виправленням, хоч би як швидко він прибирав помилку.
Перевірте обидва набори, потім оновлення ключа
Підтвердьте окремо вибраний набір обміну ключами й вибраний набір трафіку, бо вони беруться з різних списків і можуть успішно спрацювати незалежно. Потім дайте відбутися оновленню ключа й підтвердьте його також. Робоче перше рукостискання й невдале оновлення ключа описують набір пропозицій, який прийнятний лише частково.
Збережіть цей доказ разом зі зміною. Повторюване відключення потребує власного запису про невдалий обмін, перш ніж хтось звинуватить таймер або дефект платформи.