ТСПУ (АСБИ): архитектура, эксплуатация и техническая логика системы фильтрации интернет-трафика в России

Эта статья — конспект и переработка публичного репозитория DanielLavrushin/tspu-docs, который, в свою очередь, был сгенерирован ИИ на основе транскрипта примерно пятичасовой учебной видеолекции и затем вручную проверен автором репозитория. Первоисточник — лекция об архитектуре, настройке и эксплуатации ТСПУ. Материал прошёл уже две стадии интерпретации (расшифровка лекции моделью → ручная проверка автором репозитория → переработка данным ассистентом), поэтому к деталям — особенно к числовым параметрам, названиям команд и точным техническим формулировкам — стоит относиться как к правдоподобной, но не гарантированно точной реконструкции лекции, а не как к официальной документации производителя. Там, где в исходнике встречались явные оговорки о неопределённости, они сохранены и ниже.

Содержание

1. Введение и общая архитектура АСБИ

АСБИ (автоматизированная система обеспечения безопасности интернета) — государственная система, создаваемая в рамках закона о суверенном интернете (ФЗ №90). Формально в реализации участвуют: ГУП ГРЧЦ (Главный радиочастотный центр) как заказчик, представляющий государство; АО «ДЦА» как генеральный подрядчик; и компания RDP.ru как поставщик оборудования — она делает два типа устройств, балансировщики и фильтры, а также участвует в разработке системы управления.

Проект развивался в две волны:

Пилотный проект — Уральский регион, ограниченное число площадок, байпасы GL Sun, ранняя версия центральной системы управления.
Федеральный проект — развёртывание по всей стране (порядка 350 площадок, около 5000 устройств суммарно), байпасы Silicom, обновлённые фильтры (модели 2020 года), новая ЦСУ и добавление эшелонированной («двухступенчатой») системы фильтрации.

ТСПУ (технические средства противодействия угрозам) — это физический комплекс оборудования, который врезается в разрыв канала связи оператора. Базовый принцип — прозрачность: с точки зрения топологии оператора ТСПУ выглядит как «прозрачный провод». Пакет, вошедший через определённый канал, обязан выйти через тот же канал; оператору не нужно ничего менять в своей маршрутизации.

Различают два типа ТСПУ:

Тип А (первый эшелон) — основной, устанавливается у большинства операторов; когда говорят просто «ТСПУ», обычно имеют в виду именно его.
Тип Б (второй эшелон, «эшелонированная система») — устанавливается на уровне ядра сети у крупных операторов, чтобы добирать трафик, который не прошёл через тип А (см. раздел 7).

ТСПУ состоит из четырёх функциональных блоков:

Байпасы — устройства физической защиты каналов (10–100 Гбит/с, у части оборудования 1 Гбит/с). В аварии байпас напрямую замыкает канал оператора, минуя остальную начинку ТСПУ.
Балансировщики — программируемые коммутаторы 1U/32 порта (до 3,2 Тбит/с), распределяющие трафик от байпасов по фильтрам.
Фильтры — устройства, выполняющие собственно DPI-анализ, распознавание протоколов, сверку со списками блокировки Роскомнадзора и решение «пропустить/заблокировать».
Сегмент управления — коммутаторы, VPN-шлюз и вспомогательные серверы (SPFS — сервер предварительного формирования списков; СПХД — сервер предварительного хранения данных/системных логов), связывающие площадку с центральной системой управления.

В минимальной конфигурации (один-два канала) можно обойтись одним байпасом и одним фильтром без балансировщика — тогда фильтр напрямую подключён к байпасу, но допустимы только каналы 1G/10G, поскольку сами фильтры не поддерживают интерфейсы 100G. В типовой схеме присутствуют все компоненты: несколько байпасов по числу каналов оператора, один или несколько балансировщиков и множество фильтров.

2. Прохождение трафика через ТСПУ

На стыке, где стоит ТСПУ, пакет может нести разную дополнительную инкапсуляцию поверх IP — она зависит от технологий конкретного оператора и от точки установки в его сети: обычный нетегированный IP, один VLAN-тег (802.1Q), двойной VLAN-тег (QinQ, 802.1ad), MPLS-метки (одна или несколько), их комбинации, а также PPPoE (характерен для участка до BRAS), в том числе поверх MPLS. Список не исчерпывающий — вариантов на реальных сетях операторов много. Принципиально важно: ТСПУ обязано «прогрызться» через любую комбинацию заголовков до IP-пакета, но само оно ничего в этих заголовках не меняет — всё, что находится «сверху» IP, проходит прозрачно.

Сквозной принцип для всего оборудования тракта — деление портов на LAN (в сторону абонентов) и WAN (в сторону интернета). На фильтрах это реализовано жёстко через чётность номера порта (чётные — LAN, нечётные — WAN), на балансировщиках — по той же логике, принятой при проектировании конкретной схемы.

Полный путь пакета в типовой схеме:

