IKEv2 NO_PROPOSAL_CHOSEN: який етап відхилив набір?

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

Спочатку: який обмін було відхилено

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

Саме сповіщення не ідентифікує обмін. Рядок над ним називає узгоджувану SA, і це ім'я вказує на список пропозицій, який слід перевірити.

Порівнюйте повні набори, а не окремі ключові слова

Пропозиція — це комбінація: алгоритм шифрування, цілісність або AEAD, група обміну ключами та будь-яка псевдовипадкова функція. Порівнювати лише назву шифрування — звичайна помилка, адже двоє партнерів можуть погодитися щодо AES-256 і все одно розійтися щодо SHA-1 проти SHA-256. Випишіть запропонований і дозволений набори поруч на невдалому етапі, потім шукайте порожній перетин.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

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

Набір IKE і набір ESP — різні об'єкти

Редагування пропозиції IKE не виправить відхилену пропозицію CHILD, і навпаки так само. У strongSwan це окремі налаштування, приблизно proposals = aes256-sha256-modp2048 для IKE SA і окремий список ESP для CHILD SA. Змініть список, що відповідає невдалому обміну, потім перечитайте журнал, а не припускайте, що виправлення спрацювало.

Для CHILD SA відповідним налаштуванням є список пропозицій ESP, а не список IKE. Копіювання рядка IKE до нього створює конфігурацію, яка розбирається, але узгоджує неправильний об'єкт.

Робочий тунель, який падає під час оновлення ключа

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

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

ipsec statusall | grep -E "IKE:|ESP:"

Виберіть перетин, потім підтвердьте обидві фази

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

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