Мониторинг интерфейса туннеля IPsec: что читать

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

Пройдите их по порядку и остановитесь на первом, который не проходит.

Что интерфейс добавляет к картине

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

Выигрыш административный, а не криптографический. Интерфейс сообщает о трафике, который несёт, и ничего не говорит о том, пригодна ли сейчас защита со стороны партнёра.

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

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

ip -s link show xfrm0
ip route get 10.20.30.40
ip xfrm state
ip xfrm policy
swanctl --list-sas
tcpdump -ni xfrm0 -c 20 host 10.20.30.40

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

Тест приложения идёт последним и намеренно: успешный ping на противоположную сторону туннеля не доказывает, что служба за ней принимает соединения.

Сравните внутренние счётчики с внешними

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

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

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

Наблюдайте это при перевыпуске ключей и отказе

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

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

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