Сбой Curator 8 октября 2026 года

8 октября 2026 года в инфраструктуре Curator произошел сбой, который привел к полной недоступности всей сети фильтрации и защищаемых ресурсов клиентов. Инцидент продолжался 38 минут — с 15:32 до 16:10 UTC+3.

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

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

Архитектура сети фильтрации Curator

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

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

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

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

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

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

Также на каждом узле работает watchdog — система проверки активности, которая для оценки состояния узла в том числе отслеживает обмен маршрутной информацией через BGP-сессии между узлом и коммутатором.

Наконец, для централизованного управления конфигурацией в сети Curator используется система распространения конфигурации СControl. Она позволяет быстро и согласованно применять изменения на всех узлах распределенной сети фильтрации. Через эту систему распространяются как пользовательские настройки, например параметры защиты отдельных ресурсов, так и инфраструктурные настройки Curator.

Механика инцидента

8 октября в 15:22 UTC+3 во время очередного релиза СControl — системы централизованного управления и распространения конфигураций — в конфигурацию межсетевого экранирования попало некорректное запрещающее правило.

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

В 15:30 это правило начало распространяться на узлы фильтрации через систему распространения конфигураций. В результате ошибочное правило затронуло интерфейс узлов фильтрации, через который трафик от узла фильтрации поступает к коммутатору (VRF internal), и заблокировало BGP (TCP/179), что привело к разрыву BGP-сессий между узлами фильтрации и коммутаторами.

При этом BGP-сессии между коммутаторами и вышестоящими операторами, а также клиентами, подключенными по BGP, оставались установленными.

Разрыв одной из BGP-сессий на узле фильтрации был воспринят системой проверки активности как признак сбоя, из-за чего узел автоматически выводился из ротации. Поскольку конфигурация была применена одновременно на всех узлах, этот сценарий повторился на всех фильтрующих узлах.

В результате в 15:32 UTC+3 из ротации были выведены все узлы фильтрации, что привело к полному прекращению обслуживания трафика на всех фильтрующих площадках и недоступности префиксов, анонсируемых через автономную систему Curator.

Восстановление работы

После определения причины сбоя мы приступили к откату изменений. Обычно восстановление предыдущей конфигурации занимает не более 3–5 минут. Однако в данном случае особенности состояния системы распространения конфигурации после релиза потребовали дополнительных действий для восстановления согласованности компонентов.

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

Хронология инцидента

15:22 — выполнение очередного релиза CControl.

15:30 — синхронизация конфигурации на узлах фильтрации.

15:31 — прекращение обработки маршрутной информации, полученной через BGP-сессии с клиентами, подключенными по BGP.

15:32 — прекращение передачи маршрутной информации в сторону вышестоящих операторов.

15:40 — откат изменений, внесенных релизом.

16:02 — восстановление анонсов в сторону вышестоящих операторов связи и доступности ресурсов клиентов, подключенных через публичный интернет.

16:10 — восстановление доступности ресурсов клиентов, подключенных через BGP.

16:10 — полное восстановление работы сети фильтрации Curator.

Действия Curator по предотвращению повторения инцидента

Мы приносим извинения всем клиентам, которых затронул сбой 8 октября. Мы понимаем, насколько критична доступность защищаемых нами ресурсов, и работаем над тем, чтобы предотвратить повторение подобных инцидентов.

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

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

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

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

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