Почему нагруженный туннель IPsec рано меняет ключи: пределы по времени и объёму

Примерно каждые пятьдесят минут туннель на загруженном канале падает на несколько секунд, и первый подозреваемый — часы. Ассоциации могут завершаться по предельному времени или по количеству байтов, и та граница, что наступит первой, отправляет их на покой. На канале с реальным трафиком предел объёма может сработать задолго до конца настроенного часа. Значит, «слишком рано» — это утверждение о часах, а не об ассоциации.

Считайте то, что считает ассоциация, а не интерфейс

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

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

Мягкий и жёсткий пороги — два разных события

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

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

Читайте эффективный срок жизни из рабочего состояния

На strongSwan swanctl --list-sas печатает сводку ассоциации с временами смены ключей и жизни, поэтому значение, которое демон намерен применить, видно без догадок. На хосте Linux без представления демона ip xfrm state сообщает настроенные мягкие и жёсткие пределы байтов и пакетов рядом с текущими счётчиками. Эти два показания отвечают на разные вопросы, и оба стоит сохранить в заявке.

swanctl --list-sas
ip -s xfrm state

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

Следите за обменом, который заменяет SA

Держите три обновления отдельно, потому что они отказывают по-разному: смена ключей IKE SA строит новую управляющую ассоциацию, смена ключей CHILD SA заменяет ассоциацию данных, а повторная аутентификация повторяет обмен идентичностью. В IKEv2 каждая сторона решает собственные сроки жизни, а не договаривается об одном общем значении, поэтому обмен, который вы не инициировали, обычен. Несовпадение perfect forward secrecy — частая причина того, что новая child SA умирает именно на интервале смены ключей, и это выглядит точно как сбой таймера, пока кто-нибудь не прочитает предложение.

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

Докажите обновление, а не скрывайте его

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

Вывод такой формы выдерживает проверку, а изменённое значение таймера, из-за которого соединение выглядело тихим полдня, — нет. Если сдвинулся только таймер, доказательства сдвинулись вместе с ним.