Байпас. Канал оператора физически разорван и заведён на байпас; в штатном (Inline) режиме трафик прозрачно идёт дальше к балансировщику.
Балансировщик, стадия фильтрации служебного трафика. Порты объединены в линки (пары LAN+WAN); трафик, вошедший в определённый LAN-порт, обязан выйти через парный ему WAN-порт. Прежде чем распределять пакет по фильтрам, балансировщик прогоняет его через правила (flow rules): служебный трафик — BGP (TCP/179), мультикаст, протоколы маршрутизации — обычно сразу заворачивается назад (bypass), чтобы не грузить фильтры и не рисковать вмешательством в служебные протоколы оператора.
Балансировщик, стадия распределения по фильтрам. Трафик, не попавший под bypass-правила, уходит в группу балансировки. Распределение построено на хеш-сумме от source IP, destination IP и IP-протокола, к которой добавляется количество ядер фильтров, чтобы разложить нагрузку не только по устройствам, но и по ядрам внутри устройства. К пакету добавляется служебный 4-байтный заголовок (похож на VLAN-тег, но им не является), который говорит фильтру, на какое ядро отправить пакет, и позволяет балансировщику опознать при возврате, в какой именно линк оператора вернуть обработанный пакет. Хеш симметричен: для обратного пакета (интернет → абонент) source/destination меняются местами, но итоговая сумма совпадает — значит, оба направления одной сессии всегда оказываются на одном и том же фильтре и даже на одном и том же его ядре.
Обработка на фильтре. Пакет последовательно проходит проверки: является ли он вообще IP-пакетом; попадает ли в ACL, привязанный к какому-либо пулу; попадает ли под условия (по IP-подсетям) активного DPI-листа; и только затем анализируется движком DPI, который решает — пропустить или заблокировать (drop). Не прошедший любую из первых трёх проверок пакет просто прозрачно возвращается назад, как будто фильтра нет. Сам фильтр работает как L2-устройство — не трогает инкапсуляцию, только «заглядывает» внутрь до IP-заголовка.

Отдельный технический нюанс — как фильтр показывает абоненту HTTP-редирект (302 на страницу-заглушку) или обрывает HTTPS-соединение через TCP Reset, если канал между балансировщиком и фильтром де-факто однонаправленный, а в трафике присутствуют MPLS-метки, которые фильтр сам сгенерировать не умеет. Решение: пропустить исходный пакет абонента к ресурсу как есть, дождаться ответного пакета от сервера (в нём уже будут «родные» правильные заголовки инкапсуляции) и подменить его содержимое на редирект/reset, сохранив исходную инкапсуляцию.

3. Байпас

Байпас физически защищает каналы связи оператора: в случае любой аварии оборудования ТСПУ (падение фильтров, балансировщика, обесточивание) он замыкает канал напрямую, минуя остальную начинку, чтобы не разорвать связность сети оператора.

В проекте используются байпасы двух производителей:

Silicom (федеральный проект). У каждого канала есть четыре порта: Net0/Net1 — к оператору, Mon0/Mon1 — к балансировщику (или напрямую к фильтру в простейшей схеме). Поддерживаются четыре режима:

Inline — штатный рабочий режим, трафик реально проходит через ТСПУ.
TAP — каналы оператора замыкаются друг на друга напрямую, а на балансировщик/фильтр уходит только копия трафика без возможности как-либо повлиять на него; удобный режим для отладки системы без риска для связности сети оператора.
Active Bypass — то же замыкание канала оператора напрямую, но без отправки копии на ТСПУ вообще; используется, когда нужно полностью вывести ТСПУ из тракта (например, на время технических работ).
Power-off Bypass — аварийный режим при потере электропитания; вероятно реализован через оптический переключатель. Это последняя линия защиты, но переключение в него/из него сопровождается флапами линков и заметным для оператора перерывом трафика — в отличие от переключений между Inline/TAP/Active Bypass, которые проходят «безболезненно» (возможна лишь единичная потеря пакетов, уже ушедших в сторону балансировщика).

GL Sun (пилотный проект, Урал). Функционально беднее: доступен фактически только аналог Power-off Bypass, промежуточных TAP/Active Bypass нет, и любое переключение сопровождается флапом линков оператора. Кроме того, GL Sun не генерирует heartbeat-пакеты самостоятельно — их вместо байпаса отправляет балансировщик (или фильтр, если балансировщика нет).

Байпасы Silicom постоянно проверяют доступность канала до балансировщика специальными heartbeat-пакетами (по данным документации — не-IP-кадры, изначально в формате IPX, впоследствии по договорённости с RDP.ru изменённые на формат, прозрачно проходящий через балансировщик и фильтр). Если heartbeat перестаёт доходить, байпас автоматически переключает соответствующий канал в TAP или Active Bypass — в зависимости от настройки. Важно, что heartbeat байпаса не доходит до самих фильтров — он заворачивается уже на балансировщике; проверка работоспособности собственно фильтров — отдельный, независимый механизм на уровне балансировщика (см. раздел 4).

4. Балансировщик (EcoFilter Balancer)

Балансировщик — программируемый коммутатор-«диспетчер»: принимает трафик от байпасов и распределяет по фильтрам, а также сам умеет фильтровать служебный трафик, программно байпасить неисправные группы портов и следить за живостью фильтров.

Платформа: 1U, 32 порта QSFP28, заявленная пропускная способность 3,2 Тбит/с (на пакетах крупнее ~160 байт), порты работают на 10/25/100G; для 10G используются «гидры» — breakout-кабели, разводящие один QSFP28 на четыре SFP+. Поставляется «с нуля», без готовой конфигурации — всё (порты, линки, правила) собирается вручную под конкретную площадку.

Порты делятся на LAN/WAN по чётности (аналогично фильтрам) и объединяются в линки; трафик, вошедший в конкретный порт оператора, жёстко возвращается через парный порт того же линка — это и обеспечивает прозрачность ТСПУ.

Flow rules (правила фильтрации на балансировщике) состоят из условия (match: VLAN ID, IPv4 src/dst, L4-порт, MAC, MPLS-метки, глубина VLAN-тегов) и действия (action): bypass — прозрачно вернуть трафик оператору, минуя фильтры (используется для BGP, мультикаста, прочего служебного трафика); balancing s_mac — отправить трафик в группу балансировки для распределения по фильтрам. Правила применяются по приоритету, обычная практика — явно описать нужный трафик высокоприоритетными правилами, а «заглушкой» с наименьшим приоритетом байпасить всё остальное.

Механика балансировки описана в разделе 2: хеш по source/destination IP и протоколу с учётом числа ядер фильтров (параметр N_UNIT_QA — количество ядер минус одно «служебное», отданное под Linux и управление), симметричность хеша, дополнительный 4-байтный заголовок для маршрутизации пакета к нужному ядру и обратно в нужный линк. У балансировщика нет собственных логов о том, куда конкретно ушёл пакет — вся коммутация происходит на аппаратном уровне чипа, поэтому найти сессию конкретного абонента можно только перебором фильтров площадки (вручную при малом их числе, скриптом — при большем).

