Как мы настраиваем Zabbix-мониторинг pfSense: firewall states, потери пакетов и WAN без ложных тревог

Задача: видеть качество WAN, а не доступность одной цели

В наших внедрениях запрос обычно звучит просто: сообщить, когда интернет за pfSense работает плохо или перестал работать. Но единичный ping не доказывает состояние WAN: ответ подтверждает только обмен ICMP с выбранным адресом, а его отсутствие может быть связано с фильтрацией или самой целью. Поэтому я начинаю с карты утверждений. Отдельно фиксируем доступность firewall для Zabbix, состояние WAN-интерфейса, оценку gateway monitoring, прохождение трафика через канал и состояние внешней услуги. Сначала определяем объект и границу, затем сбор, трактовку, логику события, controlled check и ограничения. Так тревога отвечает на понятный вопрос, а не превращает пропуск измерения в сообщение «интернет упал».

Граница наблюдения между firewall, шлюзом и внешней сетью

pfSense наблюдает собственные интерфейсы, PF, маршруты и назначенную контрольную цель, а не весь интернет. По документации Netgate gateway monitoring отправляет ICMP echo к gateway либо Monitor IP и показывает latency, packet loss и статус. Адрес у провайдера хорошо описывает ближний участок, но не аварию дальше; удалённая цель расширяет охват, добавляя зависимость от промежуточных сетей. Мы записываем смысл каждой цели и не считаем один адрес абсолютной истиной. В Zabbix я разделяю узел pfSense и логические сущности каналов, чтобы потерю SNMP не принять за отказ WAN. Для нескольких линий привязываем измерение к нужному пути: ответ через резерв не должен создавать ложное восстановление основного. Для каждого item указываем источник, описываемый путь и границы вывода.

Безопасный сбор через SNMP и данные pfSense

Мы настраиваем SNMP на интерфейсе управления или доверенном VPN-пути и разрешаем опрос от Zabbix server либо proxy. Community не оставляем стандартной и не публикуем в items, журналах или заметках. Документация pfSense описывает bsnmpd: MIB II даёт сведения об интерфейсах, модуль PF — о ruleset, states, interfaces, tables и очередях. Перед созданием шаблона я выполняю разрешённый read-only snmpwalk с коллектора и сохраняю перечень доступных ветвей без секрета. Состав модулей различается, поэтому одинаковый набор OID не предполагаем. В Zabbix исходные счётчики хранятся отдельно, доли получают явную формулу, отсутствие данных — собственное событие. Gateway status, latency и loss берём подтверждённым для установленной версии способом; при отсутствии безопасного источника не изображаем их SNMP-метрикой. GUI остаётся каналом операторской сверки.

Почему state table не является самостоятельным приговором

PF хранит состояния соединений для stateful-фильтрации. В Diagnostics → States видны интерфейс, протокол, источник, назначение, направление и TCP-состояние. Для мониторинга полезны число записей, настроенный максимум, их отношение и динамика. Большая таблица не доказывает перегрузку: профиль зависит от пользователей, NAT, длительности соединений и таймаутов. Резкий рост бывает нормальным пиком, а умеренное число states не исключает исчерпания другого ресурса. Я сопоставляю заполнение с state creations, ошибками и drops PF, CPU, памятью, трафиком и жалобами на соединения. При подозрении фильтрую таблицу по адресу или интерфейсу, не очищая её. Повторяющиеся SYN_SENT дают гипотезу о незавершённом handshake, но требуют packet capture, проверки маршрута и удалённой стороны. Тревога по states означает риск ёмкости или аномалию профиля, а не вывод «WAN неисправен».

Как различаем перегрузку, packet loss и маршрутизацию

Перегрузку канала мы ищем по совпадению во времени: трафик приближается к рабочей ёмкости, растут задержка и потери, после снижения нагрузки показатели восстанавливаются. Одной утилизации недостаточно: скорость порта может не совпадать с тарифом или ограничителем. Packet loss рассматриваем как устойчивую серию до корректной цели, подтверждённую другим направлением или прикладной проверкой. Если потери видит pfSense, но внешняя точка до WAN-адреса стабильна, я исследую исходящий путь, Monitor IP и участок после шлюза. При поднятом интерфейсе и доступном ближнем адресе, но отказе отдельных сетей сверяем route table, policy routing, gateway logs и трассу с правильным source. Errors и drops направляют проверку к L1/L2, драйверу или оборудованию, но требуют динамики. Совпавший отказ с нескольких точек уменьшает вероятность дефекта коллектора, не заменяя данные pfSense и оператора.

Решение по событиям и защита от ложных тревог

Мы настраиваем корреляцию состояний. Item должен получить несколько последовательных наблюдений в согласованном окне; пороги и длительности утверждаются для конкретного канала, а не копируются между площадками. Недоступность WAN требует устойчивого ухудшения gateway-сигнала и независимого подтверждения через тот же путь. Потеря только SNMP создаёт событие сбора без утверждения об интернете. Рост state table при нормальных потерях, drops и контрольных соединениях предупреждает о профиле или ёмкости, а не об аварии канала. Maintenance подавляет ожидаемые работы, зависимости предотвращают каскад, recovery ждёт подтверждения, чтобы статус не мигал. Для multi-WAN сохраняем причинность каждого gateway и сообщаем, работает ли сервис через резерв. Уведомление перечисляет устойчивый сигнал, подтверждение, недоступную проверку и экран pfSense, не назначая виновным провайдера до локализации.

Внедрение и контролируемая проверка

