Определение мёртвого пира IKEv2 не проверяет ваше приложение

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

Прочитайте два вида доказательств по отдельности, прежде чем менять таймер.

О чём на самом деле спрашивает проверка живучести

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

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

Прочитайте ассоциации безопасности до браузера

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

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

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

Отказ маршрута выглядит точно как мёртвый пир

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

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

Держите таймеры вне диагностики

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

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

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