Отказоустойчивость. Балансировщик шлёт keep-alive пакеты через каждую пару портов (filter group) в сторону фильтров и меряет время прохождения (в штатном режиме — порядка десятков микросекунд). Параметры проверки (начальная задержка, интервал ~100 мс, порог потерь ~5 пакетов и т.д.) задаются в профиле доступности. При потере доступности конкретной filter group балансировщик переводит именно её (а не всю площадку) в программный байпас — трафик этой пары портов начинает заворачиваться прямо на балансировщике, минуя фильтр, без флапов у оператора. Это существенное улучшение относительно пилотного проекта, где выпадение даже одного интерфейса роняло в байпас всю площадку. Альтернативный механизм — перебалансировка трафика на оставшиеся живые filter group — в федеральном проекте, как правило, отключён, поскольку пересчёт хеша рвёт уже установленные сессии; предпочтителен точечный программный байпас, при котором часть трафика временно не фильтруется, но зато не рвутся все соединения и не встаёт вся площадка.

5. Фильтр (EcoFilter): логика обработки пакета

Фильтр — основное «рабочее» устройство ТСПУ. Каждый пакет от балансировщика проходит последовательную цепочку проверок, и на любом её этапе может «сорваться» и быть прозрачно возвращён оператору:

IP-пакет или нет. Глубина разбора инкапсуляции определяется параметром VLAN Mode (untag / vlan / QinQ); в проекте АСБИ он всегда должен стоять в QinQ, иначе часть трафика будет молча проходить без всякой обработки. Именно на этом шаге отсеиваются не-IP-кадры — включая, например, keep-alive от балансировщика.
ACL, привязанный к пулу. Пулы в проекте — типа fake (без реальной трансляции адресов: что пришло — то и ушло), но пул с ACL всё равно обязателен: без него трафик вообще не попадёт на DPI, каким бы ни было содержимое DPI-листов. На заводской конфигурации пулов и ACL нет — их создают вручную.
DPI-лист (по IP-подсетям). До 16 списков (0–15), каждый со своими параметрами IP / No IP / No IP Remote (и аналогами для IPv6), которые определяют, какой трафик вообще подлежит этому конкретному списку. Список 0 в проекте зарезервирован под фильтрацию по реестру Роскомнадзора.
Движок DPI (ecDPI). Многофакторный анализ сессии целиком (не отдельного пакета): размеры пакетов и их вариации, частота прохождения, ключевые слова и паттерны, а для шифрованного трафика — косвенные статистические признаки, поскольку прямых полей протокола не видно.
Решение. Параметр behavior DPI-листа определяет, что делать с совпавшим трафиком: block — реально заблокировать; ignore — только зафиксировать факт совпадения и отправить лог (это первая стадия двухступенчатой блокировки, см. раздел 8); color/redirect в проекте не задействованы. Отдельный переключатель WH list mode меняет логику списка с blacklist (по умолчанию) на whitelist, но whitelist в АСБИ не используется — слишком высок риск случайно заблокировать «всё».

При блокировке HTTP абоненту показывается редирект (код 302) на страницу-заглушку по адресу, заданному параметром DPI-листа; при блокировке HTTPS содержимое зашифровано и подменить страницу нельзя, поэтому просто рвут TCP Reset. Отдельно есть флаг send RST off, отключающий отправку Reset при блокировке именно протоколов (не URL) — иначе приложение абонента (например, мессенджер), получив Reset, начинает лихорадочно и очень часто переустанавливать соединение, порождая лавину новых сессий и лишнюю нагрузку.

Хотя фильтр анализирует трафик вплоть до прикладного уровня, топологически он остаётся L2-устройством: у него нет полноценных IP-интерфейсов в тракте данных (только management-интерфейс для удалённого доступа), он не умеет самостоятельно генерировать трафик (ping/traceroute доступны только через management), не трогает инкапсуляцию, у него по требованию операторов выключен LLDP (чтобы устройство не «светилось» в топологии сети оператора), а L2 MTU выставлен в максимум по RFC (9216 байт), чтобы раз и навсегда закрыть проблемы с фрагментацией. Отдельный важный параметр — permit invalid flow, который в проекте всегда должен быть включён: он разрешает заводить TCP-сессию без предшествующего SYN-пакета, что критично в момент переключения байпаса из TAP в рабочий Inline-режим — иначе фильтр массово дропнет все уже установленные к этому моменту соединения абонентов.

6. Места установки ТСПУ в сети оператора

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

До BRAS/BPE/BNG (в мобильных сетях — до GGSN/PGW), то есть до устройства, терминирующего абонентские сессии. Особенность — присутствие PPPoE-инкапсуляции на широкополосном доступе; это не критично (фильтры её умеют разбирать), но требует правильной настройки VLAN Mode (см. раздел 5).

Между BRAS и CGNAT. Судя по документации, это, вероятно, самая удобная точка: PPPoE уже терминирован, а адреса абонентов ещё «серые» (не транслированы NAT-ом), то есть видны напрямую — можно найти конкретного абонента по IP на фильтрах, исключить его из обработки конкретным DPI-листом для диагностики и т.д.

После CGNAT. Здесь видны только «белые» адреса из общего NAT-пула оператора; сама фильтрация от этого не страдает, но траблшутинг усложняется — чтобы связать конкретного абонента с конкретной сессией на ТСПУ, приходится запрашивать у оператора данные о трансляции с CGNAT. (Если BRAS и CGNAT физически совмещены в одном устройстве, «средняя» точка между ними просто отсутствует.)

