Почему ваш туннель IPsec работает до первого обновления ключа CHILD SA

Туннель поднялся, ping ответил, и все подписались. Четыре часа спустя сессия падает, стороны записывают ошибку предложения или обмена ключами, и первое предположение — что-то изменилось в сети. Ничего не изменилось. Туннель, который несёт трафик, доказал, что две стороны согласны в том, как аутентифицироваться и как защищать первую дочернюю ассоциацию, и ничего не доказал об обмене ключами, который они потребуют при обновлении. Несоответствие сидит в промежутке между этими двумя событиями.

Подключено не значит, что настройки PFS совпадают

В IKEv2 первая дочерняя ассоциация создаётся во время обмена аутентификации, а её ключи выводятся из материала, который ассоциация IKE уже произвела. Отдельный обмен Diffie-Hellman для этой дочерней ассоциации не выполняется, поэтому политика, требующая его при обновлении, при подъёме не проверяется.

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

Где несоответствие прячется в строке предложения

В strongSwan группа добавляется к дочернему предложению, поэтому строка вроде aes256gcm16-prfsha256-ecp256 выглядит как выбор шифрования, но также несёт требование обмена ключами. Сторона, предлагающая только aes256gcm16-prfsha256 такого требования не имеет, и два списка пересекаются по шифрованию, но расходятся по обмену.

Читайте дочернее предложение и предложение IKE как отдельные списки. Группа, появившаяся в списке IKE, ничего не говорит о дочернем списке, а редактирование одного при чтении другого — обычный способ это упустить.

Читайте сбой, а не файл, который вы правили

Найдите notify, завершивший обмен. Обновление ключа дочерней ассоциации, возвращающее «нет приемлемого предложения», указывает на списки предложений; запрос на обновление, никогда не получающий ответа, указывает на путь или на сторону, которая перестала слушать. Эти два требуют разных исправлений, и формулировка строки журнала их разделяет.

Подтвердите работающую конфигурацию, а не ту, что на диске. Файл, сохранённый но не загруженный, или соединение, перечитанное из другого include, дадут несоответствие, которое не исправит никакое редактирование видимого файла.

Три события, которые все называют обновлением ключа

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

Отметьте, какое событие называет сторона, и проверяйте предложения только для этого события. Измените один список, перезагрузите и снова вызовите то же событие. Если журнал называет повторную аутентификацию, читать нужно предложение IKE. Если он называет обновление ключа дочерней ассоциации, важную группу несёт дочернее предложение.

Отключение обновления — не исправление

Если задать время обновления ключа равным нулю, сбойный обмен подавляется, и туннель живёт до демонтажа или перезапуска стороны. Вы купили более долговечный ключ и несоответствие, которое снова вас встретит при миграции, аудите или обновлении от поставщика. То же относится к срокам, растянутым далеко за пределы политики, которую ожидает другая сторона.

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

Докажите это обменом, который провалился

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

После этого верните обычный срок и сохраните обе записи событий, неудачную и успешную. Доказательство, которое вам нужно, — что соединение переживает собственный жизненный цикл, а не что оно пережило ping.