Що входить до пропозиції IPsec? Поля IKE і ESP

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

Дві переговори з окремими списками пропозицій

IKEv2 будує дві асоціації безпеки. Перша — IKE SA, яка захищає сам обмін керування, а друга — CHILD SA, яка передає ваш трафік через ESP. Кожна має власний список пропозицій, і сторона може прийняти одну й відхилити іншу.

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

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

Які поля належать якій пропозиції

Набір полів невеликий, але в двох переговорах він не однаковий. Читайте таблицю рядок за рядком, бо поле в одному стовпці може бути відсутнім в іншому. Синтаксис залежить від реалізації; документація пропозицій strongSwan — одне конкретне джерело.

Поле шифрування називає шифр і, у більшості синтаксисів, довжину його ключа. Поле цілісності називає хеш, яким автентифікується шифротекст, а PRF називає функцію, що виводить ключовий матеріал для IKE SA. Група DH створює свіжий спільний секретний матеріал, тому вона присутня з обох боків, але з різною метою.

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

Як обирається одна повна пропозиція

Кожна пропозиція — це набір, і сторона-відповідач шукає набір, у якому кожне обов'язкове поле прийнятне. Два списки можуть обидва містити AES і SHA-256 і все ж не мати сумісного запису, бо довжина ключа, PRF або група DH різняться. Порівняння відбувається за пропозицією, а не за алгоритмом.

Коли нічого не збігається, сторона-відповідач надсилає NO_PROPOSAL_CHOSEN із типом SA, який не вдався. Прочитайте, до якого списку пропозицій належить повідомлення, перш ніж правити конфігурацію; зміна алгоритмів ESP при відхиленій пропозиції IKE марнує цикл налагодження.

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

AEAD видаляє поле, а не додає його

AES-GCM і ChaCha20-Poly1305 автентифікують і шифрують за одну операцію. Коли будь-який із них вибрано для ESP, алгоритм цілісності окремо не узгоджується, бо конструкція AEAD уже його покриває. Тому пропозиція, що поєднує AES-GCM із SHA-256, у найкращому разі надлишкова, а в найгіршому відхиляється.

PRF залишається окремим на боці IKE, оскільки виводить ключі для каналу керування, а не захищає корисне навантаження. Саме тому пропозиція IKE може законно поєднувати шифр AEAD із PRF і групою DH, тоді як відповідна пропозиція ESP перелічує лише шифр AEAD і необов'язкову групу PFS.

Довжина ключа є частиною токена шифрування, тому AES-128-GCM і AES-256-GCM — різні пропозиції. Профіль, скопійований із посібника, що припускав 256-bit ключі, не збіжиться з кінцевою точкою, налаштованою на 128-bit, хоча обидва рядки кажуть AES-GCM. Дві сторони можуть домовитися про родину шифрів і все ж відхилити одна одну через число після дефіса.

Читайте встановлену SA, а не конфігурацію

Налаштований список пропозицій — це пропозиція; встановлена SA — результат. На strongSwan і в ядрі Linux доступні обидва подання:

sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policy

swanctl --list-sas друкує узгоджені алгоритми для кожної SA, включно з тим, чи використовує CHILD AEAD. ip xfrm state показує, що ядро фактично встановило, і саме там підтверджується, що оновлення ключів не відкотилося до іншого набору, ніж задокументований.

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