On-a-stick — когда BRAS и/или CGNAT подключены к сети агрегированным каналом «петлёй», трафик через ТСПУ на этом участке проходит дважды: сначала до сервисного устройства, потом обратно после него. Наилучший вариант — когда оператор чётко разводит эти два прохождения по разным VLAN, и тогда на балансировщике можно направить на фильтры только один VLAN (например, «до» CGNAT, где видны серые адреса), а второй прозрачно забайпасить flow-правилом. Если развести направления по VLAN невозможно, трафик обрабатывается дважды: сессии дублируются (причём с разными адресами до/после трансляции), нагрузка на ТСПУ фактически удваивается, а траблшутинг усложняется — по документации, это нежелательная ситуация, которой стараются избегать уже на этапе проектирования подключения площадки.

7. Эшелонированная система (ТСПУ типа Б)

Идея второго эшелона — обработать трафик, который по тем или иным причинам не «собрался» на обычном ТСПУ типа А. У крупных операторов на уровне ядра сети и пиринга (в отличие от абонентов и мелких single-home операторов на уровне доступа) трафик может быть асимметричным: уходить через одного провайдера, а возвращаться через другого. В таком случае на «плоском» фильтре тип А сессия просто не сойдётся — одна её половина ТСПУ вообще не видит. Заодно эшелонирование позволяет не ставить полноценные ТСПУ у каждого мелкого оператора, снижая общее число площадок.

Балансировщик второго эшелона называется Eco Highway — та же аппаратная платформа (1U-коммутатор на чипе Barefoot Tofino), но другое ПО. Принципиальное отличие от EcoFilter Balancer: Eco Highway сам фильтрует трафик по IP-адресам и портам (L3/L4), а не просто раскидывает его по фильтрам. Списки для этого — десятки и сотни тысяч записей — загружаются автоматически по BGP прямо из ЦСУ (задать их вручную, как flow rules на обычном балансировщике, физически нельзя): отдельные таблицы для IPv4 «адрес+порт», IPv4 «только адрес», аналогичные для IPv6, белый список исключений и таблица port redirect (что отправлять на фильтры).

Это значит, что блокировка «по протоколу» (например, Telegram) на втором эшелоне не требует DPI на фильтре — она делается прямо на балансировщике по уже готовым спискам IP:порт, полученным из ЦСУ тем же путём двухстадийной очистки, что и для типа А (раздел 8). Соответственно, в прошивке фильтров второго эшелона функционал блокировки протоколов попросту отсутствует за ненадобностью — на их долю остаётся только URL-фильтрация по реестру Роскомнадзора, то есть та часть работы, которая объективно требует заглянуть внутрь пакета.

Подключение фильтров к Eco Highway организовано иначе, чем к обычному балансировщику: не парами физических LAN/WAN портов, а в режиме on-a-stick с разделением направления через служебный VLAN-тег, который балансировщик выставляет при отправке пакета на фильтр и переопределяет при получении обратно.

Внутри чипа Tofino есть два независимых логических конвейера (Pipeline) обработки со своей памятью и вычислительными ресурсами каждый. На обычном балансировщике оба конвейера настроены одинаково; на Eco Highway — по-разному, что позволяет фактически удвоить суммарную ёмкость таблиц фильтрации (важно, поскольку встроенная память чипа очень быстрая, но очень ограниченная — по сути TCAM). LAN-порты жёстко привязаны к одному конвейеру, WAN — к другому, а поскольку прямой связи между конвейерами внутри чипа нет, между ними прокладывается физическая кабельная перемычка, рассчитанная на пропуск всего объёма трафика балансировщика. Пакет проходит через первый конвейер (может быть дропнут, отправлен на фильтр, либо — если не совпал ни с одним правилом — перейти через перемычку на второй конвейер), затем аналогично через второй; при отправке на фильтр повторного прохождения второго конвейера не происходит.

Поскольку через эшелон проходит существенно больше трафика, чем через отдельный ТСПУ типа А, логирование на Eco Highway не ведётся — доступен только просмотр состояния в реальном времени, без сохранения истории; протокольные логи для формирования списков по-прежнему приходят только с фильтров первого эшелона. Диагностика на эшелоне сводится к проверке списков в ЦСУ, временному программному байпасу всего Eco Highway и проверке на фильтрах второго эшелона. Отдельная задача Eco Highway — уметь распознавать трафик, уже обработанный на первом эшелоне, и не пропускать его через фильтрацию повторно, чтобы избежать дублирования, аналогичного проблеме on-a-stick (раздел 6).

8. Формирование протокольных списков: двухстадийная блокировка

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

Этап 1 — распознавание. На фильтрах типа А DPI-лист с распознаванием работает в режиме behavior: ignore — то есть срабатывания фиксируются как протокольные логи, но сам трафик не блокируется и продолжает идти как обычно.

Этап 2 — накопление и передача. Логи с фильтров уходят на локальный SPFS (сервер предварительного формирования списков) той же площадки; настраивается это в секции debug logger — какие протоколы логировать (по умолчанию all, но обычно указывают конкретные) и сколько пакетов сессии сохранять в логе (по умолчанию 0/«без ограничения», фактически ведущее к 30 пакетам; на практике для анализа хватает порядка 3-х — большее число создаёт избыточный поток логов). SPFS передаёт накопленное в ЦСУ по gRPC через VPN-туннель («Континент»).

Этап 3 — анализ в ЦСУ. Центральная система, видя данные сразу со всех площадок страны, а не с одного фильтра, может делать более глубокий анализ: сопоставлять сессии с разных устройств, применять статистику, выявлять конкретные IP:порт, устойчиво ассоциированные с конкретным протоколом (например, серверы или прокси Telegram), и формировать из них уже «очищенные» списки с низкой вероятностью ложных срабатываний.

