Как я мониторю IPsec VPN и не путаю поднятый туннель с работающей связью

Почему зелёный статус меня перестал устраивать

На одном из внедрений жалоба выглядела противоречиво: шлюз показывал VPN как поднятый, а сотрудники периодически не получали ответ от внутреннего сервиса на другой площадке. Я не стал объявлять неисправным весь IPsec по одному тайм-ауту. Сначала разложил соединение на наблюдаемые слои и привязал их к одной временной шкале. Отдельно нужны управляющая ассоциация IKE, ассоциации передачи данных, запись маршрута или policy, фактические счётчики и запрос до конечной цели. Зелёная IKE SA говорит лишь о том, что стороны согласовали защищённый управляющий канал и знают соседа. Она не доказывает, что создан подходящий child SA и что пакет конкретной подсети попадёт под шифрование. Именно это различие стало основой шаблона: Zabbix хранит не сводный флаг «туннель работает», а несколько независимых признаков. Событие формируется по их сочетанию, поэтому дежурный видит не абстрактный VPN down, а, например, живую IKE SA при отсутствии нужного child SA или сквозного ответа. На панели я вывожу эти слои строками, а не одним круговым индикатором. Рядом помещаю время последнего изменения каждого признака: так становится видно, что сквозная ошибка началась после обновления policy, хотя управляющая сессия не прерывалась.

Как я разделил IKE SA, child SA и установку пути

Из доступного только для чтения API шлюза я забираю идентификатор соединения, состояние и возраст IKE SA, затем список child SA с направлением, SPI и фазой жизненного цикла. Поля производителя нормализую зависимыми элементами, но исходный ответ сохраняю короткое время для разбора смены состояния. Следующим элементом проверяю, установлена ли требуемая policy в policy-based схеме либо маршрут и привязка к интерфейсу в route-based схеме. Эти признаки нельзя склеивать: после изменения конфигурации IKE способна остаться активной, старый child SA — доживать, а новая policy — не установиться. Возраст ассоциации использую как контекст, а не как показатель качества. При rekey старая и новая SA некоторое время могут сосуществовать, поэтому краткое удвоение записей нормально, если новая принимает трафик и старая корректно исчезает. Отдельно отмечаю повторяющиеся ошибки rekey: одиночный переход без потери пакетов не тревожит, а серия неудачных согласований вместе с остановкой счётчиков уже требует разбора предложений и времени на сторонах. DPD также трактую осторожно: он помогает обнаружить потерю IKE-соседа, но успешный DPD не подтверждает доступность сервера за этим соседом.

Селекторы определяют, какой трафик вообще станет IPsec

На следующем шаге я сверяю traffic selectors с согласованной картой сетей. Для каждой значимой пары локальной и удалённой подсети храню нормализованное представление и проверяю наличие пары с обеих сторон, учитывая направление. Это ловит ситуацию, когда туннель формально существует, но интересующий адрес не входит в negotiated selectors или одна сторона сузила диапазон иначе. Я не помещаю реальные адреса клиента в общий шаблон: ожидаемые сети задаются защищёнными макросами на конкретном узле, а в событиях остаются обезличенные обозначения сегментов. Одновременно проверяю firewall и NAT. Правило должно разрешать поток в нужной зоне, а исключение из source NAT — срабатывать до общего masquerade; иначе пакет меняет источник и перестаёт соответствовать селектору либо удалённой политике. В route-based варианте дополнительно смотрю таблицу маршрутизации и порядок policy routing. Так проверка отвечает не только на вопрос «есть ли SA», но и на более полезный: попадёт ли выбранный контрольный пакет в правильную цепочку обработки.

Счётчики показывают движение, но требуют контекста

Для каждого child SA я собираю входящие и исходящие байты и пакеты. Абсолютное значение малоинформативно, поэтому Zabbix рассчитывает приращение и сопоставляет его с моментом контрольного запроса. Если запрос отправлен, исходящие пакеты выросли, а входящие нет, я исследую удалённую фильтрацию, обратный маршрут и удалённый NAT. Если оба счётчика стоят, хотя маршрут выбран правильно, проверяю локальную policy и соответствие селекторов. Если счётчики растут в обе стороны, но приложение не отвечает, IPsec уже не главный подозреваемый. Сброс счётчика не считаю потерей трафика автоматически: он бывает при rekey, пересоздании child SA или перезагрузке устройства. Для корреляции сохраняю SPI, время появления SA и системное время шлюза. Скорость роста тоже не превращаю в обязательный минимум: резервный туннель вправе молчать. Значим именно ожидаемый отклик на управляемый пакет, а не постоянная фоновая активность, которую легко ошибочно принять за здоровье связи.

