Что входит в предложение 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 показывает, что ядро фактически установило, и именно там подтверждается, что обновление ключей не откатилось к другому набору, чем задокументированный.

Сохраните этот вывод рядом с конфигурацией после исправления. Когда обновление клиента меняет значения по умолчанию, записанный набор даёт базовую линию для сравнения, и сравнение указывает на сдвинувшееся поле вместо того, чтобы начинать расследование заново.