Этап 4 — обратная загрузка списков. Очищенные списки уходят обратно двумя путями: на фильтры типа А — по HTTP, в отдельный DPI-лист (не тот, что распознаёт, а другой, например «список 5»), где behavior: block уже реально блокирует; на Eco Highway — по BGP, в собственном формате, для блокировки прямо на балансировщике.

По имеющимся данным (полученным в тестовой зоне), полный цикл — от появления нового, ранее не встречавшегося сервера блокируемого протокола до его фактической блокировки — занимает порядка 5–15 минут, в зависимости от периодичности анализа в ЦСУ, настроек SPFS и объёма сессий по данному протоколу (чем больше абонентов используют новый сервер, тем быстрее набирается статистика для его надёжной идентификации). До момента обновления списка уже открытые сессии не обрываются принудительно — абонент какое-то время продолжает пользоваться новым, ещё не внесённым в список ресурсом.

9. Центральная система управления (ЦСУ)

ЦСУ развёрнута на двух независимых физических площадках — основной и резервной, связанных выделенным каналом для репликации. Все площадки ТСПУ подключаются к обеим площадкам ЦСУ через VPN на криптошлюзах «Континент»: локальный шлюз на площадке (модель попроще) устанавливает туннель через публичный интернет к более мощному шлюзу на стороне ЦСУ. Через этот канал идёт управление устройствами, сбор протокольных логов (gRPC от SPFS), системных логов (syslog) и данных мониторинга (SNMP), распространение списков (HTTP на фильтры, BGP на Eco Highway) и обновление прошивок.

На момент лекции ЦСУ обслуживала порядка 350 площадок и около 5000 устройств суммарно (фильтры, балансировщики, байпасы, SPFS, СПХД). Внутри ЦСУ выделяется несколько подсистем: формирование списков фильтрации, мониторинг, логирование, картография размещения оборудования, отчётность — их внутреннее устройство описано в отдельном документе «Системная архитектура ЦСУ», не входящем в данный материал. Обслуживанием самой ЦСУ занимается команда DevOps; инженеры на площадках выступают её пользователями (мониторинг, управление), а не администраторами.

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

10. Сегмент управления площадки

Адресация management-сети площадки построена по схеме 10.<регион>.<площадка>.0/24 (первый октет всегда 10, второй — номер региона из ~88 возможных, третий — номер конкретной площадки внутри региона). Внутри выделенной площадке подсети /24 адреса жёстко закреплены по типам устройств: например (согласно документации), диапазон под байпасы — самый широкий, поскольку их число зависит от количества каналов оператора и может быть большим; далее идут диапазоны под балансировщики и их BMC, под фильтры и их IPMI, под SPFS и СПХД; последний адрес подсети (.254) закреплён за криптошлюзом «Континент», который является шлюзом по умолчанию для всех устройств площадки и через который весь management-трафик уходит в VPN к обеим площадкам ЦСУ.

Отдельно существует подсеть логирования — единая по всей стране (а не уникальная для каждой площадки), поскольку она не выходит за пределы конкретной площадки: лог-интерфейсы фильтров (реализованные через DPDK) используются только для отправки журнала соединений и не имеют полноценного IP-стека (их нельзя, например, пропинговать). Системные логи (syslog), в отличие от журнала соединений, идут через обычный management-интерфейс и в итоге оседают на СПХД площадки для последующего ретроспективного анализа.

11. Фильтр: аппаратные платформы

Линейка фильтров EcoFilter делится на младшую (EcoFilter 20/40 — 2 и 4 десятигигабитных интерфейса трафика соответственно) и старшую (EcoFilter 4080/4120/4160 — 8/12/16 таких интерфейсов; число в названии модели прямо связано с количеством портов). Все модели — 1U, с горячезаменяемыми блоками питания и вентиляторами; заявленная маркетинговая цифра пропускной способности до 160 Гбит/с относится к режиму NAT-трансляции, который в проекте не используется, — реальная производительность в режиме DPI-фильтрации ниже и зависит от профиля трафика.

Модели 2019 года (пилотный, Урал) построены на Intel Xeon 2695/2699 (18/22 ядра, 128/256 ГБ ОЗУ), с несъёмными сетевыми интерфейсами и двумя медными портами логирования. Модели 2020 года (федеральный проект) — на Intel Xeon Gold 6212 (24 ядра, 192/384 ГБ ОЗУ), со съёмными интерфейсными платами и уже четырьмя SFP+ портами (10G) под логирование; аппаратная платформа может закупаться у разных поставщиков (например, у Lanner), внешне отличаясь, но сохраняя одинаковую внутреннюю логику.

На всех фильтрах интерфейсы трафика жёстко разделены по чётности: чётные — LAN (к абонентам), нечётные — WAN (к интернету) — тот же принцип, что и на EcoFilter Balancer (но не на Eco Highway, см. раздел 7).

Платформа фильтра исторически выросла из линейки CGNAT-устройств 2013 года, что объясняет часть унаследованных архитектурных особенностей (понятия сессии/трансляции, деление LAN/WAN и т.д.). Из всего заложенного в прошивку функционала (NAT, PPPoE BRAS-функции, маршрутизация, QoS) в проекте ТСПУ реально задействованы только два модуля — EcoFilter (фильтрация по спискам) и EcoDPI (распознавание приложений вплоть до 7-го уровня OSI).

12. Сессии и трансляции на фильтре

Базовая единица учёта трафика на фильтре — сессия: запись вида «направление / протокол / local IP:port / global IP:port / remote IP:port / время последнего пакета / оставшийся тайм-аут». Направление (Egress — инициировано абонентом, Ingress — инициировано снаружи) фиксируется один раз, по стороне первого пакета, создавшего сессию, и больше не меняется. Local IP всегда содержит адрес абонента независимо от того, с какой стороны пришёл конкретный пакет (для пакетов со стороны WAN source/destination при записи меняются местами) — это важный ориентир при диагностике: адрес интернет-ресурса в поле Local IP означает проблему на тракте (например, перепутанные LAN/WAN, см. раздел 24).