Откуда Zabbix получает состояние без секретов

Источник выбираю по возможностям конкретного шлюза. Предпочитаю официальный API со структурированным ответом; если его нет, беру документированные SNMP OID производителя. Журнал использую как событийное дополнение: сообщения об ошибке proposal, DPD timeout, удалении SA и rekey хорошо объясняют переход, но один лог неудобен для текущего состояния. На устройстве создаю отдельную роль мониторинга с правом только читать VPN status, маршруты, policy и интерфейсные счётчики. Ей запрещены изменение конфигурации, выполнение произвольных команд, чтение PSK, приватных ключей, содержимого сертификатного хранилища и резервных копий. Токен API или SNMPv3-реквизиты находятся в секретном хранилище либо защищённых макросах Zabbix и никогда не включаются в значения items, журнал preprocessing или название события. Если производитель отдаёт конфигурацию целиком, я не забираю такой endpoint: лучше потерять удобное поле и получить его другим безопасным способом, чем копировать чувствительные данные в историю мониторинга. Доступ проверяю отдельным входом именно под этой ролью и убеждаюсь, что страницы редактирования закрыты. Ответ API фильтрую на proxy до отправки истории: остаются технические состояния и счётчики, а серийные номера, имена учётных записей и описания с внутренними адресами отбрасываются.

Сквозной запрос из независимой контрольной точки

Главным доказательством связи я сделал активную проверку с Zabbix proxy, расположенного в том сегменте, откуда действительно должен идти рабочий трафик. Источник запроса фиксирован, чтобы он совпадал с локальным селектором и ожидаемым правилом firewall. Целью служит разрешённый адрес или служебный endpoint за удалённым шлюзом; тип проверки выбираю по реальному протоколу — TCP-соединение, HTTP-запрос либо ICMP, если он разрешён. Проверка не передаёт пользовательские данные и не требует учётной записи приложения. Я сохраняю результат, длительность и диагностический код, а затем коррелирую их с дельтами IPsec-счётчиков. Для нескольких удалённых подсетей нужны отдельные цели: успех в одной паре селекторов ничего не говорит о другой. Интервал подбираю по критичности сервиса, стоимости запроса, поведению канала и требованиям эксплуатации. Единого правильного таймера или общего SLA-порога здесь нет; спутниковый резерв, постоянный офисный канал и редкий технологический обмен имеют разные нормальные профили.

Что я проверяю, прежде чем обвинить туннель

Когда сквозная проверка не проходит, я сначала воспроизвожу её из той же контрольной точки и не переключаюсь на ноутбук администратора с другим маршрутом. Затем проверяю DNS: какой адрес получил proxy, не истекла ли запись и совпадает ли результат с адресом, включённым в селекторы. После этого отделяю проблему MTU и MSS. Маленький запрос может проходить, а крупный зависать из-за лишнего IPsec overhead, заблокированного Path MTU Discovery или отсутствующего MSS clamping. Я сравниваю запросы разного размера и признаки фрагментации, не меняя параметры вслепую. Третья ветвь — асимметричная маршрутизация: исходящий пакет увеличивает счётчик нужного child SA, а ответ уходит через другой WAN, соседний VPN или маршрут по умолчанию. Здесь помогают таблицы маршрутов обоих концов, firewall state и счётчики обратного направления. Полезен одновременный краткий захват заголовков на доверенных интерфейсах, если он согласован: на внешнем интерфейсе я ожидаю ESP или инкапсуляцию, на внутреннем — исходный поток. Содержимое пакетов не сохраняю. Лишь после этих проверок связываю отказ с IPsec. Такой порядок не маскирует проблему DNS перезапуском SA и не лечит неправильный обратный маршрут снижением MTU.

Контролируемый failover и заранее готовый откат

