IKEv2: обновление ключей против повторной аутентификации — почему соединение падает позже

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

Две операции, которые снаружи выглядят похоже

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

Повторная аутентификация идёт дальше: она устанавливает новые аутентифицированные отношения, а значит, учётные данные оцениваются заново. Всё, что истекло, было отозвано или изменилось в каталоге, становится видимым в этот момент.

Что на самом деле заменяет обновление ключей

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

Это разделение объясняет знакомый сценарий: трафик идёт хорошо, затем обновляется CHILD SA и предложение больше не подходит, потому что кто-то недели назад изменил фазу 2 на одной стороне. Изменение лежало там безвредно, пока обновление его не задействовало.

Несовпадения времени жизни ведут себя так же. Сторона, которая первой достигает своего предела, начинает обмен, а другая должна его принять.

Что повторно оценивает повторная аутентификация

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

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

Некоторые реализации накладывают старое и новое состояние во время повторной аутентификации. Другие создают короткий разрыв. Поэтому одинаковые настройки у двух поставщиков могут дать разный пользовательский опыт. Проверяйте поведение, а не предполагайте, что стандарт это предписывает.

Прочитайте метки времени, прежде чем что-то менять

Зафиксируйте момент сбоя вместе с состоянием ассоциации до и после. Если старая ассоциация была заменена без обмена аутентификации, вы были на границе обновления. Если непосредственно перед сбоем появляется обмен AUTH, вы были на повторной аутентификации.

strongSwan предоставляет это как отдельные настройки: rekey управляет обновлением ключей, reauth управляет тем, происходит ли новая аутентификация, а значения margin решают, насколько заранее до истечения начинается каждая. документация по обновлению ключей описывает это взаимодействие, и её стоит прочитать, прежде чем копировать срок из сообщения на форуме.

Отличайте всё это от обычной потери сети. Разорванное соединение даёт событие обнаружения мёртвого партнёра или шторм повторных передач, а не чистый обмен с совпадающими предложениями.

Измените то, что сломалось

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

Растягивание сроков, чтобы избежать симптома, — единственный вариант, который всегда выглядит сработавшим и никогда не срабатывает.

Проверьте контролируемое обновление

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

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