Трансляция — более простая сущность, связка «local IP:port ↔ global IP:port» без привязки к конкретному удалённому ресурсу. Поскольку в проекте ТСПУ NAT не используется (фильтр работает прозрачно, адреса не подменяются), local и global всегда совпадают, и команды с ключевым словом global/ga фактически не несут дополнительного смысла по сравнению с local/la — это наследие платформы, изначально спроектированной как NAT-устройство. Одной трансляции может соответствовать множество одновременных сессий к разным ресурсам; трансляция удаляется только после того, как истёк тайм-аут у последней связанной с ней сессии. Тайм-ауты сессий и трансляций задаются отдельно в общих настройках устройства (NAT Defaults) и могут переопределяться на уровне конкретного пула.

Ключевые CLI-команды: show session (таблица сессий) и show xl (таблица трансляций), с фильтрацией по local/remote (и менее полезными в контексте проекта global/ga/la/ra) и постобработкой через pipe-операторы include/exclude/count/more, которые можно комбинировать в цепочку. Собственного API для удалённого доступа к данным фильтра нет, но можно выполнить нужную команду по SSH и обработать вывод внешними средствами (grep, скрипты) — при этом встроенные pipe-операторы самого фильтра при таком удалённом вызове могут работать нестабильно.

13. Фильтр: первоначальная настройка и CLI