Завершая внедрение, я провожу согласованный тест переключения в разрешённое окно. До него фиксирую активные SA, селекторы, маршруты, счётчики, состояние резервного пути и результаты сквозной проверки. Затем меняется один фактор: основной путь штатно выводится из выбора тем способом, который предусмотрен конфигурацией. Я наблюдаю, как удаляется или перестаёт принимать трафик соответствующий child SA, появляется резервная policy или маршрут и восстанавливается запрос из того же proxy. Одновременно контролирую, что трафик не вышел в открытый интернет и не попал под нежелательный NAT. Критерии остановки определяются для конкретного контура заранее, без универсальных секунд и процентов. Если резервный путь не устанавливается, селекторы отличаются или контрольный сервис недоступен, я возвращаю исходный приоритет маршрута либо включаю отключённый штатный объект, проверяю восстановление прежней SA и повторяю сквозной запрос. После успешного теста тоже возвращаю согласованную рабочую схему, если переключение было проверочным, и сохраняю только обезличенную временную линию. Так мониторинг подтверждает не красивый статус, а управляемое поведение связи и возможность безопасного возврата.

Отвергнутые альтернативы

• Считать статус IKE connected доказательством связиIKE SA подтверждает управляющий обмен, но нужный child SA, селекторы, маршрут, policy или прохождение полезного трафика могут отсутствовать.
• Проверять только внешний адрес VPN-шлюзаОтвет внешнего интерфейса подтверждает доступность самого устройства, но не шифрование и доставку до ресурса удалённой сети.
• Опираться только на DPDDPD обнаруживает состояние IKE-соседа, однако не проверяет приложение, обратный маршрут, firewall и совпадение селекторов.
• Диагностировать каждый тайм-аут как падение VPNПохожий симптом создают DNS, MTU или MSS, асимметричная маршрутизация, фильтрация и состояние самого целевого сервиса.
• Выдать системе мониторинга административный доступДля чтения состояния и счётчиков не нужны изменение конфигурации, просмотр PSK, приватных ключей или экспорт сертификатов.

Конфигурация и сбор

Отдельная роль только для чтения VPN status, child SA, маршрутов или policy, интерфейсных счётчиков и разрешённых событий. Доступ к изменению конфигурации, PSK, приватным ключам, экспорту сертификатов и резервным копиям не требуется.

• Получить через официальный API или SNMP состояния IKE SA и child SA с идентификаторами жизненного цикла.
• Сверить установленные маршруты либо policy и согласованные traffic selectors с обезличенной картой ожидаемых пар.
• Снять двунаправленные счётчики до и после разрешённого контрольного запроса из Zabbix proxy.
• Прочитать только относящиеся к соединению события DPD и rekey, не выгружая конфигурацию и секреты.

Контролируемая проверка и свидетельство

В согласованное окно штатно исключается основной путь и наблюдается переход на заранее настроенный резерв: смена SA, установка маршрута или policy, рост счётчиков и восстановление запроса из прежней контрольной точки. Тест немедленно прекращается при выходе трафика вне ожидаемой policy, срабатывании нежелательного NAT или влиянии на соседние связи.

Фрагмент рабочего регламента

• Разделить сводный статус на IKE SA, child SA и установленный путь для нужной пары селекторов.
• Сопоставить контрольный запрос с приращением входящих и исходящих пакетов конкретного child SA.
• Проверить DNS, размер пакета, MTU или MSS, обратный маршрут, firewall и NAT до пересоздания SA.
• Сверить DPD и rekey по разрешённым событиям производителя, не запрашивая ключевой материал.

Откат

До переключения сохраняются текущий приоритет путей, активные идентификаторы SA и результаты проверки. Откат возвращает прежний штатный объект или приоритет, после чего подтверждаются ожидаемые selectors, установка исходного маршрута либо policy, двусторонний рост счётчиков и ответ контрольной цели из того же proxy.

Ограничения вывода

Нельзя назначить общий polling interval, длительность DPD, время rekey, число неудачных проверок или одну границу SLA для всех IPsec VPN. Допустимое поведение зависит от производителя, типа канала, профиля трафика, согласованных параметров, резервирования и требований конкретного сервиса. Поднятая IKE SA и успешный DPD не заменяют проверку child SA, пути и конечной доступности.