8 октября 2 026 года запомнился Рунету масштабными проблемами, произошедшим из‑за нескольких, как кажется, не связанных друг с другом событий: утром на дата‑центр «Яндекса» в рязанском Сасово обрушились беспилотники, а ближе к вечеру в новости попал провайдер облака непрерывной доступности Curator, у которого впервые за десятилетие произошел сбой, приведший к полной недоступности всей сети фильтрации и, соответственно, защищаемых ресурсов клиентов. Сегодня Curator опубликовал у себя в блоге подробный разбор этого 38-минутного инцидента, кому интересно, можете почитать в первоисточнике: https://curator.pro/library/blog/sboi‑curator-8-oktiabria-2026-goda/

Меня же в их посте привлек разбор архитектуры сети фильтрации. Ребята подробно (насколько это позволяет формат блога) рассказали как трафик проходит через узлы защиты, зачем нужны два контекста маршрутизации, какую роль играют BGP и watchdog. А еще о том, как централизованное управление конфигурацией влияет на работу распределенной инфраструктуры.

Устройство сети фильтрации

Итак, у Curator на данные момент 9 собственных площадок фильтрации трафика в РФ, каждая из которых состоит из нескольких узлов фильтрации, которые через высокопроизводительный коммутатор подключены к вышестоящим операторам. Каждый узел подключен к коммутатору и взаимодействует с ним через два логически разделенных контекста маршрутизации — VRF external и VRF internal. В каждом из них устанавливается отдельная BGP‑сессия для обмена маршрутной информацией.

Неочищенный трафик через VRF external направляется с коммутатора на узел фильтрации, где проходит обработку. После фильтрации очищенный трафик через VRF internal возвращается на коммутатор, откуда направляется дальше к получателю. Такое разделение позволяет изолировать маршрутизацию входящего и прошедшего фильтрацию трафика, обеспечивая его последовательное прохождение через систему защиты.

Коммутатор, в свою очередь, поддерживает BGP‑сессии с вышестоящим оператором и клиентами, подключенными по BGP. Также каждый узел и коммутатор подключены к OOB‑маршрутизатору, через который осуществляется независимый доступ к сети управления.

На каждом узле работает межсетевой экран внутренней разработки Curator, обеспечивающий обработку сетевого трафика непосредственно на уровне ядра Linux и использующий собственный синтаксис правил. Этот firewall оптимизирован для обработки экстремально больших объемов сетевого трафика, что необходимо для эффективной работы сети фильтрации.
Еще на каждом узле работает watchdog — система проверки активности, которая для оценки состояния узла в том числе отслеживает обмен маршрутной информацией через BGP‑сессии между узлом и коммутатором.

Почему важен BGP

BGP (Border Gateway Protocol) — протокол динамической маршрутизации, с помощью которого автономные системы обмениваются информацией о доступных сетях. Он также используется внутри описанной схемы для обмена маршрутной информацией между узлами фильтрации и коммутаторами.Сам по себе BGP не фильтрует вредоносные запросы. Его задача — сообщать сетевым устройствам, какие маршруты доступны и куда направлять трафик.Для сети фильтрации это важно: недостаточно принять пакет и обработать его на узле. Сеть должна корректно направить входящий поток на фильтрацию, а затем обеспечить передачу очищенного трафика дальше. Поэтому состояние BGP‑сессий используется не только для маршрутизации, но и как один из признаков работоспособности узла.
Здесь выделяется два уровня:

• Доступность узла как вычислительной системы.
  Сервер может оставаться включенным и отвечать на запросы управления.

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

Как устроен межсетевой экран на узлах

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

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

Вот пример синтаксиса межсетевого экрана:

service_create 48268 185.65.148.144 443 6: remote

Зачем нужен watchdog

Watchdog (система проверки активности и работоспособности) работает на каждом узле. Один из параметров, который она отслеживает, — состояние обмена маршрутной информацией по BGP‑сессиям между узлом фильтрации и коммутатором. Если одна из контролируемых сессий разрывается, watchdog воспринимает это как признак неисправности и выводит узел из ротации.

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

Как работает CControl

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

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

Надежность, начинающаяся с архитектуры

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

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