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 документация по предложениям охватывает синтаксис обоих списков.