Внедрение начинаем с инвентаризации WAN, gateway, Monitor IP, разрешённого пути SNMP и владельца реакции. Затем включаем только нужные SNMP-модули, ограничиваем доступ, снимаем базовую динамику и создаём items без событий. Я проверяю единицы, направление счётчиков, поведение после перезапуска и соответствие графиков интерфейсу в pfSense. После накопления рабочего профиля согласуем пороги, длительности, зависимости и сообщения. Controlled check проводится без отключения боевого канала: на согласованном тестовом объекте временно блокируем только проверочный трафик к одной контрольной цели либо используем заранее выделенную безопасную цель. Изменение не должно затрагивать пользовательские states или gateway action. Мы убеждаемся, что Zabbix видит потерю конкретного сигнала, ждёт подтверждение, не объявляет весь WAN недоступным без второй проверки и корректно закрывает событие после устойчивого возврата. Отдельно проверяем отказ SNMP-доступа правилом на тестовом пути: ожидается тревога сбора, а не WAN. Перед и после я сверяю Status → Gateways, gateway logs, Diagnostics → States и независимые проверки с нескольких точек.

Проверка результата, ограничения и контакты

Результат принимаем не по зелёному цвету, а по доказательной записи. В ней есть временная линия исходного сигнала, момент подтверждения, статус связанной проверки, показания pfSense UI и результат независимых обращений. Для ложноположительной проверки фиксируем, что одиночный пропуск или недоступность одного Monitor IP не открывают событие WAN. Для чувствительности подтверждаем, что устойчивое согласованное нарушение открывает нужное событие и не порождает дубликаты по всем сервисам. Мы не обещаем определение причины только по SNMP, не считаем ответ ICMP доказательством работы приложений и не трактуем Online у gateway как гарантию всей внешней маршрутизации. Шифрование, права, резервирование Zabbix и действия pfSense при смене gateway проектируются отдельно. Если исходный профиль меняется после нового тарифа, правил NAT или состава пользователей, пороги пересматриваются. Обсудить внедрение можно на https://itfresh.ru/ или в Telegram: https://t.me/ITfresh_Boss ; телефон: tel:+79037296241. Footer: IT Fresh — практический мониторинг с проверяемой границей наблюдения; названия pfSense, Netgate и Zabbix принадлежат их правообладателям.

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

• Объявлять WAN недоступным после одного pingОдин ответ подтверждает лишь конкретный обмен ICMP с конкретной целью в конкретный момент, а отсутствие ответа может быть связано с фильтрацией или самой целью.
• Считать высокий размер state table готовым диагнозомЧисло состояний зависит от профиля трафика, таймаутов и правил; без доли заполнения, динамики, drops и влияния на соединения оно не доказывает отказ.
• Смешивать недоступность SNMP с отказом WANОпрос может не пройти из-за ACL, community, привязки SNMP к интерфейсу или пути от poller, пока пользовательский транзит остаётся рабочим.
• Использовать один общий порог потерь для всех каналовДопустимые значения и продолжительность подтверждения зависят от типа линии, Monitor IP, рабочих приложений и договорённости об обслуживании.
• Автоматически очищать states при тревогеОчистка разрывает активные соединения, меняет наблюдаемую картину и не устраняет перегрузку, дефект линии или ошибочный маршрут.

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

Read-only SNMP с ограниченного адреса Zabbix server или proxy; чтение Status → Gateways, gateway logs и Diagnostics → States в pfSense. Изменение gateway actions, маршрутов, ruleset, states и пользовательского трафика в обычный сбор не входит.

• Инвентаризировать WAN, gateway и смысл каждого Monitor IP без записи публичных адресов и конфиденциальной топологии в материал.
• Проверить с коллектора доступные MIB II и PF ветви, включённые модули и привязку SNMP; секрет не сохранять в выводе.
• Создать отдельные items доступности SNMP, интерфейсных счётчиков, PF states и подтверждённых gateway-показателей.
• Собрать рабочий профиль, затем согласовать пороги, длительность подтверждения, зависимости и recovery для каждого канала.

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

На согласованном тестовом объекте изолируется только трафик одной контрольной проверки либо используется выделенная безопасная цель. Пользовательский WAN и активные states не затрагиваются. В pfSense UI и Zabbix сверяются loss, gateway status, доступность SNMP и независимые проверки; тест немедленно прекращается при влиянии на рабочий трафик.

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

• Проверить свежесть SNMP items и отделить потерю сбора от изменения WAN.
• Сопоставить Status → Gateways и gateway logs с временной линией latency и loss в Zabbix.
• Посмотреть размер и состав state table через Diagnostics → States без очистки записей.
• Сверить интерфейсные errors, drops и трафик, route table и независимые проверки через нужный канал.
• Зафиксировать, подтверждается ли нарушение с нескольких точек и ограничено ли оно отдельным маршрутом или услугой.

Откат

До controlled check сохраняются исходные правила тестового доступа, выбранная цель и настройки items и triggers. Временная изоляция удаляется обратным точечным изменением, затем подтверждаются доступность контрольной цели, штатный gateway status, поступление SNMP и отсутствие влияния на пользовательские соединения. States не очищаются.

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

SNMP и PF-статистика показывают состояние firewall, но не доказывают исправность каждого внешнего маршрута или приложения. Gateway monitoring описывает путь до выбранного Monitor IP. Универсальных порогов заполнения state table, packet loss, latency и длительности события нет: их согласуют с каналом, рабочим профилем и правилами реакции. Набор доступных OID проверяется на установленной версии и включённых модулях.