Подключение к фильтру возможно через консольный порт (115200 8N1) или по SSH (порт 22); логин по умолчанию — admin/econat. CLI построен на двух режимах: операционном (>, только просмотр состояния) и конфигурационном (#, изменение настроек), с древовидной навигацией по разделам конфигурации (system, pools, access-lists и т. д.) — переход в раздел по имени, выход на уровень выше через .., возврат в корень через /; поддерживаются автодополнение по Tab, история команд по стрелкам и подсказки по ?. Изменения в конфигурационном режиме применяются командой apply и лишь затем сохраняются в стартовую конфигурацию командой wr; отдельно доступны операции сохранения/загрузки/копирования и очистки конфигурации. Одновременная работа двух пользователей в конфигурационном режиме имеет ограничения; незакрытая скобка в введённой команде переводит CLI в своеобразный «капкан» (trap mode), из которого нужно выходить особым образом. Ключевое слово ls используется для быстрого обзора текущего раздела дерева конфигурации.

14. Фильтр: конфигурация системных подсистем

Раздел описывает базовую системную настройку устройства: параметры консольного порта (скорость, тайм-аут неактивности); management-интерфейс (IP, шлюз, DNS, список разрешённых для доступа адресов, с добавлением/удалением записей через операторы +=/-=); параметры терминала SSH (авто-логаут, вид приглашения, нумерация строк, лимит одновременных сессий — около 20, и предупреждение о том, что значение auto-logout never потенциально опасно); управление пользователями (создание/удаление, уровни доступа, пароли в открытом или скрытом виде — secret 0/secret 15); интеграция с TACACS+ для централизованной авторизации с откатом на локальную базу при недоступности сервера; настройка до трёх NTP-серверов; SNMP (community-строка только на чтение, traps, список разрешённых адресов).

Системное журналирование (syslog) поддерживает до двух внешних лог-серверов с настройкой hostname и сдвига времени, а также раздельные уровни логирования по подсистемам (1 — только ошибки, 2 — предупреждения, 3 — информационные сообщения), с отдельной подсистемой all, задающей максимальный уровень сразу для всего; команды пользователя логируются отдельно на уровне fatal, а через SNMP traps транслируются тоже только события уровня fatal. Отдельно от системного логирования настраиваются журнал соединений (connection log), уходящий через выделенный лог-интерфейс (DPDK), и журнал распознанных протоколов (debug logger), отправляемый на SPFS — с выбором протоколов для логирования (all или конкретный список) и числом сохраняемых пакетов на протокол (по умолчанию 30, рекомендуемое практикой значение — 3).

15. Фильтр: интерфейсы и общие параметры NAT Defaults

Физические интерфейсы включаются/выключаются и могут снабжаться описанием; агрегация LACP на фильтрах не используется. Общие параметры устройства собраны в разделе NAT Defaults:

VLAN Mode (untag/vlan/QinQ) — задаёт глубину разбора инкапсуляции при поиске IP-заголовка; в проекте АСБИ должен быть всегда QinQ (см. разделы 2 и 5).
Sessions per Translation — по умолчанию 4096, ограничивает число сессий на одну трансляцию.
Forward Traffic — должен быть всегда включён.
L2 MTU — максимум 9216 байт по RFC.
LLDP — выключен по требованию операторов, чтобы устройство не «светилось» в их сетевой топологии.
Permit Invalid Flow — должен быть всегда включён; разрешает заводить TCP-сессии без предшествующего SYN-пакета (критично при переключении из TAP в Inline).

Здесь же задаются тайм-ауты сессий/трансляций по умолчанию (см. раздел 12) и, при необходимости, включение обработки IPv6-трафика с указанием диапазона адресов.

16. Фильтр: ACL и пулы

Трафик попадает на обработку DPI только через связку «пул + ACL» (см. раздел 5). ACL создаются командой create acl, содержат правила allow/deny с условиями по протоколу, source/destination (конкретный адрес, подсеть или any) и номеру VLAN (по умолчанию — любой из диапазона 0–4095); правила нумеруются с зазором (10, 20, 30…) для удобства последующей вставки новых. Пул создаётся командой create pool с типом fake (без реальной NAT-трансляции — что пришло, то и ушло), к пулу привязывается ACL; при наличии нескольких пулов действует приоритет — трафик попадает в пул с наивысшим приоритетом, чей ACL совпал первым. В настройках пула включается connection logging и, при необходимости, обработка IPv6.

17. Фильтр: настройка DPI

Общий блок настроек DPI включает включение/выключение модуля целиком, флаг send RST off (отключает TCP Reset при блокировке протоколов — см. раздел 5) и режим работы (normal, без «двойного зеркалирования» трафика).

Отдельный блок посвящён интеграции с реестром Роскомнадзора: источник данных (сервер РКН или ГРЧЦ), логин/пароль доступа, привязка к конкретному номеру DPI-листа, настройка прокси и dump-сервера. Отмечена практическая проблема — скорость скачивания реестра с сервера РКН может проседать, и для стабильной работы системе нужна минимальная скорость канала порядка 10 Мбит/с.

Есть механизм «деградации протокола» (protocols capacity) — шкала от 0 (полная блокировка) до 100 (полный пропуск), которая вместо жёсткого дропа вероятностно отбрасывает часть пакетов заданного протокола; на практике эффективная деградация достигается уже при пропускании порядка 2–10% трафика — этого достаточно, чтобы ощутимо ухудшить качество голосовых звонков и работу мессенджеров, не блокируя протокол полностью.

Каждый из 16 (0–15) DPI-листов настраивается индивидуально: включение/выключение, отдельный флаг детектирования BitTorrent по UTP, режим WH list mode (blacklist по умолчанию/whitelist, последний не используется — см. раздел 5), поведение behavior (block/ignore/color/redirect, последние два в проекте не задействованы), URL страницы-заглушки при redirect для HTTP-блокировок, адрес и расписание скачивания источника списка (download URL, update schedule), список распознаваемых протоколов, параметры No IP/IP (исключение/включение конкретных адресов из обработки конкретным листом — удобно для диагностики отдельного абонента) и отдельно список QUIC. Формат самих списков фильтрации может включать IP-адреса, подсети, диапазоны и URL; для HTTP блокируется конкретный URL, а для HTTPS — только по домену, извлекаемому из SNI/Client Hello (поскольку остальное содержимое зашифровано).

18. Фильтр: мониторинг и диагностика

Базовые команды просмотра состояния: show version (версия ПО и серийный номер, совпадающий с MAC-адресом management-интерфейса), show ip if (параметры management), show time (текущее время в UTC/локальной зоне), show uptime (время работы платформы и отдельно — процесса EcoNAT), а также аппаратные показатели через show power/show fan/show temperature. Состояние интерфейсов смотрится через show interface brief, монитор трафика и данные трансиверов (DDM).

Команда show resources показывает загрузку ключевых ресурсов: занятость таблиц сессий/трансляций (рекомендуется держать не выше ~20%), запас свободных буферов (не должен стремиться к нулю), загрузку DPI-ресурсов (не выше 100%) и условный показатель CPU Load, характеризующий обработку трафика. Отдельно контролируется память: Control Plane и Data Plane разделены, причём память Data Plane выделяется единожды при старте и в норме не должна расти; порогом тревоги считается снижение свободной памяти до 5–10%. show cps показывает скорость создания новых сессий, show statistic — статистику по сессиям и пулам (в том числе показатель Optimal, соответствующий ~20% загрузки), а show counters all/show counters div — накопленные и «дельта за секунду» счётчики соответственно.

Системный журнал просматривается через show syslog (с ротацией по двум файлам). Для диагностики DPI доступны: show dpi records <N> (содержимое конкретного списка), show dpi state (число записей и дата последнего обновления), dpi load <N> (ручная загрузка конкретного списка) и dpi run (принудительное обновление всех списков), а также show dpi match <ресурс> — проверка, под какой именно DPI-лист попадает заданный ресурс. Ping и traceroute доступны только из конфигурационного режима и только через management-интерфейс (см. раздел 5 — у фильтра нет собственных L3-интерфейсов в тракте данных).

19. Фильтр: обновление прошивки

Прошивка фильтра хранится в двух равнозначных разделах (prim1/prim2) плюс заводской резервный раздел (FB). Команда firmware status показывает текущее и загружаемое при следующей загрузке состояние (cur/boot); firmware download скачивает новую версию, firmware install — устанавливает её; при проблемах доступны firmware rollback (откат) и firmware reset. В штатной эксплуатации обновление прошивки на площадках выполняется централизованно через ЦСУ.

20. Балансировщик: аппаратная платформа

Помимо одноюнитового 32-портового варианта (см. раздел 4), существует и двухюнитовая модель на 65 портов, но в проекте АСБИ используются только 1U-версии. Порты работают на 10/25/100G; десятигигабитные каналы получают из 100G-портов «гидрами»-брейкаутами. Внутри устройства — микросервер на архитектуре Intel/Linux, отвечающий за CLI и конфигурацию; программируемый коммутационный чип Barefoot Tofino, на котором реализована собственно логика балансировки/фильтрации; BMC для аппаратного управления самим устройством (сенсоры, блоки питания) независимо от состояния основной ОС; пятипортовый Ethernet-коммутатор для внутреннего доступа к микросерверу и BMC; и Console MUX, переключающий консольный порт между внутренними компонентами. На передней панели — консоль, management Ethernet и USB.

21. Балансировщик: конфигурация

CLI балансировщика по стилю напоминает интерфейсы линейки Juniper: операционный режим для просмотра и режим редактирования (edit) для изменения конфигурации, применение через apply, сохранение в стартовую конфигурацию через save. Обновление прошивки выполняется командами call rdp firmware download/call rdp install; прошивка хранится в двух разделах (A/B) с автоматическим откатом, если новая версия за фиксированное число попыток (3) в течение заданного окна (20 минут) не «прижилась», плюс команда сброса счётчика попыток call rdp firmware reset-tries.

Настройка физических портов включает присвоение имени, указание физического номера порта, линии (lane, для десятигигабитных каналов из 100G-порта — значения 0–3) и скорости; при работе на 100G задействуются сразу все четыре линии. Линки формируются объединением пары портов (LAN+WAN) в сторону оператора. Группа балансировки объединяет порты в сторону фильтров (filter groups); параметр N_UNIT_QA задаёт число ядер фильтра, участвующих в обработке, минус одно служебное (см. раздел 4).

Профиль проверки доступности (keep-alive) задаёт начальную задержку, интервал проверки, порог потерь для признания группы неактивной, минимальное число активных пар портов для группы в целом и включение/отключение перебалансировки трафика при частичном отказе. Собственно фильтрация трафика (flow rules) конфигурируется через условия match (VLAN, IPv4 src/dst, L4-порт, MAC, MPLS, глубина тегов) и действия (balancing s_mac → конкретная balance group, либо bypass) с учётом приоритета правил и их привязки к конкретным линкам (см. раздел 4). Для байпасов GL Sun на балансировщике отдельно настраивается heartbeat (см. раздел 3.3.1). Management-интерфейс балансировщика настраивается стандартно — IP, маска, шлюз по умолчанию.

22. Балансировщик: мониторинг и диагностика

Аппаратное состояние проверяется командой show hardware info (CPU, память, вентиляторы, блоки питания, температура), состояние management-интерфейса — show mng if, версии прошивки и оставшиеся попытки автоотката — show rdp firmware version. Доступна детальная информация по портам и трансиверам (SFP-данные, DDM, статистика фреймов), а также счётчики пакетов/байт по каждому правилу фильтрации отдельно. Состояние группы балансировки показывает статус каждой filter group (up/bypass) и время прохождения keep-alive-пакета (time of pass); программный байпас, как и на уровне отдельных групп, может включаться индивидуально для диагностики или технических работ.

23. Распознавание протоколов (DPI Engine)

Движок DPI строит решение на многофакторном анализе сессии в целом, а не отдельного пакета: учитываются размеры пакетов и их вариации в рамках сессии, частота прохождения пакетов, наличие характерных ключевых слов/паттернов внутри содержимого, а для шифрованного трафика (где явных сигнатур протокола нет) — набор косвенных статистических признаков. По самой природе такого анализа возможны ложноположительные срабатывания, что и обуславливает двухстадийную схему блокировки, описанную в разделе 8: сначала распознавание и накопление статистики по множеству площадок в ЦСУ, затем — уже очищенная от ложных срабатываний блокировка. Документация также упоминает продолжающееся противостояние между разработчиками системы и создателями средств обхода блокировок (обфускация трафика, маскировка под другие протоколы и т. п.) как постоянный фактор, влияющий на развитие DPI-движка, — без раскрытия конкретных технических деталей этой борьбы.

24. Траблшутинг

Общий подход к диагностике проблем доступности ресурса для абонента, по документации, выглядит так: сначала найти сессию конкретного абонента на фильтрах площадки (при необходимости — обходом всех фильтров, поскольку у балансировщика нет собственных логов о маршрутизации пакета, см. раздел 4); затем проверить, под какой DPI-лист попадает интересующий ресурс, командой show dpi match; при подозрении на влияние самого ТСПУ — временно вывести конкретный фильтр или всю площадку в программный байпас и проверить, восстанавливается ли доступ; для точечной диагностики конкретного абонента — временно исключить его адрес из обработки нужным DPI-листом через параметр No IP (см. раздел 17). Отдельная категория проблем — перепутанные местами LAN/WAN порты при физическом монтаже или коммутации, которые диагностируются по характерным аномалиям в таблице сессий (см. раздел 12.5 — появление «чужих» адресов там, где ожидается адрес абонента). Поскольку у ТСПУ нет собственных полноценных L3-интерфейсов в тракте данных, часть диагностических действий (генерация тестового трафика с самого фильтра в сторону оператора) физически невозможна — фильтр не может, например, пропинговать оборудование оператора через LAN/WAN-интерфейсы, только через management. Наконец, ряд ситуаций (в первую очередь связанных с адресацией после CGNAT или с разводкой VLAN у оператора) требует прямого взаимодействия с инженерами оператора связи, поскольку часть нужной для диагностики информации находится вне зоны видимости ТСПУ.

25. Бонус: оборудование

В репозитории отдельным разделом (tspu-equipment/README.md) собраны материалы о конкретных физических платформах, использующихся в проекте, — фотографии и обозначения моделей байпасов, фильтров и балансировщиков разных производителей и поколений. Это скорее иллюстративный каталог, чем нормативный текст, поэтому в рамках данной статьи он не пересказывается построчно; интересующимся стоит смотреть непосредственно оригинал в репозитории.

Итоговые замечания

Несколько сквозных идей, которые стоит держать в уме при чтении всего материала:

Прозрачность как архитектурный принцип. На каждом уровне — байпас, балансировщик, фильтр — система спроектирована так, чтобы оператор связи не видел и не ощущал присутствия ТСПУ в штатном режиме: LLDP выключен, MTU выставлен в максимум, инкапсуляция не модифицируется, а любые сбои по возможности переводятся в режимы, не вызывающие флапов линков.
Двухстадийность и централизация как способ снизить ложные срабатывания. И блокировка протоколов, и (в перспективе) многие другие решения строятся по схеме «локальное распознавание → централизованный анализ с более широким контекстом → точная блокировка», а не «увидел — сразу заблокировал».
Эшелонирование — компромисс экономики и полноты покрытия. Второй эшелон появился не потому, что первый плохо справляется, а потому что для отдельных топологий (асимметричный трафик крупных операторов) плоская схема принципиально не работает, а плодить полноценные ТСПУ типа А у каждого небольшого оператора нерентабельно.
Наследие CGNAT-платформы. Многие внешне странные детали (сущность «трансляции» при выключенном NAT, малополезные в проекте ключевые слова global/ga) объясняются тем, что аппаратно-программная платформа фильтра выросла из более раннего продукта для операторского NAT, а не создавалась с нуля под задачи DPI-фильтрации.

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