diff --git a/README.md b/README.md index 15be685..02c0c26 100644 --- a/README.md +++ b/README.md @@ -12,139 +12,108 @@ > **Примечание:** Данная документация сгенерирована с помощью ИИ на основе транскрипта ~5-часовой видеолекции и проверена вручную. Может содержать неточности. -### [1. Введение и общая архитектура АСБИ](chapters/01.md) +### Часть I. Обзор системы -- 1.1. Что такое АСБИ (Автоматизированная система обеспечения безопасности интернета) -- 1.2. Закон о суверенном интернете и участники проекта (ГРЧЦ, ДЦОА, RDP.ru) +#### [1. Введение и общая архитектура АСБИ](docs/overview.md) + +- 1.1. Что такое АСБИ +- 1.2. Закон о суверенном интернете и участники проекта - 1.3. Что такое ТСПУ — комплекс оборудования у операторов связи - 1.4. Общая схема: байпасы, балансировщики, фильтры, сегмент управления -### [2. Прохождение трафика через ТСПУ](chapters/02.md) +#### [2. Прохождение трафика через ТСПУ](docs/traffic-flow.md) -- 2.1. Стык оператора связи: типы инкапсуляции (VLAN, QinQ, MPLS, PPPoE) -- 2.2. Разделение на LAN-порты (абоненты) и WAN-порты (интернет) +- 2.1. Стык оператора связи: типы инкапсуляции +- 2.2. Разделение на LAN-порты и WAN-порты - 2.3. Простейший вариант ТСПУ (один байпас, один фильтр) - 2.4. Типовая схема ТСПУ -### [3. Байпас (Bypass)](chapters/03.md) +#### [3. Места установки ТСПУ в сети оператора](docs/placement.md) -- 3.1. Назначение и роль байпаса в ТСПУ -- 3.2. Байпасы Silicom (федеральный проект) - - 3.2.1. Порты: Net0/Net1 (оператор) и Mon0/Mon1 (балансировщик) - - 3.2.2. Режим Inline — основной рабочий режим - - 3.2.3. Режим TAP — копирование трафика без влияния на оператора - - 3.2.4. Режим Active Bypass — замыкание без копирования - - 3.2.5. Режим Passive Bypass — аварийное оптическое замыкание канала - - 3.2.6. Переключение между режимами и влияние на оператора -- 3.3. Байпасы GL Sun (пилотный проект, Урал) - - 3.3.1. Отличие от Silicom: только пассивный байпас - - 3.3.2. Флап линков при каждом переключении -- 3.4. Мониторинг каналов: Heartbeat-пакеты байпаса -- 3.5. Автоматическое переключение в TAP/Active Bypass при потере канала -- 3.6. Развитие: отечественные байпасы +- 3.1. До BRAS/BPE/BNG (между абонентами и терминацией сессий) +- 3.2. До CGNAT (после BRAS) — наиболее удобная точка +- 3.3. После CGNAT (ближе к выходу в интернет) +- 3.4. Режим On-a-stick (BRAS/CGNAT подключены петлёй) -### [4. Балансировщик (EcoFilter Balancer)](chapters/04.md) +#### [4. Эшелонированная система (ТСПУ тип Б)](docs/echelon.md) -- 4.1. Назначение: распределение трафика по фильтрам -- 4.2. Аппаратная платформа: 32-портовый, 1U, пропускная способность 3.2 Тбит/с -- 4.3. Организация портов: пары LAN/WAN, линки - - 4.3.1. Принцип чётных/нечётных портов - - 4.3.2. Жёсткая привязка: трафик возвращается в тот же линк - - 4.3.3. Асимметричный трафик: все линки — на один балансировщик -- 4.4. Фильтры на балансировщике (Flow rules) - - 4.4.1. Байпас служебного трафика (BGP, мультикаст, маршрутизация) - - 4.4.2. Отправка трафика на группу балансировки -- 4.5. Балансировка трафика - - 4.5.1. Хэш-сумма: source IP + destination IP + протокол - - 4.5.2. Учёт количества ядер фильтров - - 4.5.3. Дополнительный 4-байтный заголовок для фильтров - - 4.5.4. Симметричность хэша: одна сессия — один фильтр, одно ядро -- 4.6. Отказоустойчивость - - 4.6.1. Keep-alive пакеты к фильтрам - - 4.6.2. Программный байпас при потере группы портов - - 4.6.3. Перебалансировка трафика (опционально) -- 4.7. Работа с различными инкапсуляциями (VLAN, MPLS) -- 4.8. Обработка HTTP-редиректов и TCP Reset через фильтры +- 4.1. Назначение: обработка трафика, не прошедшего через ТСПУ тип А +- 4.2. Проблема асимметричного трафика у крупных операторов +- 4.3. Балансировщик Eco Highway +- 4.4. Два конвейера (Pipeline) в Eco Highway +- 4.5. Отличия EcoFilter Balancer от Eco Highway +- 4.6. Отсутствие логирования на Eco Highway (только real-time) +- 4.7. Прозрачный пропуск трафика, уже обработанного ТСПУ тип А -### [5. Фильтр (EcoFilter)](chapters/05.md) +### Часть II. Байпас и балансировщик -- 5.1. Путь пакета через фильтр - - 5.1.1. Проверка: IP-пакет или нет - - 5.1.2. Проверка по ACL (привязка к пулу) - - 5.1.3. Проверка по DPI-листу (IP-подсети) - - 5.1.4. Обработка движком DPI - - 5.1.5. Решение: пропустить или заблокировать (drop) -- 5.2. Работа на уровне L2: фильтр как «прозрачный провод» +#### [5. Байпас (Bypass)](docs/bypass.md) -### [6. Места установки ТСПУ в сети оператора](chapters/06.md) +- 5.1. Назначение и роль байпаса в ТСПУ +- 5.2. Байпасы Silicom (федеральный проект) +- 5.3. Байпасы GL Sun (пилотный проект, Урал) +- 5.4. Мониторинг каналов: Heartbeat-пакеты байпаса +- 5.5. Автоматическое переключение в TAP/Active Bypass при потере канала +- 5.6. Развитие: отечественные байпасы -- 6.1. До BRAS/BPE/BNG (между абонентами и терминацией сессий) - - 6.1.1. Особенность: PPPoE-трафик -- 6.2. До CGNAT (после BRAS) — наиболее удобная точка - - 6.2.1. Видимость серых абонентских IP-адресов -- 6.3. После CGNAT (ближе к выходу в интернет) - - 6.3.1. Только белые адреса, сложности траблшутинга -- 6.4. Режим On-a-stick (BRAS/CGNAT подключены петлёй) - - 6.4.1. Двойное прохождение трафика через ТСПУ - - 6.4.2. Разделение по VLAN для обработки трафика одного направления - - 6.4.3. Проблемы двойной обработки и best practice +#### [6. Балансировщик: принцип работы](docs/balancer.md) -### [7. Эшелонированная система (ТСПУ тип Б)](chapters/07.md) +- 6.1. Назначение: распределение трафика по фильтрам +- 6.2. Аппаратная платформа: 32-портовый, 1U, пропускная способность 3.2 Тбит/с +- 6.3. Организация портов: пары LAN/WAN, линки +- 6.4. Фильтры на балансировщике (Flow rules) +- 6.5. Балансировка трафика +- 6.6. Отказоустойчивость +- 6.7. Работа с различными инкапсуляциями (VLAN, MPLS) +- 6.8. Обработка HTTP-редиректов и TCP Reset через фильтры -- 7.1. Назначение: обработка трафика, не прошедшего через ТСПУ тип А -- 7.2. Проблема асимметричного трафика у крупных операторов -- 7.3. Балансировщик Eco Highway - - 7.3.1. BGP-загрузка списков фильтрации из ЦСУ - - 7.3.2. Блокировка по IP-адресам на уровне балансировщика (Telegram, реестр РКН) - - 7.3.3. Фильтры в режиме On-a-stick, VLAN-разделение LAN/WAN - - 7.3.4. Фильтры занимаются только URL-фильтрацией по реестру РКН -- 7.4. Два конвейера (Pipeline) в Eco Highway - - 7.4.1. Разделение портов между конвейерами - - 7.4.2. Физическая перемычка между конвейерами - - 7.4.3. Прохождение пакета: drop / отправка на фильтр / переход на второй конвейер - - 7.4.4. Удвоение количества правил фильтрации -- 7.5. Отличия EcoFilter Balancer от Eco Highway -- 7.6. Отсутствие логирования на Eco Highway (только real-time) -- 7.7. Прозрачный пропуск трафика, уже обработанного ТСПУ тип А +#### [7. Балансировщик: аппаратная платформа](docs/balancer-platform.md) -### [8. Формирование протокольных списков (двухстадийная блокировка)](chapters/08.md) +- 7.1. Одноюнитовый (32 порта QSFP28) и двухюнитовый (65 портов) +- 7.2. Скорости портов: 10G / 25G / 100G +- 7.3. Гидры (breakout): один QSFP28 → четыре SFP+ (10G) +- 7.4. Внутренняя архитектура +- 7.5. Передняя панель: Console, Management Ethernet, USB -- 8.1. Первый этап: распознавание протоколов на фильтрах (ТСПУ тип А) -- 8.2. Отправка логов на SPFS (сервер предварительного формирования списков) -- 8.3. Передача логов по GRPC в центральную систему управления -- 8.4. Анализ, очистка от ложных срабатываний, формирование списков -- 8.5. Загрузка очищенных списков обратно на фильтры (HTTP) и на Eco Highway (BGP) -- 8.6. Время полного цикла блокировки: ~5–15 минут +#### [8. Балансировщик: конфигурация](docs/balancer-config.md) -### [9. Центральная система управления (ЦСУ)](chapters/09.md) +- 8.1. CLI: операционный режим / конфигурационный режим (`edit`) +- 8.2. Обновление прошивки: `call rdp firmware download` / `call rdp install` +- 8.3. Настройка физических портов +- 8.4. Настройка линков (объединение двух портов LAN+WAN в сторону оператора) +- 8.5. Настройка группы балансировки +- 8.6. Профиль Keep-Alive (liveness profile) +- 8.7. Настройка фильтров (Flow rules) +- 8.8. Настройка Heartbeat для GL Sun (пилотный проект) +- 8.9. Management-интерфейс: IP, маска, default gateway -- 9.1. Архитектура: две независимые площадки (основная и резервная) -- 9.2. Связь с ТСПУ через VPN (криптошлюз «Континент») -- 9.3. Масштаб: ~350 площадок, ~5000 устройств -- 9.4. Подсистемы ЦСУ: формирование списков, мониторинг, логирование, картография -- 9.5. Новая ЦСУ для федерального проекта (замена уральской) +#### [9. Балансировщик: мониторинг и диагностика](docs/balancer-monitoring.md) -### [10. Сегмент управления ТСПУ](chapters/10.md) +- 9.1. `show hardware info` — CPU, память, вентиляторы, БП, температура +- 9.2. `show mng if` — management-интерфейс +- 9.3. `show rdp firmware version` — версии прошивок, tries +- 9.4. Состояние портов и трансиверов: SFP-информация, DDM, статистика фреймов +- 9.5. Статистика правил фильтрации: счётчики пакетов/байт по каждому flow +- 9.6. Состояние группы балансировки +- 9.7. Программный байпас: индивидуально для каждой группы портов -- 10.1. Адресация: 10.<регион>.<площадка>.0/24 -- 10.2. Распределение адресов: байпасы, балансировщики, BMC, фильтры, IPMI, SPFS, СПХД -- 10.3. Шлюз по умолчанию — криптошлюз «Континент» -- 10.4. Подсеть логирования (единая для всех ТСПУ) +### Часть III. Фильтр -### [11. Фильтр: аппаратная платформа](chapters/11.md) +#### [10. Фильтр: принцип работы](docs/filter.md) + +- 10.1. Путь пакета через фильтр +- 10.2. Работа на уровне L2: фильтр как «прозрачный провод» + +#### [11. Фильтр: аппаратная платформа](docs/filter-platform.md) - 11.1. Младшая линейка: EcoFilter 2020/2040 - 11.2. Старшая линейка: EcoFilter 4080/4120/4160 - 11.3. Модели 2019 года (пилотный проект, Урал) - - 11.3.1. Процессоры Intel Xeon 2695/2699, 18/22 ядра, 128/256 ГБ RAM - - 11.3.2. Фиксированные сетевые интерфейсы - 11.4. Модели 2020 года (федеральный проект) - - 11.4.1. Процессор Intel Xeon Gold 6212, 24 ядра, 192/384 ГБ RAM - - 11.4.2. Сменные сетевые интерфейсы, 4× SFP+ лог-порта - 11.5. Разделение интерфейсов: LAN (чётные) / WAN (нечётные) - 11.6. История платформы: от CGNAT (2013) к DPI-фильтру -### [12. Сессии и трансляции на фильтре](chapters/12.md) +#### [12. Фильтр: сессии и трансляции](docs/filter-sessions.md) - 12.1. Понятие сессии: local IP:port + global IP:port + remote IP:port - 12.2. Понятие трансляции: local IP:port ↔ global IP:port @@ -155,56 +124,39 @@ - 12.7. Тайм-ауты сессий и трансляций - 12.8. Команды: `show session`, `show xl`, фильтрация по `local`/`remote`, pipe и count -### [13. Фильтр: первоначальная настройка и CLI](chapters/13.md) +#### [13. Фильтр: первоначальная настройка и CLI](docs/filter-cli.md) - 13.1. Подключение: консоль (115200 8N1) и SSH (порт 22) - 13.2. Логин по умолчанию: admin / econat - 13.3. Операционный режим (>) и конфигурационный режим (#) - 13.4. Навигация по дереву конфигурации: system, pools, access-lists - - 13.4.1. Переход в раздел, exit (..), root (/) - - 13.4.2. Автодополнение (Tab), история команд (↑↓), справка (?) - 13.5. Применение конфигурации: `apply`, сохранение: `wr` - 13.6. Управление конфигурациями: save, load, copy, clear config - 13.7. Одновременная работа двух пользователей: ограничения - 13.8. «Мышеловка» (trap mode) при незакрытой скобке - 13.9. Ключевое слово `ls` для быстрого просмотра -### [14. Фильтр: конфигурация подсистем](chapters/14.md) +#### [14. Фильтр: конфигурация подсистем](docs/filter-subsystems.md) - 14.1. Консольный порт: скорость, тайм-аут неактивности - 14.2. Management-интерфейс: IP, gateway, DNS, allowed IP - - 14.2.1. Добавление/удаление записей: `+=` и `-=` - 14.3. Терминал (SSH): auto-logout, prompt, нумерация строк - - 14.3.1. Лимит сессий (20), опасность `never` для auto-logout - 14.4. Пользователи: создание, удаление, уровни доступа, пароли (secret 0 / 15) - 14.5. TACACS+: авторизация, fallback на локальную базу - 14.6. NTP: до 3 серверов, период обновления - 14.7. SNMP: community (read-only), traps, allow-ip - 14.8. Системное журналирование (syslog) - - 14.8.1. Внешние лог-серверы (до 2), hostname, time shift - - 14.8.2. Уровни логирования по подсистемам (1=ошибки, 2=предупреждения, 3=информация) - - 14.8.3. Подсистема `all` — максимальный уровень для всех - - 14.8.4. Логирование команд пользователя (уровень fatal) - - 14.8.5. SNMP traps: только уровень fatal - 14.9. Журналирование соединений (connection log) — через лог-интерфейс (DPDK) - 14.10. Журналирование протоколов (debug logger) — отправка на SPFS - - 14.10.1. Выбор протоколов (all / конкретные) - - 14.10.2. Количество пакетов на протокол (по умолчанию 30, рекомендуется 3) -### [15. Фильтр: настройка интерфейсов и общих параметров](chapters/15.md) +#### [15. Фильтр: настройка интерфейсов и общих параметров](docs/filter-interfaces.md) - 15.1. Интерфейсы: enable/disable, description (LACP не используется) - 15.2. NAT Defaults — общие параметры устройства - - 15.2.1. **VLAN Mode**: untagged / vlan / qinq — глубина поиска IP-заголовка (всегда qinq) - - 15.2.2. Sessions per Translation (по умолчанию 4096) - - 15.2.3. **Forward Traffic**: всегда ON - - 15.2.4. **L2 MTU**: 9216 - - 15.2.5. **LLDP**: выключен (требование операторов — прозрачность) - - 15.2.6. **Permit Invalid Flow**: всегда ON — приём TCP-сессий без SYN - 15.3. Тайм-ауты сессий и трансляций - 15.4. IPv6: включение, диапазон адресов для обработки -### [16. Фильтр: ACL и пулы — запуск трафика на обработку](chapters/16.md) +#### [16. Фильтр: ACL и пулы — запуск трафика на обработку](docs/filter-acl-pools.md) - 16.1. Создание ACL: `create acl`, правила (allow/deny), протоколы, source/destination, VLAN - 16.2. Создание пула: `create pool`, тип = fake (без NAT) @@ -214,39 +166,15 @@ - 16.6. IPv6 в пуле - 16.7. Секция bypass — heartbeat к байпасу GL Sun (только пилотный проект) -### [17. Фильтр: настройка DPI](chapters/17.md) +#### [17. Фильтр: настройка DPI](docs/filter-dpi.md) - 17.1. Общие настройки модуля DPI - - 17.1.1. Включение/выключение DPI - - 17.1.2. **Send RST off**: отключение TCP Reset при блокировке протоколов - - 17.1.3. Functionality mode: normal (не double mirror traffic) - 17.2. Настройка реестра РКН - - 17.2.1. Источник: RKN или GRFЦ - - 17.2.2. Логин/пароль для доступа к серверу РКН - - 17.2.3. Привязка к DPI-листу (list number) - - 17.2.4. Proxy-сервер, dump server - - 17.2.5. Проблемы скачивания: минимальная скорость ~10 Мбит/с - 17.3. Деградация протоколов (protocols capacity) - - 17.3.1. Шкала 0–100: 0 = полная блокировка, 100 = полный пропуск - - 17.3.2. Дроп пакетов с заданной вероятностью - - 17.3.3. Эффективная деградация: 2–10% пропускания - - 17.3.4. Влияние на голосовые вызовы и мессенджеры - 17.4. Настройка DPI-листов (0–16) - - 17.4.1. Enable/disable каждого листа - - 17.4.2. BitTorrent UTP detection - - 17.4.3. WH List Mode: blacklist (по умолчанию) / whitelist - - 17.4.4. **Behavior**: block / ignore / color / redirect - - 17.4.5. Redirect URL — страница-заглушка для заблокированных HTTP-ресурсов - - 17.4.6. Download URL — источник списков, update schedule - - 17.4.7. Protocols — список распознаваемых протоколов - - 17.4.8. **No IP** / **IP** — исключение/включение адресов для обработки - - 17.4.9. QUIC list - 17.5. Формат списков фильтрации - - 17.5.1. IP-адреса, подсети, диапазоны, URL - - 17.5.2. HTTP: блокировка конкретного URL - - 17.5.3. HTTPS: блокировка только по домену (SNI/Client Hello) -### [18. Фильтр: мониторинг и диагностика](chapters/18.md) +#### [18. Фильтр: мониторинг и диагностика](docs/filter-monitoring.md) - 18.1. `show version` — версия ПО, серийный номер (= MAC management) - 18.2. `show ip if` — параметры management-интерфейса @@ -255,26 +183,15 @@ - 18.5. Аппаратная часть: `show power`, `show fan`, `show temperature` - 18.6. Интерфейсы: `show interface brief`, traffic monitor, трансиверы (DDM) - 18.7. Ресурсы: `show resources` - - 18.7.1. Таблицы сессий/трансляций: не более 20% загрузки - - 18.7.2. Свободные буферы: не должны уходить в ноль - - 18.7.3. DPI-ресурсы: не более 100% - - 18.7.4. CPU Load — условный параметр обработки трафика - 18.8. Память: Control Plane vs Data Plane - - 18.8.1. Data Plane выделяется при старте, не должна расти - - 18.8.2. Пороги: 5–10% свободной памяти — повод для тревоги - 18.9. `show cps` — скорость создания новых сессий - 18.10. `show statistic` — статистика сессий и пулов, значение Optimal (= 20%) - 18.11. Счётчики: `show counters all` / `show counters div` (дельта за секунду) - 18.12. Системный журнал: `show syslog`, ротация двух файлов - 18.13. DPI-мониторинг - - 18.13.1. `show dpi records ` — содержимое DPI-листа - - 18.13.2. `show dpi state` — количество записей, дата последнего дампа - - 18.13.3. `dpi load ` — ручная загрузка списка - - 18.13.4. `dpi run` — принудительное обновление всех списков - - 18.13.5. `show dpi match <ресурс>` — проверка ресурса по всем DPI-листам - 18.14. Ping и Traceroute (из конфигурационного режима) -### [19. Фильтр: обновление прошивки](chapters/19.md) +#### [19. Фильтр: обновление прошивки](docs/filter-firmware.md) - 19.1. Два раздела: prim1 и prim2 (равнозначные) + FB (заводская) - 19.2. `firmware status` — текущее состояние (cur / boot) @@ -282,79 +199,48 @@ - 19.4. `firmware rollback` / `firmware reset` - 19.5. Централизованное обновление через ЦСУ -### [20. Балансировщик: аппаратная платформа](chapters/20.md) +### Часть IV. Управление и блокировка -- 20.1. Одноюнитовый (32 порта QSFP28) и двухюнитовый (65 портов) -- 20.2. Скорости портов: 10G / 25G / 100G -- 20.3. Гидры (breakout): один QSFP28 → четыре SFP+ (10G) -- 20.4. Внутренняя архитектура - - 20.4.1. Микросервер (Intel, Linux) — CLI, конфигурация - - 20.4.2. Чип Barefoot Tofino — программируемая коммутация - - 20.4.3. BMC — управление аппаратной частью, сенсоры, блоки питания - - 20.4.4. Ethernet switch (5-портовый) — доступ к микросерверу и BMC - - 20.4.5. Console MUX — переключение консоли между компонентами -- 20.5. Передняя панель: Console, Management Ethernet, USB +#### [20. Сегмент управления ТСПУ](docs/management-segment.md) -### [21. Балансировщик: конфигурация](chapters/21.md) +- 20.1. Адресация: 10.<регион>.<площадка>.0/24 +- 20.2. Распределение адресов: байпасы, балансировщики, BMC, фильтры, IPMI, SPFS, СПХД +- 20.3. Шлюз по умолчанию — криптошлюз «Континент» +- 20.4. Подсеть логирования (единая для всех ТСПУ) -- 21.1. CLI: операционный режим / конфигурационный режим (`edit`) - - 21.1.1. Интерфейс похож на Juniper CLI - - 21.1.2. `apply` — применить, `save` — сохранить в startup -- 21.2. Обновление прошивки: `call rdp firmware download` / `call rdp install` - - 21.2.1. Два раздела прошивок (A/B), автоматический rollback (3 попытки / 20 мин) - - 21.2.2. `call rdp firmware reset-tries` -- 21.3. Настройка физических портов - - 21.3.1. Имя порта, номер физического порта (number), линия (lane), скорость (speed) - - 21.3.2. 10G: указание lane (1–4), 100G: все lane задействованы -- 21.4. Настройка линков (объединение двух портов LAN+WAN в сторону оператора) -- 21.5. Настройка группы балансировки - - 21.5.1. Привязка групп портов в сторону фильтров (filter groups) - - 21.5.2. nat-unit-queues: количество ядер фильтра минус один -- 21.6. Профиль Keep-Alive (liveness profile) - - 21.6.1. Допустимая задержка, интервал, пороги потерь и восстановления - - 21.6.2. Минимальное количество активных пар - - 21.6.3. Перебалансировка: включение/выключение -- 21.7. Настройка фильтров (Flow rules) - - 21.7.1. Match-условия: VLAN, IPv4 src/dst, L4 port, MAC, MPLS, глубина тегов - - 21.7.2. Actions: `balancing-as mag-hash` → balance group / `bypass` - - 21.7.3. Приоритеты правил - - 21.7.4. Привязка фильтров к линкам -- 21.8. Настройка Heartbeat для GL Sun (пилотный проект) -- 21.9. Management-интерфейс: IP, маска, default gateway +#### [21. Центральная система управления (ЦСУ)](docs/central-management.md) -### [22. Балансировщик: мониторинг и диагностика](chapters/22.md) +- 21.1. Архитектура: две независимые площадки (основная и резервная) +- 21.2. Связь с ТСПУ через VPN (криптошлюз «Континент») +- 21.3. Масштаб: ~350 площадок, ~5000 устройств +- 21.4. Подсистемы ЦСУ: формирование списков, мониторинг, логирование, картография +- 21.5. Новая ЦСУ для федерального проекта (замена уральской) -- 22.1. `show hardware info` — CPU, память, вентиляторы, БП, температура -- 22.2. `show mng if` — management-интерфейс -- 22.3. `show rdp firmware version` — версии прошивок, tries -- 22.4. Состояние портов и трансиверов: SFP-информация, DDM, статистика фреймов -- 22.5. Статистика правил фильтрации: счётчики пакетов/байт по каждому flow -- 22.6. Состояние группы балансировки - - 22.6.1. Статус filter groups: up/bypass - - 22.6.2. time-on-path — время прохождения keep-alive пакета -- 22.7. Программный байпас: индивидуально для каждой группы портов +#### [22. Распознавание протоколов и двухстадийная блокировка](docs/protocol-blocking.md) -### [23. Распознавание протоколов (DPI Engine)](chapters/23.md) +- 22.1. Многофакторный анализ сессий +- 22.2. Ложноположительные срабатывания +- 22.3. Обфускация и борьба с обходом блокировок +- 22.4. Двухстадийная блокировка: распознавание → очистка в ЦСУ → блокировка +- 22.5. Первый этап: распознавание протоколов на фильтрах (ТСПУ тип А) +- 22.6. Отправка логов на SPFS (сервер предварительного формирования списков) +- 22.7. Передача логов по GRPC в центральную систему управления +- 22.8. Анализ, очистка от ложных срабатываний, формирование списков +- 22.9. Загрузка очищенных списков обратно на фильтры (HTTP) и на Eco Highway (BGP) +- 22.10. Время полного цикла блокировки: ~5–15 минут -- 23.1. Многофакторный анализ сессий - - 23.1.1. Размеры пакетов и их вариации - - 23.1.2. Частота прохождения пакетов - - 23.1.3. Ключевые слова и паттерны внутри пакетов - - 23.1.4. Особенности анализа шифрованного трафика -- 23.2. Ложноположительные срабатывания -- 23.3. Двухстадийная блокировка: распознавание → очистка в ЦСУ → блокировка -- 23.4. Обфускация и борьба с обходом блокировок +### Часть V. Эксплуатация -### [24. Траблшутинг](chapters/24.md) +#### [23. Траблшутинг](docs/troubleshooting.md) -- 24.1. Общий подход к диагностике проблем доступности -- 24.2. Поиск сессии абонента: обход фильтров площадки -- 24.3. Проверка ресурса в DPI-листах: `show dpi match` -- 24.4. Программный байпас для исключения ТСПУ как причины проблемы -- 24.5. Исключение абонента из обработки: параметр No IP -- 24.6. Перепутки LAN/WAN и их диагностика -- 24.7. Взаимодействие с оператором связи -- 24.8. Ограничения: L2-устройство, невозможность генерации трафика с фильтра +- 23.1. Общий подход к диагностике проблем доступности +- 23.2. Поиск сессии абонента: обход фильтров площадки +- 23.3. Проверка ресурса в DPI-листах: `show dpi match` +- 23.4. Программный байпас для исключения ТСПУ как причины проблемы +- 23.5. Исключение абонента из обработки: параметр No IP +- 23.6. Перепутки LAN/WAN и их диагностика +- 23.7. Взаимодействие с оператором связи +- 23.8. Ограничения: L2-устройство, невозможность генерации трафика с фильтра ### [Бонус: Оборудование](tspu-equipment/README.md) diff --git a/chapters/01.md b/chapters/01.md new file mode 100644 index 0000000..1505640 --- /dev/null +++ b/chapters/01.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [1. Введение и общая архитектура АСБИ](../docs/overview.md). + +[← Оглавление](../README.md) diff --git a/chapters/02.md b/chapters/02.md new file mode 100644 index 0000000..e0e6bd9 --- /dev/null +++ b/chapters/02.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [2. Прохождение трафика через ТСПУ](../docs/traffic-flow.md). + +[← Оглавление](../README.md) diff --git a/chapters/03.md b/chapters/03.md new file mode 100644 index 0000000..018b39c --- /dev/null +++ b/chapters/03.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [5. Байпас (Bypass)](../docs/bypass.md). + +[← Оглавление](../README.md) diff --git a/chapters/04.md b/chapters/04.md new file mode 100644 index 0000000..a0242e2 --- /dev/null +++ b/chapters/04.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [6. Балансировщик: принцип работы](../docs/balancer.md). + +[← Оглавление](../README.md) diff --git a/chapters/05.md b/chapters/05.md new file mode 100644 index 0000000..806cdd0 --- /dev/null +++ b/chapters/05.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [10. Фильтр: принцип работы](../docs/filter.md). + +[← Оглавление](../README.md) diff --git a/chapters/06.md b/chapters/06.md new file mode 100644 index 0000000..f3a11b5 --- /dev/null +++ b/chapters/06.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [3. Места установки ТСПУ в сети оператора](../docs/placement.md). + +[← Оглавление](../README.md) diff --git a/chapters/07.md b/chapters/07.md new file mode 100644 index 0000000..866e283 --- /dev/null +++ b/chapters/07.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [4. Эшелонированная система (ТСПУ тип Б)](../docs/echelon.md). + +[← Оглавление](../README.md) diff --git a/chapters/08.md b/chapters/08.md new file mode 100644 index 0000000..2e0dbf0 --- /dev/null +++ b/chapters/08.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [22. Распознавание протоколов и двухстадийная блокировка](../docs/protocol-blocking.md) (пункты 22.5–22.10). + +[← Оглавление](../README.md) diff --git a/chapters/09.md b/chapters/09.md new file mode 100644 index 0000000..ab8d7ea --- /dev/null +++ b/chapters/09.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [21. Центральная система управления (ЦСУ)](../docs/central-management.md). + +[← Оглавление](../README.md) diff --git a/chapters/10.md b/chapters/10.md new file mode 100644 index 0000000..43a07ad --- /dev/null +++ b/chapters/10.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [20. Сегмент управления ТСПУ](../docs/management-segment.md). + +[← Оглавление](../README.md) diff --git a/chapters/11.md b/chapters/11.md new file mode 100644 index 0000000..137e2ae --- /dev/null +++ b/chapters/11.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [11. Фильтр: аппаратная платформа](../docs/filter-platform.md). + +[← Оглавление](../README.md) diff --git a/chapters/12.md b/chapters/12.md new file mode 100644 index 0000000..4f064fe --- /dev/null +++ b/chapters/12.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [12. Фильтр: сессии и трансляции](../docs/filter-sessions.md). + +[← Оглавление](../README.md) diff --git a/chapters/13.md b/chapters/13.md new file mode 100644 index 0000000..f85b3b5 --- /dev/null +++ b/chapters/13.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [13. Фильтр: первоначальная настройка и CLI](../docs/filter-cli.md). + +[← Оглавление](../README.md) diff --git a/chapters/14.md b/chapters/14.md new file mode 100644 index 0000000..dcda8ad --- /dev/null +++ b/chapters/14.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [14. Фильтр: конфигурация подсистем](../docs/filter-subsystems.md). + +[← Оглавление](../README.md) diff --git a/chapters/15.md b/chapters/15.md new file mode 100644 index 0000000..8d5e290 --- /dev/null +++ b/chapters/15.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [15. Фильтр: настройка интерфейсов и общих параметров](../docs/filter-interfaces.md). + +[← Оглавление](../README.md) diff --git a/chapters/16.md b/chapters/16.md new file mode 100644 index 0000000..9c8d99d --- /dev/null +++ b/chapters/16.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [16. Фильтр: ACL и пулы — запуск трафика на обработку](../docs/filter-acl-pools.md). + +[← Оглавление](../README.md) diff --git a/chapters/17.md b/chapters/17.md new file mode 100644 index 0000000..90453e6 --- /dev/null +++ b/chapters/17.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [17. Фильтр: настройка DPI](../docs/filter-dpi.md). + +[← Оглавление](../README.md) diff --git a/chapters/18.md b/chapters/18.md new file mode 100644 index 0000000..69a2bb9 --- /dev/null +++ b/chapters/18.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [18. Фильтр: мониторинг и диагностика](../docs/filter-monitoring.md). + +[← Оглавление](../README.md) diff --git a/chapters/19.md b/chapters/19.md new file mode 100644 index 0000000..cd6888b --- /dev/null +++ b/chapters/19.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [19. Фильтр: обновление прошивки](../docs/filter-firmware.md). + +[← Оглавление](../README.md) diff --git a/chapters/20.md b/chapters/20.md new file mode 100644 index 0000000..a0e5f9c --- /dev/null +++ b/chapters/20.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [7. Балансировщик: аппаратная платформа](../docs/balancer-platform.md). + +[← Оглавление](../README.md) diff --git a/chapters/21.md b/chapters/21.md new file mode 100644 index 0000000..d9c756a --- /dev/null +++ b/chapters/21.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [8. Балансировщик: конфигурация](../docs/balancer-config.md). + +[← Оглавление](../README.md) diff --git a/chapters/22.md b/chapters/22.md new file mode 100644 index 0000000..dbcfe98 --- /dev/null +++ b/chapters/22.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [9. Балансировщик: мониторинг и диагностика](../docs/balancer-monitoring.md). + +[← Оглавление](../README.md) diff --git a/chapters/23.md b/chapters/23.md new file mode 100644 index 0000000..3c19e0e --- /dev/null +++ b/chapters/23.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [22. Распознавание протоколов и двухстадийная блокировка](../docs/protocol-blocking.md) (пункты 22.1–22.4). + +[← Оглавление](../README.md) diff --git a/chapters/24.md b/chapters/24.md new file mode 100644 index 0000000..5fd0889 --- /dev/null +++ b/chapters/24.md @@ -0,0 +1,5 @@ +# Раздел перенесён + +Документация реорганизована. Материал этой страницы теперь находится в разделе [23. Траблшутинг](../docs/troubleshooting.md). + +[← Оглавление](../README.md) diff --git a/docs/balancer-config.md b/docs/balancer-config.md index 3083a56..f249289 100644 --- a/docs/balancer-config.md +++ b/docs/balancer-config.md @@ -1,12 +1,12 @@ -# 21. Балансировщик: конфигурация +# 8. Балансировщик: конфигурация -[← Оглавление](../README.md) · [← Раздел 20: Балансировщик: аппаратная платформа](20.md) +[← Оглавление](../README.md) · [← Раздел 7: Балансировщик: аппаратная платформа](balancer-platform.md) --- Настройка балансировщика (EcoFilter Balancer) начинается после установки прошивки и конфигурации сегмента управления. В отличие от фильтра, на балансировщике **нет дефолтной конфигурации** — все секции (порты, линки, группы балансировки, фильтры) необходимо создавать вручную. -## 21.1. CLI: операционный режим / конфигурационный режим (`edit`) +## 8.1. CLI: операционный режим / конфигурационный режим (`edit`) CLI балансировщика, как и у фильтра, имеет **два режима** работы: @@ -17,7 +17,7 @@ CLI балансировщика, как и у фильтра, имеет **дв > **Отличие от фильтра:** на фильтре для перехода в конфигурационный режим используется команда `config`, а на балансировщике — **`edit`**. -### 21.1.1. Интерфейс похож на Juniper CLI +### 8.1.1. Интерфейс похож на Juniper CLI Интерфейс командной строки балансировщика **очень похож на CLI Juniper**. Настройки задаются с помощью команды `set`: @@ -27,7 +27,7 @@ CLI балансировщика, как и у фильтра, имеет **дв Для тех, кто знаком с оборудованием Juniper, работа с CLI балансировщика не вызовет затруднений. -### 21.1.2. `apply` — применить, `save` — сохранить в startup +### 8.1.2. `apply` — применить, `save` — сохранить в startup После внесения изменений их необходимо применить и сохранить: @@ -51,7 +51,7 @@ CLI балансировщика, как и у фильтра, имеет **дв > **Важно:** в прошивке пилотного проекта (Урал) команда `apply` одновременно и применяла, и сохраняла конфигурацию в startup-config. В текущих (федеральных) прошивках это поведение изменено: `apply` только применяет, а для сохранения нужна отдельная команда `save`. -## 21.2. Обновление прошивки: `call rdp firmware download` / `call rdp install` +## 8.2. Обновление прошивки: `call rdp firmware download` / `call rdp install` Обновление прошивки балансировщика выполняется в **два этапа** — скачивание и установка: @@ -80,7 +80,7 @@ CLI балансировщика, как и у фильтра, имеет **дв | `call rdp firmware set-active` | Установить активную прошивку на указанный раздел | | `show rdp firmware version` | Показать состояние прошивок (версия, активность, tries) | -### 21.2.1. Два раздела прошивок (A/B), автоматический rollback (3 попытки / 20 мин) +### 8.2.1. Два раздела прошивок (A/B), автоматический rollback (3 попытки / 20 мин) Как и на фильтре, балансировщик хранит **два раздела** прошивок — **A** и **B**: @@ -103,7 +103,7 @@ CLI балансировщика, как и у фильтра, имеет **дв > **Практический совет:** если вам нужно несколько раз перезагрузить балансировщик в короткий промежуток времени (например, для тестирования), помните о лимите в 3 перезагрузки. После третьей перезагрузки за короткий период прошивка будет признана нестабильной. Количество попыток и временной интервал **не настраиваются** — они зашиты в прошивке. -### 21.2.2. `call rdp firmware reset-tries` +### 8.2.2. `call rdp firmware reset-tries` Для сброса счётчика попыток загрузки используется команда: @@ -113,7 +113,7 @@ CLI балансировщика, как и у фильтра, имеет **дв Эта команда обнуляет значение **tries**, позволяя продолжить перезагрузки без риска автоматического переключения на другой раздел. В промышленной эксплуатации эта команда практически не требуется, но знать о ней полезно. -## 21.3. Настройка физических портов +## 8.3. Настройка физических портов Настройка физических портов — это **первый шаг** конфигурации балансировщика. Поскольку дефолтной конфигурации нет, все порты необходимо создавать вручную. @@ -135,7 +135,7 @@ CLI балансировщика, как и у фильтра, имеет **дв set ports p2-2 number 2 lane 2 speed 10g ``` -### 21.3.1. Имя порта, номер физического порта (number), линия (lane), скорость (speed) +### 8.3.1. Имя порта, номер физического порта (number), линия (lane), скорость (speed) Имя порта может быть **произвольным**, однако рекомендуется придерживаться единообразной схемы именования, отражающей номер физического порта и номер линии: @@ -151,7 +151,7 @@ CLI балансировщика, как и у фильтра, имеет **дв | `p2-2` | 2 | 2 | 10G | Порт 2, линия 2 — второй 10G-канал | | `p2` | 2 | — | 100G | Порт 2, все линии — 100G-канал | -### 21.3.2. 10G: указание lane (1–4), 100G: все lane задействованы +### 8.3.2. 10G: указание lane (1–4), 100G: все lane задействованы Поведение параметра **lane** зависит от выбранной скорости: @@ -178,7 +178,7 @@ CLI балансировщика, как и у фильтра, имеет **дв > **Рекомендация:** все физические порты настраиваются в соответствии со схемой организации связи на конкретной площадке. Единых «стандартных» настроек нет — конфигурация полностью зависит от того, какие устройства и на каких скоростях подключены к балансировщику. -## 21.4. Настройка линков (объединение двух портов LAN+WAN в сторону оператора) +## 8.4. Настройка линков (объединение двух портов LAN+WAN в сторону оператора) **Линк** (link) в терминологии балансировщика — это объединение **двух портов** (LAN и WAN) в сторону оператора связи: @@ -221,7 +221,7 @@ CLI балансировщика, как и у фильтра, имеет **дв > **Рекомендация:** в описании линка указывайте, к какому конкретно байпасу и к каким его интерфейсам подключён данный линк. Это значительно упрощает диагностику. -## 21.5. Настройка группы балансировки +## 8.5. Настройка группы балансировки После настройки портов и линков необходимо создать **группу балансировки** (balance group) и привязать к ней группы портов в сторону фильтров. @@ -239,7 +239,7 @@ CLI балансировщика, как и у фильтра, имеет **дв (liveness) ``` -### 21.5.1. Привязка групп портов в сторону фильтров (filter groups) +### 8.5.1. Привязка групп портов в сторону фильтров (filter groups) К группе балансировки привязываются **filter groups** — пары портов (LAN + WAN) в сторону фильтров: @@ -256,7 +256,7 @@ CLI балансировщика, как и у фильтра, имеет **дв Каждая filter group объединяет один LAN-порт и один WAN-порт, смотрящие в сторону конкретной пары интерфейсов фильтра. -### 21.5.2. nat-unit-queues: количество ядер фильтра минус один +### 8.5.2. nat-unit-queues: количество ядер фильтра минус один Параметр **`nat-unit-queues`** сообщает балансировщику количество ядер на подключённых фильтрах, которые участвуют в обработке трафика: @@ -276,7 +276,7 @@ CLI балансировщика, как и у фильтра, имеет **дв Этот параметр **напрямую влияет на балансировку** — балансировщик распределяет трафик не только между фильтрами, но и между их ядрами, обеспечивая равномерную нагрузку. В новых версиях ПО число ядер задаётся в настройках группы балансировки (параметр `cores`). -## 21.6. Профиль Keep-Alive (liveness profile) +## 8.6. Профиль Keep-Alive (liveness profile) К группе балансировки привязывается **профиль Keep-Alive** (liveness profile, параметр группы `liveness-profile`), определяющий параметры отправки keep-alive-пакетов через группы портов в сторону фильтров. @@ -290,11 +290,11 @@ CLI балансировщика, как и у фильтра, имеет **дв set liveness profile <имя_профиля> probes-up-count <число> ``` -### 21.6.1. Допустимая задержка, интервал, пороги потерь и восстановления +### 8.6.1. Допустимая задержка, интервал, пороги потерь и восстановления | Параметр | Описание | | -------------------------- | -------------------------------------------------------------------- | -| **`initial-delay`** | По руководству производителя — максимально допустимая задержка между keep-alive-пакетами, при превышении которой срабатывает счётчик потерь; по эксплуатационным описаниям — пауза перед началом отправки keep-alive после поднятия интерфейсов, чтобы фильтр успел их инициализировать (например, 1000 мс). Подробнее — [раздел 4.6.1](04.md) | +| **`initial-delay`** | По руководству производителя — максимально допустимая задержка между keep-alive-пакетами, при превышении которой срабатывает счётчик потерь; по эксплуатационным описаниям — пауза перед началом отправки keep-alive после поднятия интерфейсов, чтобы фильтр успел их инициализировать (например, 1000 мс). Подробнее — [раздел 6.6.1](balancer.md) | | **`interval`** | Периодичность отправки keep-alive-пакетов, мс (например, 100) | | **`probes-down-count`** | Количество последовательно потерянных пакетов, после которых filter group считается **неактивной** (например, 5) | | **`probes-up-count`** | Количество последовательно полученных ответов, после которых неактивная filter group снова считается **активной** (например, 5) | @@ -303,15 +303,15 @@ CLI балансировщика, как и у фильтра, имеет **дв При потере заданного количества последовательных пакетов filter group переводится в состояние **bypass** — трафик не отправляется на фильтр, а перекладывается из одного порта в другой на уровне логики балансировщика. -### 21.6.2. Минимальное количество активных пар +### 8.6.2. Минимальное количество активных пар Параметр **минимальное количество активных пар** (`active-pairs`) определяет, при каком количестве рабочих filter groups вся группа балансировки **целиком** считается активной. Пример: если задано значение 8, то группа балансировки будет считаться рабочей, пока хотя бы 8 filter groups активны — неважно, сколько их всего. -> **Уральский пилотный проект:** минимальное количество активных пар было установлено **равным общему количеству** пар в сторону фильтров. В результате при потере хотя бы одного интерфейса вся группа балансировки переходила в неактивное состояние, балансировщик прекращал отправку heartbeat на байпас GL Sun, и тот переводил линки в аппаратный байпас с флапом у оператора ([раздел 3.3.1](03.md)). Весь трафик ТСПУ снимался из-за одного упавшего интерфейса. Такое поведение **не обязательно** — значение можно настроить более гибко. +> **Уральский пилотный проект:** минимальное количество активных пар было установлено **равным общему количеству** пар в сторону фильтров. В результате при потере хотя бы одного интерфейса вся группа балансировки переходила в неактивное состояние, балансировщик прекращал отправку heartbeat на байпас GL Sun, и тот переводил линки в аппаратный байпас с флапом у оператора ([раздел 5.3.1](bypass.md)). Весь трафик ТСПУ снимался из-за одного упавшего интерфейса. Такое поведение **не обязательно** — значение можно настроить более гибко. -### 21.6.3. Перебалансировка: включение/выключение +### 8.6.3. Перебалансировка: включение/выключение Параметр **перебалансировки** (`rebalance`, значения enable/disable) задаётся в настройках группы балансировки, а не в профиле Keep-Alive, и определяет, что происходит при выходе из строя одной из filter groups: @@ -324,16 +324,16 @@ CLI балансировщика, как и у фильтра, имеет **дв > **Рекомендация:** в федеральном проекте перебалансировку планируется **отключить**. При потере filter group для конкретной пары интерфейсов включается **программный bypass** — трафик не отправляется на фильтр, а перекладывается из LAN-порта в WAN-порт и наоборот. Последствия минимальны: небольшая часть трафика временно не фильтруется. Это меньшее зло, чем флапание линков или массовый переезд сессий при перебалансировке. Система мониторинга получает уведомления (логи, SNMP traps), и проблема устраняется вручную. -## 21.7. Настройка фильтров (Flow rules) +## 8.7. Настройка фильтров (Flow rules) -**Фильтр** на балансировщике — именованный набор правил (flows), который привязывается к линкам в сторону оператора (параметр `apply-to-links`, [раздел 21.7.4](#2174-привязка-фильтров-к-линкам)). Каждое правило состоит из условия (match) и действия (action); порядок проверки задаёт приоритет (priority, [раздел 21.7.3](#2173-приоритеты-правил)): +**Фильтр** на балансировщике — именованный набор правил (flows), который привязывается к линкам в сторону оператора (параметр `apply-to-links`, [раздел 8.7.4](#874-привязка-фильтров-к-линкам)). Каждое правило состоит из условия (match) и действия (action); порядок проверки задаёт приоритет (priority, [раздел 8.7.3](#873-приоритеты-правил)): | Часть | Описание | | ---------- | ----------------------------------------------------------- | | **Match** | Условия, по которым отбирается трафик (заголовки пакетов) | | **Action** | Действие с пакетом при совпадении | -### 21.7.1. Match-условия: VLAN, IPv4 src/dst, L4 port, MAC, MPLS, глубина тегов +### 8.7.1. Match-условия: VLAN, IPv4 src/dst, L4 port, MAC, MPLS, глубина тегов Доступные условия для match-секции: @@ -351,7 +351,7 @@ CLI балансировщика, как и у фильтра, имеет **дв Match-условия можно использовать как для **включения** трафика в обработку, так и для **исключения** определённого трафика. -### 21.7.2. Actions: `balancing-as mag-hash` → balance group / `bypass` +### 8.7.2. Actions: `balancing-as mag-hash` → balance group / `bypass` Действие (action) определяет, что происходит с пакетом при совпадении: @@ -383,7 +383,7 @@ Match-условия можно использовать как для **вкл set filters main flows default-bypass priority 1 ``` -### 21.7.3. Приоритеты правил +### 8.7.3. Приоритеты правил Каждому правилу назначается **приоритет** (priority), определяющий порядок обработки. Пакет проверяется по правилам в порядке убывания приоритета — от **высшего** к **низшему**. Первое совпавшее правило определяет действие. @@ -403,7 +403,7 @@ Match-условия можно использовать как для **вкл > **Применение для диагностики:** при траблшутинге можно создать правило с высоким приоритетом, которое перехватывает трафик конкретного VLAN и выполняет action `bypass`. Это позволяет исключить конкретный трафик из обработки фильтрами и проверить, влияет ли ТСПУ на проблему. По статистике правила (количество пакетов/байт) можно убедиться, что трафик действительно проходит через это правило. -### 21.7.4. Привязка фильтров к линкам +### 8.7.4. Привязка фильтров к линкам После настройки правил необходимо **привязать фильтр к линкам** — указать, на каких линках (в сторону оператора) данные правила будут действовать: @@ -419,7 +419,7 @@ Match-условия можно использовать как для **вкл Один набор правил (фильтр) может быть привязан к **нескольким линкам** одновременно. Все линки, привязанные к фильтру, используют одни и те же flow rules. -## 21.8. Настройка Heartbeat для GL Sun (пилотный проект) +## 8.8. Настройка Heartbeat для GL Sun (пилотный проект) Данная настройка актуальна **только для пилотного проекта на Урале**, где используются байпасы GL Sun. В федеральном проекте с байпасами Silicom эта настройка **не требуется** — Silicom самостоятельно генерирует и проверяет heartbeat-пакеты. @@ -441,7 +441,7 @@ Heartbeat-пакеты отправляются только при услови > **Примечание:** с байпасами Silicom логика работы другая — Silicom самостоятельно отсылает heartbeat и проверяет доступность интерфейсов, а балансировщик прозрачно пропускает эти пакеты между своими портами. -## 21.9. Management-интерфейс: IP, маска, default gateway +## 8.9. Management-интерфейс: IP, маска, default gateway Настройка management-интерфейса балансировщика выполняется аналогично другим сетевым устройствам: @@ -453,7 +453,7 @@ Heartbeat-пакеты отправляются только при услови Management-интерфейс обеспечивает доступ к устройству по SSH и используется для управления, мониторинга и взаимодействия с ЦСУ. -> **Напоминание:** management Ethernet работает **только** на скорости 1 Гбит/с (см. [раздел 20.2](20.md)). +> **Напоминание:** management Ethernet работает **только** на скорости 1 Гбит/с (см. [раздел 7.2](balancer-platform.md)). --- @@ -485,4 +485,4 @@ Management-интерфейс обеспечивает доступ к устр --- -[← Оглавление](../README.md) · [← Раздел 20: Балансировщик: аппаратная платформа](20.md) · [Раздел 22: Балансировщик: мониторинг и диагностика →](22.md) +[← Оглавление](../README.md) · [← Раздел 7: Балансировщик: аппаратная платформа](balancer-platform.md) · [Раздел 9: Балансировщик: мониторинг и диагностика →](balancer-monitoring.md) diff --git a/docs/balancer-monitoring.md b/docs/balancer-monitoring.md index 19c360b..43039a9 100644 --- a/docs/balancer-monitoring.md +++ b/docs/balancer-monitoring.md @@ -1,12 +1,12 @@ -# 22. Балансировщик: мониторинг и диагностика +# 9. Балансировщик: мониторинг и диагностика -[← Оглавление](../README.md) · [← Раздел 21: Балансировщик: конфигурация](21.md) +[← Оглавление](../README.md) · [← Раздел 8: Балансировщик: конфигурация](balancer-config.md) --- Балансировщик предоставляет набор команд для мониторинга аппаратного состояния, проверки прошивок, диагностики портов, анализа правил фильтрации и контроля групп балансировки. Все команды мониторинга выполняются в **операционном режиме**. -## 22.1. `show hardware info` — CPU, память, вентиляторы, БП, температура +## 9.1. `show hardware info` — CPU, память, вентиляторы, БП, температура Команда `show hardware info` с различными ключевыми словами отображает состояние аппаратных компонентов балансировщика: @@ -21,9 +21,9 @@ Для быстрой проверки общего состояния платформы удобно использовать `show hardware info all` — команда выводит полную картину по всем аппаратным подсистемам. -> **Практический случай:** именно через мониторинг температурных датчиков была выявлена проблема с зависаниями балансировщиков весной — BMC некорректно считывал показания датчика, ошибочно определял перегрев и выключал микросервер (подробнее — в [разделе 20.4.3](20.md)). +> **Практический случай:** именно через мониторинг температурных датчиков была выявлена проблема с зависаниями балансировщиков весной — BMC некорректно считывал показания датчика, ошибочно определял перегрев и выключал микросервер (подробнее — в [разделе 7.4.3](balancer-platform.md)). -## 22.2. `show mng if` — management-интерфейс +## 9.2. `show mng if` — management-интерфейс Команда `show mng if` отображает текущее состояние management-интерфейса: @@ -34,7 +34,7 @@ Команда полезна для быстрой проверки параметров управления после настройки или перезагрузки устройства. -## 22.3. `show rdp firmware version` — версии прошивок, tries +## 9.3. `show rdp firmware version` — версии прошивок, tries Команда `show rdp firmware version` выводит полную информацию о состоянии прошивок: @@ -63,11 +63,11 @@ В нормальном состоянии **Tries = 0**. Ненулевое значение означает, что балансировщик предпринимал неудачные попытки загрузки с этого раздела. -Если балансировщик **более 3 раз подряд** за ~20 минут не смог загрузиться с определённого раздела, прошивка считается **ненадёжной** и происходит автоматический rollback на другой раздел (подробнее — в [разделе 21.2.1](21.md)). +Если балансировщик **более 3 раз подряд** за ~20 минут не смог загрузиться с определённого раздела, прошивка считается **ненадёжной** и происходит автоматический rollback на другой раздел (подробнее — в [разделе 8.2.1](balancer-config.md)). Для сброса счётчика используется команда `call rdp firmware reset-tries`. -## 22.4. Состояние портов и трансиверов: SFP-информация, DDM, статистика фреймов +## 9.4. Состояние портов и трансиверов: SFP-информация, DDM, статистика фреймов ### Информация о трансиверах @@ -104,7 +104,7 @@ Эта статистика полезна при диагностике проблем с физическим подключением — ошибки на уровне фреймов могут указывать на проблемы с кабелями, трансиверами или несовместимость оборудования. -## 22.5. Статистика правил фильтрации: счётчики пакетов/байт по каждому flow +## 9.5. Статистика правил фильтрации: счётчики пакетов/байт по каждому flow По каждому правилу фильтрации (flow rule) балансировщик ведёт **счётчики пакетов и байт**, прошедших через данное правило: @@ -137,7 +137,7 @@ > **Важно:** после завершения диагностики не забудьте **удалить временное правило** и применить конфигурацию. -## 22.6. Состояние группы балансировки +## 9.6. Состояние группы балансировки Команда для просмотра состояния группы балансировки: @@ -147,7 +147,7 @@ Вывод показывает общее состояние группы и статус каждой filter group внутри неё. -### 22.6.1. Статус filter groups: up/bypass +### 9.6.1. Статус filter groups: up/bypass Каждая filter group (пара портов в сторону фильтра) может находиться в одном из двух состояний: @@ -160,7 +160,7 @@ Переход в `bypass` происходит автоматически при потере заданного количества последовательных keep-alive пакетов (параметр `probes-down-count`, в типовой конфигурации — 5). Обратный переход в `up` также автоматический — при получении достаточного количества ответных keep-alive пакетов. -### 22.6.2. time-on-path — время прохождения keep-alive пакета +### 9.6.2. time-on-path — время прохождения keep-alive пакета Внутри каждой filter group отображается параметр **`time-on-path`** — время прохождения keep-alive пакета через фильтр (отдельно для направлений to-lan и to-wan): @@ -184,7 +184,7 @@ Например, time-on-path может составлять около 27 000 нс (27 мкс); конкретное значение зависит от площадки. -> **Важно:** балансировщик **ничего не знает** о работе DPI на фильтрах. Keep-alive-пакеты проходят через фильтр без обработки движком DPI. Параметр `time-on-path` отражает время прохождения пакета от балансировщика через фильтр и обратно, включая первую проверку («IP-пакет или нет»), которую выполняет процессор фильтра ([раздел 4.6.1](04.md)). +> **Важно:** балансировщик **ничего не знает** о работе DPI на фильтрах. Keep-alive-пакеты проходят через фильтр без обработки движком DPI. Параметр `time-on-path` отражает время прохождения пакета от балансировщика через фильтр и обратно, включая первую проверку («IP-пакет или нет»), которую выполняет процессор фильтра ([раздел 6.6.1](balancer.md)). Если пакеты начинают теряться — time-on-path резко возрастает. После потери **5 последовательных** keep-alive пакетов filter group переводится в состояние `bypass`. @@ -199,7 +199,7 @@ Система мониторинга должна отслеживать загрузку таблиц на фильтрах и сигнализировать о приближении к пороговым значениям **до** того, как начнутся проблемы с keep-alive. -## 22.7. Программный байпас: индивидуально для каждой группы портов +## 9.7. Программный байпас: индивидуально для каждой группы портов Программный bypass на балансировщике может управляться как **автоматически** (по результатам keep-alive — для отдельных filter groups), так и **вручную** — для группы балансировки целиком: @@ -235,7 +235,7 @@ | **Согласование с оператором** | Требуется (работы, окна обслуживания) | **Не требуется** — оператор ничего не замечает | | **Последствия** | Весь трафик не фильтруется | Не фильтруется **только часть** трафика | -> **Примечание:** сравнение приведено для оптического байпаса GL Sun. У байпасов Silicom переключение сегмента в TAP или Active Bypass выполняется без флапа линков и применяется к отдельному каналу, однако оно так же полностью снимает канал с фильтрации — см. [раздел 3.2.6](03.md). +> **Примечание:** сравнение приведено для оптического байпаса GL Sun. У байпасов Silicom переключение сегмента в TAP или Active Bypass выполняется без флапа линков и применяется к отдельному каналу, однако оно так же полностью снимает канал с фильтрации — см. [раздел 5.2.6](bypass.md). > **Опыт эксплуатации:** такое поведение было опробовано при тестировании эшелонированной системы в Сургуте. Вместо переключения трафика на оптическом байпасе (что вызывает флапы линков и недовольство оператора) использовался программный bypass на балансировщике — одной командой трафик уводился с фильтров без каких-либо видимых последствий для оператора. @@ -262,4 +262,4 @@ --- -[← Оглавление](../README.md) · [← Раздел 21: Балансировщик: конфигурация](21.md) · [Раздел 23: Распознавание протоколов (DPI Engine) →](23.md) +[← Оглавление](../README.md) · [← Раздел 8: Балансировщик: конфигурация](balancer-config.md) · [Раздел 10: Фильтр: принцип работы →](filter.md) diff --git a/docs/balancer-platform.md b/docs/balancer-platform.md index 9b7cc93..599f0e2 100644 --- a/docs/balancer-platform.md +++ b/docs/balancer-platform.md @@ -1,12 +1,12 @@ -# 20. Балансировщик: аппаратная платформа +# 7. Балансировщик: аппаратная платформа -[← Оглавление](../README.md) · [← Раздел 19: Фильтр: обновление прошивки](19.md) +[← Оглавление](../README.md) · [← Раздел 6: Балансировщик: принцип работы](balancer.md) --- Балансировщик (EcoFilter Balancer) — устройство, обеспечивающее распределение трафика между фильтрами и их отказоустойчивость. Аппаратная платформа **одинакова** как для EcoFilter Balancer, так и для Eco Highway (эшелонированная система) — различия только в программной части. -## 20.1. Одноюнитовый (32 порта QSFP28) и двухюнитовый (65 портов) +## 7.1. Одноюнитовый (32 порта QSFP28) и двухюнитовый (65 портов) Балансировщик выпускается в двух форм-факторах: @@ -23,7 +23,7 @@ - **Питание** — два блока питания с горячим резервированием (расположены на задней панели); - **Высота** — 1U. -## 20.2. Скорости портов: 10G / 25G / 100G +## 7.2. Скорости портов: 10G / 25G / 100G Порты QSFP28 поддерживают работу на различных скоростях в зависимости от конфигурации и типа установленных трансиверов: @@ -39,7 +39,7 @@ > **Примечание:** management-интерфейс работает **только** на скорости 1 Гбит/с Ethernet. Скорости 10 и 100 Мбит/с не поддерживаются. -## 20.3. Гидры (breakout): один QSFP28 → четыре SFP+ (10G) +## 7.3. Гидры (breakout): один QSFP28 → четыре SFP+ (10G) Для подключения 10-гигабитных интерфейсов используются **гидры** (breakout-кабели) — разветвители, преобразующие один порт QSFP28 в четыре порта SFP+ (10G): @@ -61,7 +61,7 @@ При использовании гидры в одном физическом QSFP28-разъёме появляется **до четырёх** независимых портов по 10 Гбит/с. Каждый из этих портов конфигурируется отдельно с указанием номера линии (lane). -## 20.4. Внутренняя архитектура +## 7.4. Внутренняя архитектура Внутренняя архитектура балансировщика включает несколько ключевых компонентов, связанных между собой: @@ -92,7 +92,7 @@ └──────────────────────────────────────────────────┘ ``` -### 20.4.1. Микросервер (Intel, Linux) — CLI, конфигурация +### 7.4.1. Микросервер (Intel, Linux) — CLI, конфигурация **Микросервер** — основной «мозг» балансировщика, с которым взаимодействует оператор: @@ -105,7 +105,7 @@ Микросервер не обрабатывает трафик напрямую — он только управляет чипом коммутации. -### 20.4.2. Чип Barefoot Tofino — программируемая коммутация +### 7.4.2. Чип Barefoot Tofino — программируемая коммутация **Barefoot Tofino** — высокопроизводительный программируемый чип, обеспечивающий коммутацию трафика на скорости провода: @@ -116,7 +116,7 @@ Все операции с трафиком (балансировка между фильтрами, программный байпас, фильтрация по flow rules) выполняются **внутри чипа Tofino** без участия микросервера. -### 20.4.3. BMC — управление аппаратной частью, сенсоры, блоки питания +### 7.4.3. BMC — управление аппаратной частью, сенсоры, блоки питания **BMC** (Baseboard Management Controller) — модуль управления аппаратной платформой: @@ -132,7 +132,7 @@ - Через **внешнюю консоль** (при определённых настройках Console MUX); - Через **Management Ethernet** (один порт обеспечивает доступ и к микросерверу, и к BMC). -### 20.4.4. Ethernet switch (5-портовый) — доступ к микросерверу и BMC +### 7.4.4. Ethernet switch (5-портовый) — доступ к микросерверу и BMC Внутри балансировщика расположен **5-портовый Ethernet-коммутатор**, к которому подключены: @@ -142,7 +142,7 @@ Благодаря этому коммутатору **один внешний Ethernet-порт** обеспечивает доступ одновременно к микросерверу и BMC — каждый на своём IP-адресе. -### 20.4.5. Console MUX — переключение консоли между компонентами +### 7.4.5. Console MUX — переключение консоли между компонентами **Console MUX** — мультиплексор консольного порта, позволяющий переключать физическую консоль между различными внутренними компонентами: @@ -151,7 +151,7 @@ > **Внимание:** скорость консольного порта может различаться в зависимости от того, к какому компоненту вы подключены. Если подключение к BMC — может быть одна скорость, к микросерверу — другая. На новых устройствах иногда приходится **подбирать скорость** консольного соединения. -## 20.5. Передняя панель: Console, Management Ethernet, USB +## 7.5. Передняя панель: Console, Management Ethernet, USB На передней панели балансировщика расположены: @@ -172,4 +172,4 @@ --- -[← Оглавление](../README.md) · [← Раздел 19: Фильтр: обновление прошивки](19.md) · [Раздел 21: Балансировщик: конфигурация →](21.md) +[← Оглавление](../README.md) · [← Раздел 6: Балансировщик: принцип работы](balancer.md) · [Раздел 8: Балансировщик: конфигурация →](balancer-config.md) diff --git a/docs/balancer.md b/docs/balancer.md index 329dfb8..03c0615 100644 --- a/docs/balancer.md +++ b/docs/balancer.md @@ -1,28 +1,28 @@ -# 4. Балансировщик (EcoFilter Balancer) +# 6. Балансировщик: принцип работы -[← Оглавление](../README.md) · [← Раздел 3: Байпас](03.md) +[← Оглавление](../README.md) · [← Раздел 5: Байпас](bypass.md) --- -## 4.1. Назначение: распределение трафика по фильтрам +## 6.1. Назначение: распределение трафика по фильтрам Балансировщик (EcoFilter Balancer) — это **высокопроизводительный программируемый коммутатор**. Его основная задача — принимать трафик операторских каналов от байпасов и **равномерно распределять** его по подключённым фильтрам, а внутри каждого фильтра — по его процессорным ядрам. Для сети оператора балансировщик, как и остальное оборудование ТСПУ, прозрачен на уровне L2. Помимо балансировки, балансировщик выполняет следующие функции: - **согласование скоростей** — операторские каналы (как правило, 10G и 100G) распределяются по портам фильтров, которые в проекте в большинстве случаев подключаются интерфейсами 10G. Число фильтров определяется только объёмом трафика, поэтому число портов в сторону фильтров не совпадает с числом операторских каналов; -- **исключение служебного трафика** — возврат оператору без обработки трафика, который не нужно отправлять на фильтры (правила с действием bypass, [раздел 4.4](#44-фильтры-на-балансировщике-flow-rules)); +- **исключение служебного трафика** — возврат оператору без обработки трафика, который не нужно отправлять на фильтры (правила с действием bypass, [раздел 6.4](#64-фильтры-на-балансировщике-flow-rules)); - **контроль доступности фильтров** — отправка keep-alive-пакетов через каждую пару портов в сторону фильтров; - **программный байпас** — вывод из обработки отдельной пары портов или всех фильтров сразу без флапа линков у оператора; -- **прозрачный пропуск heartbeat-пакетов** байпаса Silicom между парными портами линка ([раздел 3.4](03.md)). +- **прозрачный пропуск heartbeat-пакетов** байпаса Silicom между парными портами линка ([раздел 5.4](bypass.md)). -Балансировщик работает только с заголовками пакетов уровней L2–L4 и **ничего не знает** о том, что происходит на фильтрах: распознавание протоколов, DPI-листы и блокировки его не касаются. По документации производителя он поддерживает также прозрачный режим с зеркалированием: трафик пропускается мимо фильтров, а на фильтры отправляется только копия. В проекте фильтры в режиме копии трафика не используются; для вывода фильтров из обработки служит программный байпас ([раздел 4.6.2](#462-программный-байпас-при-потере-группы-портов)). +Балансировщик работает только с заголовками пакетов уровней L2–L4 и **ничего не знает** о том, что происходит на фильтрах: распознавание протоколов, DPI-листы и блокировки его не касаются. По документации производителя он поддерживает также прозрачный режим с зеркалированием: трафик пропускается мимо фильтров, а на фильтры отправляется только копия. В проекте фильтры в режиме копии трафика не используются; для вывода фильтров из обработки служит программный байпас ([раздел 6.6.2](#662-программный-байпас-при-потере-группы-портов)). -В ТСПУ тип А используется балансировщик **EcoFilter Balancer**; в эшелонированной системе (ТСПУ тип Б) на той же аппаратной платформе работает балансировщик с другим программным обеспечением — **Eco Highway** ([раздел 7](07.md)). Количество балансировщиков на площадке определяется количеством каналов связи оператора и объёмом трафика. В простейшей конфигурации — один-два канала и один фильтр — балансировщик не нужен, и байпас подключается к фильтру напрямую ([раздел 2.3](02.md)). +В ТСПУ тип А используется балансировщик **EcoFilter Balancer**; в эшелонированной системе (ТСПУ тип Б) на той же аппаратной платформе работает балансировщик с другим программным обеспечением — **Eco Highway** ([раздел 4](echelon.md)). Количество балансировщиков на площадке определяется количеством каналов связи оператора и объёмом трафика. В простейшей конфигурации — один-два канала и один фильтр — балансировщик не нужен, и байпас подключается к фильтру напрямую ([раздел 2.3](traffic-flow.md)). -С завода балансировщик поставляется с заводской (factory) прошивкой ограниченной функциональности и базовой версией рабочей прошивки, но **без рабочей конфигурации**. После установки нужной версии прошивки и настройки сегмента управления в конфигурации нет ни линков, ни групп балансировки, ни правил, а все используемые порты нужно настроить самостоятельно — всё это создаётся при проектировании конкретного узла ([раздел 21](21.md)). +С завода балансировщик поставляется с заводской (factory) прошивкой ограниченной функциональности и базовой версией рабочей прошивки, но **без рабочей конфигурации**. После установки нужной версии прошивки и настройки сегмента управления в конфигурации нет ни линков, ни групп балансировки, ни правил, а все используемые порты нужно настроить самостоятельно — всё это создаётся при проектировании конкретного узла ([раздел 8](balancer-config.md)). -## 4.2. Аппаратная платформа: 32-портовый, 1U, пропускная способность 3.2 Тбит/с +## 6.2. Аппаратная платформа: 32-портовый, 1U, пропускная способность 3.2 Тбит/с | Параметр | Значение | | -------------------------- | --------------------------------------------------------------------------------- | @@ -37,9 +37,9 @@ Каждый порт QSFP28 состоит из четырёх линий (lane) по 25 Гбит/с. На скорости 100G задействованы все четыре линии; если настроить каждую линию отдельно на 10G, один физический порт даёт до четырёх портов 10G. Для их подключения используются **«гидры»** — breakout-кабели QSFP → 4 × SFP+, оптические или DAC. -Внутри чипа Tofino — два независимых конвейера (pipeline) со своими ресурсами, каждый обслуживает свою половину портов. На EcoFilter Balancer оба конвейера настроены одинаково, поэтому к какому из них относится порт, значения не имеет — в отличие от Eco Highway ([раздел 7.4](07.md)). Подробно аппаратная часть описана в [разделе 20](20.md). +Внутри чипа Tofino — два независимых конвейера (pipeline) со своими ресурсами, каждый обслуживает свою половину портов. На EcoFilter Balancer оба конвейера настроены одинаково, поэтому к какому из них относится порт, значения не имеет — в отличие от Eco Highway ([раздел 4.4](echelon.md)). Подробно аппаратная часть описана в [разделе 7](balancer-platform.md). -## 4.3. Организация портов: пары LAN/WAN, линки +## 6.3. Организация портов: пары LAN/WAN, линки Все порты балансировщика логически делятся на две группы: @@ -73,32 +73,32 @@ Фильтр 1: te2/te1 Фильтр 1: te4/te3 ``` -### 4.3.1. Принцип чётных/нечётных портов +### 6.3.1. Принцип чётных/нечётных портов -На фильтрах разделение портов жёсткое: в каждой паре чётный порт — LAN, нечётный — WAN ([раздел 11.5](11.md)). На балансировщике жёсткой привязки нет — порт становится LAN или WAN только при настройке линка или filter group. Для однозначности при проектировании принят тот же принцип, что и на фильтрах: +На фильтрах разделение портов жёсткое: в каждой паре чётный порт — LAN, нечётный — WAN ([раздел 11.5](filter-platform.md)). На балансировщике жёсткой привязки нет — порт становится LAN или WAN только при настройке линка или filter group. Для однозначности при проектировании принят тот же принцип, что и на фильтрах: - **чётные** порты — **LAN** (в сторону абонентов); - **нечётные** порты — **WAN** (в сторону интернета). -Для 10-гигабитных портов чётность определяется по номеру линии: p4-2 — LAN, парный ему p4-1 — WAN. У 100-гигабитных портов номера линии нет, и определяющим является номер порта: p10 — LAN, p9 — WAN. Принцип действует как для портов в сторону операторского оборудования, так и для портов в сторону фильтров. На балансировщике Eco Highway он не соблюдается: там LAN- и WAN-порты разнесены по разным конвейерам ([раздел 7.4.1](07.md)). +Для 10-гигабитных портов чётность определяется по номеру линии: p4-2 — LAN, парный ему p4-1 — WAN. У 100-гигабитных портов номера линии нет, и определяющим является номер порта: p10 — LAN, p9 — WAN. Принцип действует как для портов в сторону операторского оборудования, так и для портов в сторону фильтров. На балансировщике Eco Highway он не соблюдается: там LAN- и WAN-порты разнесены по разным конвейерам ([раздел 4.4.1](echelon.md)). -### 4.3.2. Жёсткая привязка: трафик возвращается в тот же линк +### 6.3.2. Жёсткая привязка: трафик возвращается в тот же линк Пакет, вошедший в LAN-порт линка, после обработки выходит только через WAN-порт того же линка, и наоборот: вошедший через p4-2 выйдет только через p4-1, вошедший через p4-1 — только через p4-2. Ни в какой другой порт пакет попасть не может — это сделано специально, чтобы пакеты разных линков никогда не смешивались. -Это правило обеспечивает **прозрачность ТСПУ** для сети оператора: если оператор отправил пакет в конкретный канал, ТСПУ вернёт его в продолжение того же канала, независимо от того, каким фильтром пакет был обработан. Механизм — служебный 4-байтный заголовок, по которому балансировщик узнаёт исходный линк вернувшегося от фильтра пакета ([раздел 4.5.3](#453-дополнительный-4-байтный-заголовок-для-фильтров)). +Это правило обеспечивает **прозрачность ТСПУ** для сети оператора: если оператор отправил пакет в конкретный канал, ТСПУ вернёт его в продолжение того же канала, независимо от того, каким фильтром пакет был обработан. Механизм — служебный 4-байтный заголовок, по которому балансировщик узнаёт исходный линк вернувшегося от фильтра пакета ([раздел 6.5.3](#653-дополнительный-4-байтный-заголовок-для-фильтров)). -### 4.3.3. Асимметричный трафик: все линки — на один балансировщик +### 6.3.3. Асимметричный трафик: все линки — на один балансировщик Оба направления каждого потока должны попадать на один и тот же фильтр и одно его ядро; проще всего это обеспечить, когда оба направления проходят через один и тот же балансировщик. Поэтому на один балансировщик заводятся все линки, по которым могут идти прямое и обратное направления одного и того же трафика. В частности, все каналы одного агрегированного линка (LAG) оператора приходят на один балансировщик: оборудование оператора с каждой стороны распределяет потоки по каналам агрегата своим хэшем, и прямое и обратное направления одной сессии могут оказаться в разных каналах. Поэтому при проектировании узла у оператора выясняют, какие каналы входят в агрегаты. -Речь идёт о случае, когда оба направления проходят через ТСПУ, но по разным каналам. Если одно из направлений вообще минует ТСПУ, тип А такой трафик обработать не может — для этого предназначена эшелонированная система ([раздел 7.2](07.md)). +Речь идёт о случае, когда оба направления проходят через ТСПУ, но по разным каналам. Если одно из направлений вообще минует ТСПУ, тип А такой трафик обработать не может — для этого предназначена эшелонированная система ([раздел 4.2](echelon.md)). -Если одного балансировщика недостаточно, применяется перекрёстная (кроссированная) схема с несколькими балансировщиками, к которым подключены одни и те же фильтры. Чтобы поток попадал на один и тот же фильтр и одно ядро, на какой бы балансировщик он ни пришёл, группы балансировки на всех балансировщиках такой схемы настраиваются одинаково — те же фильтры в том же порядке, то же число ядер; в новых версиях ПО для сверки предусмотрена контрольная сумма конфигурации группы балансировки (`show ecofilter-balancer balancing-config-hash`). В эшелонированной системе такая схема может не подойти, поскольку фильтры там подключаются по схеме on-a-stick ([раздел 7.3.3](07.md)). +Если одного балансировщика недостаточно, применяется перекрёстная (кроссированная) схема с несколькими балансировщиками, к которым подключены одни и те же фильтры. Чтобы поток попадал на один и тот же фильтр и одно ядро, на какой бы балансировщик он ни пришёл, группы балансировки на всех балансировщиках такой схемы настраиваются одинаково — те же фильтры в том же порядке, то же число ядер; в новых версиях ПО для сверки предусмотрена контрольная сумма конфигурации группы балансировки (`show ecofilter-balancer balancing-config-hash`). В эшелонированной системе такая схема может не подойти, поскольку фильтры там подключаются по схеме on-a-stick ([раздел 4.3.3](echelon.md)). -## 4.4. Фильтры на балансировщике (Flow rules) +## 6.4. Фильтры на балансировщике (Flow rules) -> **Примечание о версиях ПО.** Имена параметров в этой главе — группы балансировки (`balance-groups`) с парами портов `filter-group`, наборы правил `filters` с привязкой `apply-to-links`, действие `balancing-as mag-hash` с `to-balance-group`, параметры `nat-unit-queues` и `rebalance` — относятся к ранней модели конфигурации балансировщика, по которой построен и [раздел 21](21.md). В новых версиях ПО модель другая: группа балансировки задаётся как `ecofilter-balancer ecofilter-unit` с парами портов `pair` и числом ядер `cores`, правила — как `ecofilter-balancer flow` с действиями `bypass` (по умолчанию), `drop` и `to-ecofilter`, а метод хэширования — одним параметром для всего устройства (`ecofilter-balancer balancing-method`). Логика работы при этом та же. +> **Примечание о версиях ПО.** Имена параметров в этой главе — группы балансировки (`balance-groups`) с парами портов `filter-group`, наборы правил `filters` с привязкой `apply-to-links`, действие `balancing-as mag-hash` с `to-balance-group`, параметры `nat-unit-queues` и `rebalance` — относятся к ранней модели конфигурации балансировщика, по которой построен и [раздел 8](balancer-config.md). В новых версиях ПО модель другая: группа балансировки задаётся как `ecofilter-balancer ecofilter-unit` с парами портов `pair` и числом ядер `cores`, правила — как `ecofilter-balancer flow` с действиями `bypass` (по умолчанию), `drop` и `to-ecofilter`, а метод хэширования — одним параметром для всего устройства (`ecofilter-balancer balancing-method`). Логика работы при этом та же. Термин «фильтр» на балансировщике означает не устройство, а **именованный набор правил**, который привязывается к линкам в сторону оператора (параметр `apply-to-links`). Каждое правило (flow) состоит из трёх частей: @@ -106,11 +106,11 @@ - **action** — действие с совпавшим пакетом; - **priority** — приоритет: правила проверяются в порядке приоритета, от высшего к низшему, и срабатывает первое совпавшее. Направление шкалы — больше или меньше число означает более высокий приоритет — в документации производителя описано противоречиво, поэтому его стоит проверять на используемой версии ПО. -Действий в ТСПУ тип А два: отправить трафик на группу балансировки, то есть на фильтры, или вернуть его оператору без обработки (bypass). В документации производителя для новых версий ПО описаны также действие `drop` и блокировка по таблицам, загружаемым с внешнего gRPC-сервера (`external-acl`, действие `block`). В рассматриваемой схеме ТСПУ тип А блокировку выполняют фильтры, а балансировщик трафик не блокирует — в отличие от эшелонированной системы ([раздел 7](07.md)). +Действий в ТСПУ тип А два: отправить трафик на группу балансировки, то есть на фильтры, или вернуть его оператору без обработки (bypass). В документации производителя для новых версий ПО описаны также действие `drop` и блокировка по таблицам, загружаемым с внешнего gRPC-сервера (`external-acl`, действие `block`). В рассматриваемой схеме ТСПУ тип А блокировку выполняют фильтры, а балансировщик трафик не блокирует — в отличие от эшелонированной системы ([раздел 4](echelon.md)). -Правила можно строить двумя способами: перечислить трафик-исключения с действием bypass, а всё остальное отправить на фильтры, — либо, наоборот, перечислить трафик, который нужно отправить на фильтры, а всё остальное вернуть оператору завершающим правилом. Обычно правил на балансировщике ТСПУ тип А немного, они задаются вручную и описывают исключения — например, служебный VLAN возвращается оператору, а весь остальной трафик отправляется на фильтры. На Eco Highway, наоборот, правила загружаются из ЦСУ и исчисляются десятками и сотнями тысяч ([раздел 7.3.1](07.md)). По каждому правилу балансировщик считает пакеты и байты; эта статистика используется при диагностике ([разделы 22.5](22.md) и [24.4](24.md)). +Правила можно строить двумя способами: перечислить трафик-исключения с действием bypass, а всё остальное отправить на фильтры, — либо, наоборот, перечислить трафик, который нужно отправить на фильтры, а всё остальное вернуть оператору завершающим правилом. Обычно правил на балансировщике ТСПУ тип А немного, они задаются вручную и описывают исключения — например, служебный VLAN возвращается оператору, а весь остальной трафик отправляется на фильтры. На Eco Highway, наоборот, правила загружаются из ЦСУ и исчисляются десятками и сотнями тысяч ([раздел 4.3.1](echelon.md)). По каждому правилу балансировщик считает пакеты и байты; эта статистика используется при диагностике ([разделы 9.5](balancer-monitoring.md) и [23.4](troubleshooting.md)). -### 4.4.1. Байпас служебного трафика (BGP, мультикаст, маршрутизация) +### 6.4.1. Байпас служебного трафика (BGP, мультикаст, маршрутизация) Действие **bypass** возвращает совпавший трафик оператору через парный порт линка сразу на входе, не отправляя его на фильтры. Так поступают с трафиком, который не нужно и нежелательно анализировать: @@ -123,11 +123,11 @@ Если правила построены по второму способу, набор завершается правилом с самым низким приоритетом, пустым условием (совпадает всё) и действием bypass: весь трафик, не попавший под предыдущие правила, возвращается оператору без обработки. Тогда на фильтры попадает только трафик, явно отобранный правилами, а всё, что правилами не перечислено, остаётся без фильтрации. -Отбором по VLAN пользуются и при подключении BRAS или CGNAT по схеме on-a-stick: на фильтры отправляют только VLAN одного направления, чтобы каждая сессия обрабатывалась один раз ([раздел 6.4.2](06.md)). +Отбором по VLAN пользуются и при подключении BRAS или CGNAT по схеме on-a-stick: на фильтры отправляют только VLAN одного направления, чтобы каждая сессия обрабатывалась один раз ([раздел 3.4.2](placement.md)). -### 4.4.2. Отправка трафика на группу балансировки +### 6.4.2. Отправка трафика на группу балансировки -Действие балансировки задаётся как `balancing-as mag-hash` — распределение по хэшу от адресов источника, назначения и IP-протокола — вместе с целевой группой (`to-balance-group`): групп балансировки может быть несколько, и правило определяет, в какую из них отправить трафик. В новых версиях ПО этому соответствует действие `to-ecofilter`, а метод хэширования задаётся отдельно для всего устройства ([раздел 4.5.1](#451-хэш-сумма-source-ip--destination-ip--протокол)). +Действие балансировки задаётся как `balancing-as mag-hash` — распределение по хэшу от адресов источника, назначения и IP-протокола — вместе с целевой группой (`to-balance-group`): групп балансировки может быть несколько, и правило определяет, в какую из них отправить трафик. В новых версиях ПО этому соответствует действие `to-ecofilter`, а метод хэширования задаётся отдельно для всего устройства ([раздел 6.5.1](#651-хэш-сумма-source-ip--destination-ip--протокол)). Пример: правило с условием «первый VLAN-тег равен 1» и действием балансировки отправляет трафик VLAN 1 на фильтры, а завершающее правило bypass возвращает оператору всё остальное. @@ -143,11 +143,11 @@ | **MAC-адреса** | MAC-адрес источника и назначения, в том числе с маской | | **Тип кадра** | EtherType (`packet-type`) и поля LLC | -В одном правиле можно комбинировать несколько условий, например VLAN и IPv4-подсеть. Настройка правил описана в [разделе 21.7](21.md). +В одном правиле можно комбинировать несколько условий, например VLAN и IPv4-подсеть. Настройка правил описана в [разделе 8.7](balancer-config.md). -## 4.5. Балансировка трафика +## 6.5. Балансировка трафика -### 4.5.1. Хэш-сумма: source IP + destination IP + протокол +### 6.5.1. Хэш-сумма: source IP + destination IP + протокол Трафик распределяется по filter groups на основе **хэш-суммы** от трёх полей IP-пакета: @@ -157,19 +157,19 @@ В новых версиях ПО метод хэширования задаётся для всего устройства параметром `ecofilter-balancer balancing-method`; описанной схеме соответствует метод `layer-3`, он же используется по умолчанию, а в качестве хэш-функции производитель указывает CRC32. Доступны и другие методы — только по адресу назначения (`dst-ip`) и с добавлением портов TCP/UDP (`layer-4`), — но в ТСПУ используется балансировка по адресам и протоколу. -Для вычисления хэша балансировщик разбирает стек инкапсуляции и добирается до IP-заголовка ([раздел 4.7](#47-работа-с-различными-инкапсуляциями-vlan-mpls)). Если IP-пакет не найден, трафик пропускается прозрачно и на фильтры не отправляется. +Для вычисления хэша балансировщик разбирает стек инкапсуляции и добирается до IP-заголовка ([раздел 6.7](#67-работа-с-различными-инкапсуляциями-vlan-mpls)). Если IP-пакет не найден, трафик пропускается прозрачно и на фильтры не отправляется. Балансировка работает за счёт **огромного количества** разных сочетаний «адрес источника — адрес назначения — протокол», реально встречающихся в операторском трафике: когда таких сочетаний много и ни одно из них не несёт заметной доли трафика, хэш распределяет нагрузку по всем filter groups и ядрам достаточно равномерно. -Обратная сторона: порты TCP/UDP в хэш не входят, поэтому **весь трафик между одной парой адресов по одному протоколу** — сколько бы соединений в нём ни было — попадает на одну пару портов одного фильтра и на одно его ядро. Разбалансировать такой поток невозможно: если, например, 200 Гбит/с идут с одного адреса на один адрес по одному протоколу, весь этот трафик будет направлен в одну пару портов и на одно ядро одного фильтра — и в пару портов 10G он физически не поместится. Это стоит учитывать для адресов, за которыми стоит много абонентов, — например, при установке ТСПУ после CGNAT ([раздел 6.3](06.md)): трафик многих абонентов с одного внешнего адреса к одному и тому же ресурсу (узлу CDN, кэш-серверу, популярному сервису) попадает на одно ядро. +Обратная сторона: порты TCP/UDP в хэш не входят, поэтому **весь трафик между одной парой адресов по одному протоколу** — сколько бы соединений в нём ни было — попадает на одну пару портов одного фильтра и на одно его ядро. Разбалансировать такой поток невозможно: если, например, 200 Гбит/с идут с одного адреса на один адрес по одному протоколу, весь этот трафик будет направлен в одну пару портов и на одно ядро одного фильтра — и в пару портов 10G он физически не поместится. Это стоит учитывать для адресов, за которыми стоит много абонентов, — например, при установке ТСПУ после CGNAT ([раздел 3.3](placement.md)): трафик многих абонентов с одного внешнего адреса к одному и тому же ресурсу (узлу CDN, кэш-серверу, популярному сервису) попадает на одно ядро. -### 4.5.2. Учёт количества ядер фильтров +### 6.5.2. Учёт количества ядер фильтров Параметр **`nat-unit-queues`** задаёт количество ядер на подключённых фильтрах, которые занимаются обработкой трафика. Это значение **всегда равно общему количеству ядер процессора фильтра минус один**: все ядра, кроме одного, отданы процессу EcoNAT, обрабатывающему трафик, а одно ядро сервисное — на нём работают Linux, системные логи и управление. -Параметр **напрямую влияет** на балансировку: он учитывается при вычислении хэша, чтобы трафик равномерно распределялся не только между фильтрами, но и между **ядрами** каждого фильтра. В новых версиях ПО число ядер задаётся в настройках группы балансировки (параметр `cores`, по умолчанию 1 — поэтому значение нужно задавать явно). Настройка — в [разделе 21.5.2](21.md). +Параметр **напрямую влияет** на балансировку: он учитывается при вычислении хэша, чтобы трафик равномерно распределялся не только между фильтрами, но и между **ядрами** каждого фильтра. В новых версиях ПО число ядер задаётся в настройках группы балансировки (параметр `cores`, по умолчанию 1 — поэтому значение нужно задавать явно). Настройка — в [разделе 8.5.2](balancer-config.md). -### 4.5.3. Дополнительный 4-байтный заголовок для фильтров +### 6.5.3. Дополнительный 4-байтный заголовок для фильтров В точке балансировки к пакету добавляется **дополнительный 4-байтный заголовок**. По структуре он похож на VLAN-тег, но VLAN-тегом не является. Заголовок выполняет две функции: @@ -178,11 +178,11 @@ Фильтр возвращает пакет **с тем же 4-байтным заголовком**. Балансировщик считывает заголовок, определяет исходный линк, удаляет заголовок и отправляет пакет обратно оператору. -В эшелонированной системе вместо этого заголовка используется VLAN-тег: балансировщик Eco Highway помечает им трафик, а фильтр после обработки меняет его на другой ([раздел 7.3.3](07.md)). +В эшелонированной системе вместо этого заголовка используется VLAN-тег: балансировщик Eco Highway помечает им трафик, а фильтр после обработки меняет его на другой ([раздел 4.3.3](echelon.md)). -Из-за 4-байтного заголовка кадры на участке между балансировщиком и фильтром на 4 байта длиннее исходных: максимальный кадр оператора вместе с заголовком должен укладываться в MTU портов балансировщика в сторону фильтров и в L2 MTU фильтра, иначе крупные кадры будут отбрасываться. В проекте на портах балансировщика выставляется MTU около 9000 байт (по умолчанию 9000, платформа допускает до 10240), а на фильтрах — L2 MTU 9216 ([раздел 15.2.4](15.md)); если оператор использует кадры крупнее, MTU нужно согласовать при проектировании. +Из-за 4-байтного заголовка кадры на участке между балансировщиком и фильтром на 4 байта длиннее исходных: максимальный кадр оператора вместе с заголовком должен укладываться в MTU портов балансировщика в сторону фильтров и в L2 MTU фильтра, иначе крупные кадры будут отбрасываться. В проекте на портах балансировщика выставляется MTU около 9000 байт (по умолчанию 9000, платформа допускает до 10240), а на фильтрах — L2 MTU 9216 ([раздел 15.2.4](filter-interfaces.md)); если оператор использует кадры крупнее, MTU нужно согласовать при проектировании. -### 4.5.4. Симметричность хэша: одна сессия — один фильтр, одно ядро +### 6.5.4. Симметричность хэша: одна сессия — один фильтр, одно ядро Хэш вычисляется **симметрично**: у обратного пакета (от интернета к абоненту) адреса источника и назначения поменялись местами, но итоговое значение совпадает со значением для прямого пакета. Сама функция CRC32 несимметрична, так что симметрию обеспечивает способ формирования входных данных хэша. @@ -192,26 +192,26 @@ - более того — на одно и то же **ядро** этого фильтра, а если оба направления проходят через один балансировщик, — и на одну и ту же пару портов; - сессия **никогда не распределяется** по разным фильтрам. -Благодаря этому фильтр всегда видит полную картину сессии — и запрос, и ответ, — что необходимо для корректного распознавания трафика и применения политик. Распределение детерминировано, пока состав группы балансировки не меняется ([раздел 4.6.3](#463-перебалансировка-трафика-опционально)). +Благодаря этому фильтр всегда видит полную картину сессии — и запрос, и ответ, — что необходимо для корректного распознавания трафика и применения политик. Распределение детерминировано, пока состав группы балансировки не меняется ([раздел 6.6.3](#663-перебалансировка-трафика-опционально)). -Балансировщик **не ведёт логов** о том, куда отправлен конкретный пакет: балансировка выполняется аппаратно, программируемым чипом, на скорости провода. Чтобы найти, на каком фильтре обслуживается сессия абонента, нужно обойти фильтры площадки — вручную, если их два-три, или простым скриптом, если их много (на некоторых площадках — около полутора десятков); скрипт справляется примерно за десяток секунд ([раздел 24.2](24.md)). +Балансировщик **не ведёт логов** о том, куда отправлен конкретный пакет: балансировка выполняется аппаратно, программируемым чипом, на скорости провода. Чтобы найти, на каком фильтре обслуживается сессия абонента, нужно обойти фильтры площадки — вручную, если их два-три, или простым скриптом, если их много (на некоторых площадках — около полутора десятков); скрипт справляется примерно за десяток секунд ([раздел 23.2](troubleshooting.md)). -## 4.6. Отказоустойчивость +## 6.6. Отказоустойчивость -### 4.6.1. Keep-alive пакеты к фильтрам +### 6.6.1. Keep-alive пакеты к фильтрам -Балансировщик непрерывно проверяет каждую filter group **keep-alive-пакетами**. С байпасами Silicom это второй, независимый от heartbeat байпаса контур контроля: heartbeat байпаса проверяет канал до балансировщика и дальше него не проходит, а keep-alive балансировщика — путь до фильтра и обратно ([раздел 3.4](03.md)). +Балансировщик непрерывно проверяет каждую filter group **keep-alive-пакетами**. С байпасами Silicom это второй, независимый от heartbeat байпаса контур контроля: heartbeat байпаса проверяет канал до балансировщика и дальше него не проходит, а keep-alive балансировщика — путь до фильтра и обратно ([раздел 5.4](bypass.md)). Принцип работы: 1. Балансировщик отправляет keep-alive-пакеты в оба порта filter group — в **LAN-порт** и в **WAN-порт**; 2. Пакет проходит через фильтр: keep-alive — служебный не-IP-пакет, и фильтр передаёт его в парный порт сразу, на первой же проверке («IP-пакет или нет»); 3. Пакет возвращается на балансировщик через парный порт той же filter group; -4. Балансировщик фиксирует время прохождения — `time-on-path`, в наносекундах, отдельно для каждого направления (в ранних версиях ПО — `to-lan` и `to-wan` в состоянии filter group, в новых — по портам в выводе `show liveness profile-status`). Например, 27 000 нс, то есть 27 мкс ([раздел 22.6.2](22.md)). +4. Балансировщик фиксирует время прохождения — `time-on-path`, в наносекундах, отдельно для каждого направления (в ранних версиях ПО — `to-lan` и `to-wan` в состоянии filter group, в новых — по портам в выводе `show liveness profile-status`). Например, 27 000 нс, то есть 27 мкс ([раздел 9.6.2](balancer-monitoring.md)). На фильтре принятые keep-alive-пакеты учитываются счётчиком `cr_pass_ecobalancer_keepalive` — по нему можно убедиться, что пакеты балансировщика до фильтра доходят. -Keep-alive проверяют не только физический канал, но и то, что фильтр продолжает обрабатывать трафик: даже первую проверку («IP-пакет или нет») выполняет процессор фильтра, поэтому если фильтр завис или перегружен настолько, что не пропускает пакеты, keep-alive не вернётся. Оценивать загрузку фильтра — не основная задача keep-alive, однако сильно перегруженный фильтр — например, при загрузке таблиц сессий заметно выше рекомендованных 20 % — теоретически может начать терять и их ([раздел 22.6](22.md)). +Keep-alive проверяют не только физический канал, но и то, что фильтр продолжает обрабатывать трафик: даже первую проверку («IP-пакет или нет») выполняет процессор фильтра, поэтому если фильтр завис или перегружен настолько, что не пропускает пакеты, keep-alive не вернётся. Оценивать загрузку фильтра — не основная задача keep-alive, однако сильно перегруженный фильтр — например, при загрузке таблиц сессий заметно выше рекомендованных 20 % — теоретически может начать терять и их ([раздел 9.6](balancer-monitoring.md)). Параметры проверки задаются в **профиле Keep-Alive** (liveness profile), который привязывается к группе балансировки: @@ -229,9 +229,9 @@ Keep-alive проверяют не только физический канал, Когда число активных пар в группе балансировки опускается ниже `active-pairs`, неактивной считается вся группа: её состояние становится bypass, и весь её трафик возвращается оператору без обработки. -В пилотном проекте на Урале значение `active-pairs` было равно общему числу пар в сторону фильтров, поэтому проблема с одним-единственным интерфейсом переводила всю группу балансировки в неактивное состояние. Балансировщик прекращал отправку heartbeat-пакетов на оптический байпас GL Sun, и вся площадка уходила в аппаратный байпас с флапом линков у оператора ([раздел 3.3.1](03.md)). Такое значение не обязательно — порог можно задать гибче. +В пилотном проекте на Урале значение `active-pairs` было равно общему числу пар в сторону фильтров, поэтому проблема с одним-единственным интерфейсом переводила всю группу балансировки в неактивное состояние. Балансировщик прекращал отправку heartbeat-пакетов на оптический байпас GL Sun, и вся площадка уходила в аппаратный байпас с флапом линков у оператора ([раздел 5.3.1](bypass.md)). Такое значение не обязательно — порог можно задать гибче. -### 4.6.2. Программный байпас при потере группы портов +### 6.6.2. Программный байпас при потере группы портов При потере keep-alive для конкретной filter group балансировщик переводит эту пару портов в **программный байпас**: трафик, который по хэшу приходится на неё, не отправляется на фильтр, а сразу перекладывается с входного порта линка на парный и возвращается оператору. @@ -243,25 +243,25 @@ Keep-alive проверяют не только физический канал, - когда keep-alive снова начинают проходить, пара **автоматически возвращается** в работу (если перебалансировка выключена); - о переключении балансировщик пишет в журнал. В стандартный набор SNMP-трапов (перезагрузка, авторизация, состояние физических портов, блоки питания) такое событие не входит; в новых версиях ПО трап на изменение состояния можно настроить отдельно (условие `xpath`). Так система мониторинга узнаёт о проблеме, и её можно устранить. -Это значительное улучшение по сравнению с пилотным проектом на Урале, где потеря хотя бы одного интерфейса переводила **всю площадку** в аппаратный байпас с флапом линков у оператора ([раздел 4.6.1](#461-keep-alive-пакеты-к-фильтрам)), а возврат в работу требовал повторного флапа. +Это значительное улучшение по сравнению с пилотным проектом на Урале, где потеря хотя бы одного интерфейса переводила **всю площадку** в аппаратный байпас с флапом линков у оператора ([раздел 6.6.1](#661-keep-alive-пакеты-к-фильтрам)), а возврат в работу требовал повторного флапа. -Программный байпас можно включить и **вручную** — для диагностики или на время технических работ. Вручную переключается группа балансировки целиком: в новых версиях ПО это команда `call ecofilter-balancer set-bypass-ecofilter-unit` с режимами auto (штатная работа: трафик идёт на фильтры, пока группа активна), bypass (весь трафик группы идёт мимо фильтров) и primary (трафик принудительно направляется на фильтры) ([раздел 22.7](22.md)); команды ручного переключения перенесены в EcoFilter Balancer из программного байпаса Eco Highway. Так можно одной командой исключить ТСПУ из обработки трафика без какого-либо влияния на линки оператора; такой режим применялся при испытаниях эшелонированной системы. +Программный байпас можно включить и **вручную** — для диагностики или на время технических работ. Вручную переключается группа балансировки целиком: в новых версиях ПО это команда `call ecofilter-balancer set-bypass-ecofilter-unit` с режимами auto (штатная работа: трафик идёт на фильтры, пока группа активна), bypass (весь трафик группы идёт мимо фильтров) и primary (трафик принудительно направляется на фильтры) ([раздел 9.7](balancer-monitoring.md)); команды ручного переключения перенесены в EcoFilter Balancer из программного байпаса Eco Highway. Так можно одной командой исключить ТСПУ из обработки трафика без какого-либо влияния на линки оператора; такой режим применялся при испытаниях эшелонированной системы. -Если фильтр перегружен и теряет keep-alive, filter group может периодически переключаться между работой и программным байпасом. Физических флапов у оператора это не вызывает, но при каждом переключении теряется небольшое количество пакетов ([раздел 22.6](22.md)). Чтобы перегрузку заметить раньше, система мониторинга должна отслеживать загрузку таблиц на фильтрах и срабатывать на превышение оптимального значения. +Если фильтр перегружен и теряет keep-alive, filter group может периодически переключаться между работой и программным байпасом. Физических флапов у оператора это не вызывает, но при каждом переключении теряется небольшое количество пакетов ([раздел 9.6](balancer-monitoring.md)). Чтобы перегрузку заметить раньше, система мониторинга должна отслеживать загрузку таблиц на фильтрах и срабатывать на превышение оптимального значения. -### 4.6.3. Перебалансировка трафика (опционально) +### 6.6.3. Перебалансировка трафика (опционально) Альтернатива программному байпасу — **перебалансировка** (параметр группы балансировки `rebalance`): трафик пропавшей filter group перераспределяется по оставшимся рабочим парам портов. В примерах конфигурации перебалансировка включена, но в проекте её планируется **выключить**, поскольку: - перебалансировка занимает время и вычислительные ресурсы; - хэш пересчитывается для всех сессий, и сессии могут перейти на другие пары портов и другие фильтры; -- новый фильтр видит такие сессии «с середины», без начального обмена, а контекст анализа на прежнем фильтре теряется; чтобы такие сессии вообще заводились в обработку, на фильтрах должен быть включён приём TCP-сессий без SYN ([раздел 15.2.6](15.md)). +- новый фильтр видит такие сессии «с середины», без начального обмена, а контекст анализа на прежнем фильтре теряется; чтобы такие сессии вообще заводились в обработку, на фильтрах должен быть включён приём TCP-сессий без SYN ([раздел 15.2.6](filter-interfaces.md)). -Производитель описывает этот режим как резервирование N+X: неисправный фильтр исключается из группы балансировки, его потоки перераспределяются между исправными, а при выходе из строя всех фильтров срабатывает режим bypass. В проекте резервирование фильтров по схеме N+1 не предусмотрено: число фильтров рассчитывается так, чтобы пропустить трафик оператора в худшем сценарии; допустим ли при этом выход из строя одного фильтра, определяется расчётом мощностей конкретной площадки ([раздел 1.4](01.md)). +Производитель описывает этот режим как резервирование N+X: неисправный фильтр исключается из группы балансировки, его потоки перераспределяются между исправными, а при выходе из строя всех фильтров срабатывает режим bypass. В проекте резервирование фильтров по схеме N+1 не предусмотрено: число фильтров рассчитывается так, чтобы пропустить трафик оператора в худшем сценарии; допустим ли при этом выход из строя одного фильтра, определяется расчётом мощностей конкретной площадки ([раздел 1.4](overview.md)). Рекомендуемый подход для федерального проекта — программный байпас на уровне отдельной filter group без перебалансировки. Часть трафика временно не фильтруется, но это меньшее зло, чем флап линков оператора или массовый переезд сессий. -## 4.7. Работа с различными инкапсуляциями (VLAN, MPLS) +## 6.7. Работа с различными инкапсуляциями (VLAN, MPLS) Балансировщик **не снимает и не модифицирует** теги, метки и другие заголовки инкапсуляции — он только читает их, чтобы добраться до IP-заголовка. По документации производителя балансировщик разбирает: @@ -272,15 +272,15 @@ Keep-alive проверяют не только физический канал, и находит в них пакеты IPv4 и IPv6. -Заголовки инкапсуляции можно использовать в условиях правил: значения VLAN-тегов и их число, число MPLS-меток ([раздел 4.4.2](#442-отправка-трафика-на-группу-балансировки)). Отбора по значениям MPLS-меток среди условий нет, да он и не был бы надёжным: значения меток на линке назначает соседний маршрутизатор оператора (при LDP и RSVP-TE — динамически), и они могут меняться при перестроении LSP. +Заголовки инкапсуляции можно использовать в условиях правил: значения VLAN-тегов и их число, число MPLS-меток ([раздел 6.4.2](#642-отправка-трафика-на-группу-балансировки)). Отбора по значениям MPLS-меток среди условий нет, да он и не был бы надёжным: значения меток на линке назначает соседний маршрутизатор оператора (при LDP и RSVP-TE — динамически), и они могут меняться при перестроении LSP. -Балансировщик сам разбирает сложную инкапсуляцию — множество тегов и меток — и сам выбирает ядро фильтра, сообщая его в 4-байтном заголовке, поэтому распределять такой трафик по ядрам фильтру не нужно. Это облегчает работу фильтра, у которого ограничений на типы инкапсуляции и их балансировку больше. Разбирать заголовки для анализа фильтр всё равно должен сам и работает только с IP-пакетом; глубина разбора VLAN-тегов на фильтре задаётся параметром VLAN Mode ([раздел 15.2.1](15.md)). +Балансировщик сам разбирает сложную инкапсуляцию — множество тегов и меток — и сам выбирает ядро фильтра, сообщая его в 4-байтном заголовке, поэтому распределять такой трафик по ядрам фильтру не нужно. Это облегчает работу фильтра, у которого ограничений на типы инкапсуляции и их балансировку больше. Разбирать заголовки для анализа фильтр всё равно должен сам и работает только с IP-пакетом; глубина разбора VLAN-тегов на фильтре задаётся параметром VLAN Mode ([раздел 15.2.1](filter-interfaces.md)). На фильтр пакет уходит с исходным стеком заголовков и добавленным 4-байтным заголовком балансировки, а обратно оператору — с тем же стеком, с каким пришёл. Кадры, в которых IP-пакет не найден, на фильтры не отправляются и прозрачно передаются в парный порт линка. Heartbeat-пакеты байпаса Silicom также до фильтров не доходят — балансировщик передаёт их между парными портами. -## 4.8. Обработка HTTP-редиректов и TCP Reset через фильтры +## 6.8. Обработка HTTP-редиректов и TCP Reset через фильтры -При блокировке ресурса фильтр отправляет абоненту **HTTP-редирект** (перенаправление на страницу-заглушку; по документации производителя — ответ «307 Temporary Redirect») для HTTP или **TCP Reset** для HTTPS: подменить содержимое зашифрованного соединения невозможно, а сам ресурс определяется по SNI в ClientHello ([раздел 17.5.3](17.md)). Для трафика без MPLS-меток фильтр формирует такой пакет сам. +При блокировке ресурса фильтр отправляет абоненту **HTTP-редирект** (перенаправление на страницу-заглушку; по документации производителя — ответ «307 Temporary Redirect») для HTTP или **TCP Reset** для HTTPS: подменить содержимое зашифрованного соединения невозможно, а сам ресурс определяется по SNI в ClientHello ([раздел 17.5.3](filter-dpi.md)). Для трафика без MPLS-меток фильтр формирует такой пакет сам. С MPLS-трафиком так не получается. MPLS-путь однонаправлен: метки, с которыми пакет абонента пришёл на фильтр, действительны только для направления в сторону интернета, а стек меток обратного направления фильтру неизвестен — собранный им самим пакет оборудование оператора отбросит или доставит не туда. Поэтому для трафика с MPLS-метками используется другая логика: @@ -289,8 +289,8 @@ Keep-alive проверяют не только физический канал, 3. Обратный пакет приходит уже с правильными метками обратного направления, и фильтр **подменяет** его содержимое на HTTP-редирект или TCP Reset, сохраняя метки; 4. Балансировщик по 4-байтному заголовку возвращает модифицированный пакет в тот же линк, и пакет доходит до абонента с корректной инкапсуляцией. -Роль балансировщика здесь двоякая. Разбирая стек меток и вычисляя симметричный хэш по IP-адресам под ними, он приводит ответ сервера на тот же фильтр и то же ядро, которые обработали запрос абонента, хотя метки у ответа другие. А при возврате он не трогает метки и отправляет пакет строго в исходный линк, поэтому подменённый ответ проходит ровно тем же путём, что и настоящий ответ сервера. Решение о блокировке и отправке редиректа или Reset принимает фильтр ([раздел 5.1.5](05.md)). +Роль балансировщика здесь двоякая. Разбирая стек меток и вычисляя симметричный хэш по IP-адресам под ними, он приводит ответ сервера на тот же фильтр и то же ядро, которые обработали запрос абонента, хотя метки у ответа другие. А при возврате он не трогает метки и отправляет пакет строго в исходный линк, поэтому подменённый ответ проходит ровно тем же путём, что и настоящий ответ сервера. Решение о блокировке и отправке редиректа или Reset принимает фильтр ([раздел 10.1.5](filter.md)). --- -[← Оглавление](../README.md) · [← Раздел 3: Байпас](03.md) · [Раздел 5: Фильтр →](05.md) +[← Оглавление](../README.md) · [← Раздел 5: Байпас](bypass.md) · [Раздел 7: Балансировщик: аппаратная платформа →](balancer-platform.md) diff --git a/docs/bypass.md b/docs/bypass.md index 66902e4..ad8745a 100644 --- a/docs/bypass.md +++ b/docs/bypass.md @@ -1,31 +1,31 @@ -# 3. Байпас (Bypass) +# 5. Байпас (Bypass) -[← Оглавление](../README.md) · [← Раздел 2: Прохождение трафика через ТСПУ](02.md) +[← Оглавление](../README.md) · [← Раздел 4: Эшелонированная система](echelon.md) --- -## 3.1. Назначение и роль байпаса в ТСПУ +## 5.1. Назначение и роль байпаса в ТСПУ Байпас — это устройство, обеспечивающее **физическую защиту каналов связи оператора** при установке ТСПУ. Каналы связи оператора физически разрываются и заводятся на байпас, который в штатном режиме прозрачно пропускает трафик дальше — в сторону балансировщика и фильтров. -Основная задача байпаса — гарантировать, что связность сети оператора не будет нарушена при тех авариях, которые байпас способен обнаружить: потеря пути через ТСПУ (по heartbeat-пакетам), пропадание линка на портах Mon, зависание подключённого inline-устройства и потеря питания. В такой ситуации байпас замыкает каналы оператора напрямую, минуя остальное оборудование ТСПУ; это последнее средство сохранить трафик оператора. При наличии балансировщика отказ отдельных фильтров байпас не отслеживает — его отрабатывает балансировщик программным байпасом группы портов ([раздел 4.6](04.md)); в схеме без балансировщика ([раздел 2.3](02.md)) контур heartbeat замыкается на самом фильтре, поэтому отказ или зависание фильтра байпас видит и замыкает канал. +Основная задача байпаса — гарантировать, что связность сети оператора не будет нарушена при тех авариях, которые байпас способен обнаружить: потеря пути через ТСПУ (по heartbeat-пакетам), пропадание линка на портах Mon, зависание подключённого inline-устройства и потеря питания. В такой ситуации байпас замыкает каналы оператора напрямую, минуя остальное оборудование ТСПУ; это последнее средство сохранить трафик оператора. При наличии балансировщика отказ отдельных фильтров байпас не отслеживает — его отрабатывает балансировщик программным байпасом группы портов ([раздел 6.6](balancer.md)); в схеме без балансировщика ([раздел 2.3](traffic-flow.md)) контур heartbeat замыкается на самом фильтре, поэтому отказ или зависание фильтра байпас видит и замыкает канал. -Количество байпасов на площадке определяется **исключительно количеством линков оператора**, в разрыв которых устанавливается ТСПУ: каждый канал занимает на байпасе свою четвёрку портов (сегмент), а одно устройство может обслуживать один или несколько каналов. Скорость байпаса зависит от модели и установленных модулей: как правило, это **10 или 100 Гбит/с**; площадок с гигабитными линками мало. Каждый байпас имеет management-интерфейс в сегменте управления площадки — под байпасы отведены первые 128 адресов management-подсети ([раздел 10.2](10.md)). +Количество байпасов на площадке определяется **исключительно количеством линков оператора**, в разрыв которых устанавливается ТСПУ: каждый канал занимает на байпасе свою четвёрку портов (сегмент), а одно устройство может обслуживать один или несколько каналов. Скорость байпаса зависит от модели и установленных модулей: как правило, это **10 или 100 Гбит/с**; площадок с гигабитными линками мало. Каждый байпас имеет management-интерфейс в сегменте управления площадки — под байпасы отведены первые 128 адресов management-подсети ([раздел 20.2](management-segment.md)). Термин «байпас» в документации ТСПУ используется в трёх значениях, которые важно различать: - **аппаратный байпас** — само устройство (Silicom, GL Sun) и его режимы, физически замыкающие канал оператора; предмет этого раздела; -- **программный байпас** балансировщика — вывод из обработки отдельной группы портов в сторону фильтра при потере keep-alive или вручную, без участия аппаратного байпаса и без флапа линков у оператора ([раздел 4.6](04.md), [22.7](22.md)); -- **действие bypass** в правилах балансировщика — возврат определённого трафика оператору без анализа ([раздел 4.4](04.md), [21.7](21.md)). +- **программный байпас** балансировщика — вывод из обработки отдельной группы портов в сторону фильтра при потере keep-alive или вручную, без участия аппаратного байпаса и без флапа линков у оператора ([раздел 6.6](balancer.md), [9.7](balancer-monitoring.md)); +- **действие bypass** в правилах балансировщика — возврат определённого трафика оператору без анализа ([раздел 6.4](balancer.md), [8.7](balancer-config.md)). -Ниже описано распределение оборудования на момент развёртывания федерального проекта; о более поздних поставках — см. [раздел 3.6](#36-развитие-отечественные-байпасы). В проекте АСБИ используются два типа аппаратных байпасов: +Ниже описано распределение оборудования на момент развёртывания федерального проекта; о более поздних поставках — см. [раздел 5.6](#56-развитие-отечественные-байпасы). В проекте АСБИ используются два типа аппаратных байпасов: | Проект | Производитель | Особенности | | ------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Федеральный** | Silicom | Активное устройство с режимами Inline, TAP, Active Bypass и Passive Bypass; переключение между первыми тремя без флапа линков; собственные heartbeat-пакеты | | **Пилотный (Урал)** | GL Sun | Оптический переключатель: только пропуск трафика или замыкание канала; каждое переключение — флап линков; heartbeat отправляет балансировщик (по TCP) или, на площадках без балансировщика, фильтр | -## 3.2. Байпасы Silicom (федеральный проект) +## 5.2. Байпасы Silicom (федеральный проект) Байпасы Silicom устанавливаются в рамках федерального проекта и обладают полным набором режимов работы, обеспечивающих гибкое управление прохождением трафика. @@ -33,7 +33,7 @@ В терминологии производителя режимы называются Inline (Normal), Bypass, Tap и Linkdrop. Принятые в ТСПУ названия **Active Bypass** и **Passive Bypass** соответствуют двум схемам обхода в архитектуре Silicom Double Bypass: активной (электронной, управляемой программно и по heartbeat) и пассивной (оптической, срабатывающей при пропадании питания или отказе активной электроники). Режим Linkdrop, в котором оба сетевых порта принудительно гасятся, имитируя отключение кабеля, в описанной здесь схеме работы ТСПУ не задействован. -### 3.2.1. Порты: Net0/Net1 (оператор) и Mon0/Mon1 (балансировщик) +### 5.2.1. Порты: Net0/Net1 (оператор) и Mon0/Mon1 (балансировщик) Для каждого канала связи байпас Silicom имеет **четыре порта**: @@ -53,9 +53,9 @@ Линк балансировщика (или пара портов фильтра) ``` -Все соединения двунаправленные: каждая пара Net/Mon — полнодуплексный проходной сегмент. Байпас Silicom — активное устройство: в режимах Inline, TAP и Active Bypass сигнал операторских линков принимается собственной оптикой модуля (порты Net выведены разъёмами MPO/LC), а линки Mon0/Mon1 — отдельные, со сменными трансиверами. Состояние линка между сторонами не транслируется: падение порта балансировщика или отключение патч-корда Mon оператор не увидит как link-down — байпас обнаружит это сам, по пропаданию линка на Mon-порту или по прекращению возврата heartbeat, и переведёт сегмент в режим обхода ([раздел 3.5](#35-автоматическое-переключение-в-tapactive-bypass-при-потере-канала)); падение линка оператора, наоборот, не видно на балансировщике. При диагностике нужно проверять состояние всех четырёх портов сегмента. В описании линка балансировщика рекомендуется указывать, к какому байпасу и какому его сегменту подключён линк ([раздел 21.4](21.md)). +Все соединения двунаправленные: каждая пара Net/Mon — полнодуплексный проходной сегмент. Байпас Silicom — активное устройство: в режимах Inline, TAP и Active Bypass сигнал операторских линков принимается собственной оптикой модуля (порты Net выведены разъёмами MPO/LC), а линки Mon0/Mon1 — отдельные, со сменными трансиверами. Состояние линка между сторонами не транслируется: падение порта балансировщика или отключение патч-корда Mon оператор не увидит как link-down — байпас обнаружит это сам, по пропаданию линка на Mon-порту или по прекращению возврата heartbeat, и переведёт сегмент в режим обхода ([раздел 5.5](#55-автоматическое-переключение-в-tapactive-bypass-при-потере-канала)); падение линка оператора, наоборот, не видно на балансировщике. При диагностике нужно проверять состояние всех четырёх портов сегмента. В описании линка балансировщика рекомендуется указывать, к какому байпасу и какому его сегменту подключён линк ([раздел 8.4](balancer-config.md)). -### 3.2.2. Режим Inline — основной рабочий режим +### 5.2.2. Режим Inline — основной рабочий режим **Inline** — основной рабочий режим байпаса. В этом режиме трафик прозрачно пропускается насквозь от оборудования оператора к балансировщику и обратно: @@ -72,7 +72,7 @@ Весь трафик оператора проходит через ТСПУ и подвергается анализу и фильтрации. Это штатный режим работы при нормальном функционировании всего оборудования. -### 3.2.3. Режим TAP — копирование трафика без влияния на оператора +### 5.2.3. Режим TAP — копирование трафика без влияния на оператора **TAP** — режим зеркалирования (копирования) трафика. В этом режиме: @@ -90,7 +90,7 @@ В режиме TAP система фильтрации получает **полную копию** всего трафика оператора, но **никаким образом не может на него повлиять** — ни заблокировать, ни модифицировать. Это очень удобный **режим отладки**: можно настраивать систему фильтрации и выявлять проблемы при полной гарантии, что операторский трафик не пострадает. -### 3.2.4. Режим Active Bypass — замыкание без копирования +### 5.2.4. Режим Active Bypass — замыкание без копирования **Active Bypass** — режим чистого обхода. Практически идентичен режиму TAP, за исключением того, что **копия трафика в сторону балансировщика не отправляется**: @@ -100,9 +100,9 @@ Mon0 Mon1 ← линки up, heartbeat продолжается ``` -Каналы оператора замыкаются активной электроникой байпаса, ТСПУ полностью исключено из пути прохождения трафика. Порты Mon0/Mon1 при этом остаются включёнными: линки в сторону балансировщика не падают, операторский трафик на них не подаётся, но heartbeat-пакеты продолжают отправляться — благодаря этому байпас обнаруживает восстановление пути через балансировщик и возвращается в Inline. Режим включается программно — по команде или автоматически при потере канала до балансировщика ([раздел 3.5](#35-автоматическое-переключение-в-tapactive-bypass-при-потере-канала)). +Каналы оператора замыкаются активной электроникой байпаса, ТСПУ полностью исключено из пути прохождения трафика. Порты Mon0/Mon1 при этом остаются включёнными: линки в сторону балансировщика не падают, операторский трафик на них не подаётся, но heartbeat-пакеты продолжают отправляться — благодаря этому байпас обнаруживает восстановление пути через балансировщик и возвращается в Inline. Режим включается программно — по команде или автоматически при потере канала до балансировщика ([раздел 5.5](#55-автоматическое-переключение-в-tapactive-bypass-при-потере-канала)). -### 3.2.5. Режим Passive Bypass — аварийное оптическое замыкание канала +### 5.2.5. Режим Passive Bypass — аварийное оптическое замыкание канала **Passive Bypass** — аварийный режим, в который байпас переходит автоматически при **отключении электропитания**, а также при отказе своей активной электроники (её контролирует внутренний сторожевой таймер). Каналы замыкаются на физическом уровне оптическим переключателем, который в обесточенном состоянии соединяет волокна Net0 и Net1 напрямую, минуя приёмопередатчики байпаса: @@ -122,13 +122,13 @@ Оптический бюджет для двух режимов считается по-разному. В режиме Inline каждая сторона оператора линкуется с сетевыми портами байпаса, поэтому бюджет — это своё плечо волокна плюс вносимые потери байпаса (по спецификации Silicom около 1–2 дБ; они присутствуют и в Inline, и в Passive Bypass). В режиме Passive Bypass устройства оператора линкуются напрямую друг с другом, и их трансиверы должны перекрывать сумму обоих плеч волокна плюс те же вносимые потери — это более жёсткое требование, и именно оно закладывается при проектировании стыка. Кроме того, на обеих сторонах канала должны стоять совместимые трансиверы: тип, длина волны, скорость и настройки FEC на 100G. -### 3.2.6. Переключение между режимами и влияние на оператора +### 5.2.6. Переключение между режимами и влияние на оператора Ключевое преимущество байпасов Silicom — переключение между режимами **Inline**, **TAP** и **Active Bypass** выполняется активной электроникой без изменения состояния оптических линков оператора и происходит **безболезненно для оператора связи**: - порты оператора **не флапают** (не падают); - при ручном переключении теряются лишь единичные пакеты — те, которые уже ушли в сторону балансировщика, но не успели вернуться в момент переключения; -- при автоматическом переключении к этому добавляется время обнаружения аварии — окно контроля возврата heartbeat (по умолчанию 20 мс, см. [раздел 3.4](#34-мониторинг-каналов-heartbeat-пакеты-байпаса)), в течение которого трафик канала не проходит; +- при автоматическом переключении к этому добавляется время обнаружения аварии — окно контроля возврата heartbeat (по умолчанию 20 мс, см. [раздел 5.4](#54-мониторинг-каналов-heartbeat-пакеты-байпаса)), в течение которого трафик канала не проходит; - такие перерывы, как правило, **незаметны** ни для оператора, ни для абонентов — пропадание трафика на доли секунды восстанавливается протоколами верхних уровней. Сводная таблица режимов: @@ -140,29 +140,29 @@ | **Active Bypass** | Замкнут напрямую | Нет | up, heartbeat идут | Без флапа | | **Passive Bypass** | Замкнут напрямую | Нет | отключены от канала оператора (при обесточивании — down) | Флапы линков при входе и при возврате в Inline | -## 3.3. Байпасы GL Sun (пилотный проект, Урал) +## 5.3. Байпасы GL Sun (пилотный проект, Урал) Байпасы GL Sun — оптические байпасы (производитель Guilin GLsun, КНР), используемые в рамках **пилотного проекта на Урале**. По сравнению с Silicom они значительно проще и имеют ряд существенных ограничений. -### 3.3.1. Отличие от Silicom: только пассивный байпас +### 5.3.1. Отличие от Silicom: только пассивный байпас Байпас GL Sun — это оптический переключатель без собственных сетевых портов: в устройствах этого класса одно 1U-шасси защищает от одной до четырёх линий, время оптического переключения — единицы миллисекунд (по спецификациям GLSUN менее 8–10 мс), управление — по RS-232 и Ethernet (web-интерфейс и командный протокол поверх TCP). В применённой в пилотном проекте конфигурации байпас поддерживает **только один механизм переключения** — оптическое замыкание канала, эквивалент режима Passive Bypass у Silicom; режимов TAP и Active Bypass с безболезненным переключением у него нет. Фактически GL Sun умеет только: - **пропускать трафик** через себя (аналог Inline); - **замыкать канал** оптически (аналог Passive Bypass) — при пропадании питания, при прекращении heartbeat-пакетов или по команде. -Требования к стыку те же, что и для пассивного обхода Silicom ([раздел 3.2.5](#325-режим-passive-bypass--аварийное-оптическое-замыкание-канала)): совместимые трансиверы с обеих сторон и запас оптического бюджета на вносимые потери переключателя. Для GL Sun это критичнее — прямое замыкание происходит при каждом переключении, а не только в аварии. +Требования к стыку те же, что и для пассивного обхода Silicom ([раздел 5.2.5](#525-режим-passive-bypass--аварийное-оптическое-замыкание-канала)): совместимые трансиверы с обеих сторон и запас оптического бюджета на вносимые потери переключателя. Для GL Sun это критичнее — прямое замыкание происходит при каждом переключении, а не только в аварии. Байпас GL Sun не генерирует heartbeat-пакеты самостоятельно — он работает как сторожевой таймер и лишь ожидает подтверждений от защищаемого устройства. Heartbeat-пакеты отправляет **балансировщик** (или **фильтр**, если балансировщика на площадке нет — на Урале есть несколько таких площадок), работая с байпасом в активном режиме. Обмен идёт по IP (TCP) на адрес байпаса через сеть управления, а не через порты данных, и байпас должен отвечать на эти пакеты; поэтому проверяется работоспособность самого балансировщика и сети управления, а не оптического пути через него: -- на балансировщике задаются IPv4-адрес и порт байпаса, период отправки, группа балансировки, при активном состоянии которой отправляются heartbeat-пакеты, и список линков байпаса, для которых выполняется проверка (это сущности самого байпаса, например 01 и 02); дополнительно задаются тип сервиса и автоматический возврат трафика в основной режим после восстановления группы балансировки — не всегда полезная опция ([раздел 21.8](21.md)); -- на фильтре (площадки без балансировщика) аналогичная секция bypass в конфигурации задаёт IP-адрес байпаса, интервал отправки и список каналов ([раздел 16.7](16.md)). +- на балансировщике задаются IPv4-адрес и порт байпаса, период отправки, группа балансировки, при активном состоянии которой отправляются heartbeat-пакеты, и список линков байпаса, для которых выполняется проверка (это сущности самого байпаса, например 01 и 02); дополнительно задаются тип сервиса и автоматический возврат трафика в основной режим после восстановления группы балансировки — не всегда полезная опция ([раздел 8.8](balancer-config.md)); +- на фильтре (площадки без балансировщика) аналогичная секция bypass в конфигурации задаёт IP-адрес байпаса, интервал отправки и список каналов ([раздел 16.7](filter-acl-pools.md)). -Состояние Bypass Watchdog держится в `active`, пока группа балансировки активна и байпас подтверждает приём. Если группа балансировки перешла в неактивное состояние, балансировщик перестаёт отправлять heartbeat-пакеты, состояние становится `disconnected`, и байпас оптически замыкает контролируемые линии ([раздел 22.7](22.md)). Обратная сторона такой схемы: авария в сегменте управления сама по себе приводит к аппаратному обходу и флапу линков оператора, хотя тракт обработки трафика исправен — это надо учитывать при работах в сети управления площадок с GL Sun. Следствие для пилотного проекта: при потере связи даже с одним фильтром вся площадка переводилась на аппаратный байпас с флапом линков у оператора, а для возврата площадки в работу требовалось заводить работы и повторный флап; в федеральном проекте программно байпасится только затронутая группа портов балансировщика, без переключения аппаратного байпаса ([раздел 4.6](04.md)). +Состояние Bypass Watchdog держится в `active`, пока группа балансировки активна и байпас подтверждает приём. Если группа балансировки перешла в неактивное состояние, балансировщик перестаёт отправлять heartbeat-пакеты, состояние становится `disconnected`, и байпас оптически замыкает контролируемые линии ([раздел 9.7](balancer-monitoring.md)). Обратная сторона такой схемы: авария в сегменте управления сама по себе приводит к аппаратному обходу и флапу линков оператора, хотя тракт обработки трафика исправен — это надо учитывать при работах в сети управления площадок с GL Sun. Следствие для пилотного проекта: при потере связи даже с одним фильтром вся площадка переводилась на аппаратный байпас с флапом линков у оператора, а для возврата площадки в работу требовалось заводить работы и повторный флап; в федеральном проекте программно байпасится только затронутая группа портов балансировщика, без переключения аппаратного байпаса ([раздел 6.6](balancer.md)). В федеральном проекте эта схема **не актуальна**: байпасы Silicom самостоятельно отправляют heartbeat-пакеты и самостоятельно проверяют доступность интерфейсов, поэтому логика работы с ними иная и на балансировщике для них ничего настраивать не нужно. -### 3.3.2. Флап линков при каждом переключении +### 5.3.2. Флап линков при каждом переключении Каждое переключение режима работы байпаса GL Sun — это **флап линков оператора**: оптический переключатель физически меняет пару соединённых трансиверов (оператор ↔ ТСПУ на оператор ↔ оператор), и даже при времени переключения менее 10 мс приёмники на стороне оператора фиксируют потерю и повторное появление сигнала. Оператор видит падение и восстановление интерфейсов, что может приводить к: @@ -170,9 +170,9 @@ - заметному перерыву в прохождении трафика; - необходимости согласовывать возврат площадки в работу как плановые работы — с повторным флапом. -Безфлапового переключения, как у Silicom ([раздел 3.2.6](#326-переключение-между-режимами-и-влияние-на-оператора)), у GL Sun нет. +Безфлапового переключения, как у Silicom ([раздел 5.2.6](#526-переключение-между-режимами-и-влияние-на-оператора)), у GL Sun нет. -## 3.4. Мониторинг каналов: Heartbeat-пакеты байпаса +## 5.4. Мониторинг каналов: Heartbeat-пакеты байпаса Байпас Silicom осуществляет **постоянный мониторинг доступности каналов** в сторону балансировщика с помощью специальных **heartbeat-пакетов**, которые генерирует сам, без участия внешнего программного обеспечения. @@ -199,14 +199,14 @@ По документации Silicom heartbeat-пакеты по умолчанию отправляются каждые 5 мс, а окно контроля составляет 20 мс; оба параметра настраиваются: интервал от 3 мс до 10 с, окно контроля от 10 мс до 50 с. -Heartbeat-пакеты байпаса Silicom — небольшие служебные Ethernet-кадры; формат кадра задаётся в настройках байпаса. По умолчанию это IPX-пакет, то есть не IP; по запросу RDP.ru на устанавливаемых байпасах формат заменяется на согласованный с разработчиком балансировщика вариант, прохождение которого проверялось на стендовых тестах. Балансировщик не отправляет такие кадры на фильтры, а прозрачно передаёт в парный порт линка; в схеме без балансировщика ([раздел 2.3](02.md)) их без обработки пропускает в парный порт фильтр, и контур проверки замыкается на фильтре. +Heartbeat-пакеты байпаса Silicom — небольшие служебные Ethernet-кадры; формат кадра задаётся в настройках байпаса. По умолчанию это IPX-пакет, то есть не IP; по запросу RDP.ru на устанавливаемых байпасах формат заменяется на согласованный с разработчиком балансировщика вариант, прохождение которого проверялось на стендовых тестах. Балансировщик не отправляет такие кадры на фильтры, а прозрачно передаёт в парный порт линка; в схеме без балансировщика ([раздел 2.3](traffic-flow.md)) их без обработки пропускает в парный порт фильтр, и контур проверки замыкается на фильтре. Важно: при наличии балансировщика heartbeat-пакеты байпаса **не доходят до фильтров** — они заворачиваются обратно на уровне балансировщика. Таким образом, существуют **две независимые стадии** проверки отказоустойчивости: 1. **Байпас → Балансировщик** — heartbeat-пакеты байпаса проверяют доступность каналов до балансировщика; -2. **Балансировщик → Фильтр** — keep-alive-пакеты балансировщика проверяют доступность и работоспособность фильтров (подробнее — в [разделе 4.6](04.md)). +2. **Балансировщик → Фильтр** — keep-alive-пакеты балансировщика проверяют доступность и работоспособность фильтров (подробнее — в [разделе 6.6](balancer.md)). -## 3.5. Автоматическое переключение в TAP/Active Bypass при потере канала +## 5.5. Автоматическое переключение в TAP/Active Bypass при потере канала Если heartbeat-пакеты, отправленные через Mon0, не возвращаются в Mon1 (или наоборот) в течение окна контроля, байпас считает, что **канал связи до балансировщика неисправен**. Кроме потери heartbeat, байпас уходит в обход при пропадании линка на Mon-портах, при зависании подключённого inline-устройства и по команде оператора. @@ -227,13 +227,13 @@ Heartbeat-пакеты байпаса Silicom — небольшие служе (± копия на Mon0/Mon1, в зависимости от настроек; heartbeat продолжаются) ``` -Такое автоматическое переключение обеспечивает **защиту трафика оператора** без ручного вмешательства: если выйдет из строя балансировщик или канал между байпасом и балансировщиком, каналы оператора будут замкнуты напрямую, и связность сети сохранится. При наличии балансировщика отказ отдельного фильтра байпас не видит — его обрабатывает балансировщик программным байпасом группы портов ([раздел 4.6.2](04.md)); в схеме без балансировщика контур heartbeat проходит через фильтр, поэтому его отказ приводит к переключению байпаса. +Такое автоматическое переключение обеспечивает **защиту трафика оператора** без ручного вмешательства: если выйдет из строя балансировщик или канал между байпасом и балансировщиком, каналы оператора будут замкнуты напрямую, и связность сети сохранится. При наличии балансировщика отказ отдельного фильтра байпас не видит — его обрабатывает балансировщик программным байпасом группы портов ([раздел 6.6.2](balancer.md)); в схеме без балансировщика контур heartbeat проходит через фильтр, поэтому его отказ приводит к переключению байпаса. Отдельно стоит помнить о возврате из **Passive Bypass**: он даёт второй флап линков оператора, поскольку оптический тракт снова переключается с прямого соединения Net0 ↔ Net1 на приёмопередатчики байпаса. Возврат площадки в работу после аварийного обхода поэтому согласуется с оператором как плановые работы. -Побочный эффект возврата из байпаса в Inline: на фильтры сразу приходит большой объём трафика, и большинство сессий видны «с середины», без начального TCP SYN. Чтобы такие сессии заводились в обработку, на фильтрах должен быть включён приём TCP-сессий без SYN ([раздел 15.2.6](15.md)). +Побочный эффект возврата из байпаса в Inline: на фильтры сразу приходит большой объём трафика, и большинство сессий видны «с середины», без начального TCP SYN. Чтобы такие сессии заводились в обработку, на фильтрах должен быть включён приём TCP-сессий без SYN ([раздел 15.2.6](filter-interfaces.md)). -## 3.6. Развитие: отечественные байпасы +## 5.6. Развитие: отечественные байпасы По открытым данным, с 2022 года Silicom прекратил техническую поддержку своего оборудования для ТСПУ, и для проекта был разработан отечественный байпас: разработчиком решения называют компанию «Булат», программное обеспечение — RDP.ru, аппаратную часть — АО «Сигналтек». С 2023 года также тестируются оптические переключатели российского производства, созданные по заказу Роскомнадзора. @@ -243,4 +243,4 @@ Heartbeat-пакеты байпаса Silicom — небольшие служе --- -[← Оглавление](../README.md) · [← Раздел 2: Прохождение трафика через ТСПУ](02.md) · [Раздел 4: Балансировщик →](04.md) +[← Оглавление](../README.md) · [← Раздел 4: Эшелонированная система](echelon.md) · [Раздел 6: Балансировщик: принцип работы →](balancer.md) diff --git a/docs/central-management.md b/docs/central-management.md index b746b1c..10a8f47 100644 --- a/docs/central-management.md +++ b/docs/central-management.md @@ -1,10 +1,10 @@ -# 9. Центральная система управления (ЦСУ) +# 21. Центральная система управления (ЦСУ) -[← Оглавление](../README.md) · [← Раздел 8: Формирование протокольных списков](08.md) +[← Оглавление](../README.md) · [← Раздел 20: Сегмент управления ТСПУ](management-segment.md) --- -## 9.1. Архитектура: две независимые площадки (основная и резервная) +## 21.1. Архитектура: две независимые площадки (основная и резервная) Центральная система управления (ЦСУ) — это централизованная платформа, через которую осуществляется управление всеми ТСПУ, развёрнутыми по стране. ЦСУ располагается в **двух независимых ЦОДах**: @@ -32,7 +32,7 @@ Обе площадки **связаны между собой** выделенным каналом связи, по которому осуществляется репликация данных и обеспечивается отказоустойчивость. Пользователи (инженеры эксплуатации) также попадают на ЦСУ через **шифрованные VPN-каналы**. -## 9.2. Связь с ТСПУ через VPN (криптошлюз «Континент») +## 21.2. Связь с ТСПУ через VPN (криптошлюз «Континент») Связь между площадками ТСПУ и центральной системой управления осуществляется через **VPN**, построенный на криптошлюзах **«Континент»** (модель IPC-3000 или аналогичная). @@ -45,9 +45,9 @@ Каждая площадка ТСПУ связана **как с основной, так и с резервной** площадкой ЦСУ, что обеспечивает непрерывность управления при выходе из строя одной из площадок. -Криптошлюз «Континент» на площадке ТСПУ выступает **шлюзом по умолчанию** для всех устройств сегмента управления (адрес .254 в подсети управления — подробнее в [разделе 10](10.md)). +Криптошлюз «Континент» на площадке ТСПУ выступает **шлюзом по умолчанию** для всех устройств сегмента управления (адрес .254 в подсети управления — подробнее в [разделе 20](management-segment.md)). -## 9.3. Масштаб: ~350 площадок, ~5000 устройств +## 21.3. Масштаб: ~350 площадок, ~5000 устройств На текущем этапе федерального проекта ЦСУ обслуживает: @@ -59,7 +59,7 @@ Предполагается дальнейшее расширение по мере развития проекта. -## 9.4. Подсистемы ЦСУ: формирование списков, мониторинг, логирование, картография +## 21.4. Подсистемы ЦСУ: формирование списков, мониторинг, логирование, картография ЦСУ представляет собой **многокомпонентную распределённую систему**, состоящую из нескольких подсистем, каждая из которых выполняет свою задачу: @@ -75,7 +75,7 @@ Поддержкой и настройкой ЦСУ занимается **команда DevOps**. Инженеры, обслуживающие ТСПУ, являются **пользователями** ЦСУ — они используют её интерфейсы для мониторинга и управления, но не занимаются настройкой самой системы. Заливка программного обеспечения на ЦСУ также выполняется командой DevOps, тогда как заливка ПО на оборудование ТСПУ выполняется совместно инженерами площадки и разработчиками (ДЦА готовит конфигурации и новое ПО, инженеры на местах выполняют установку). -## 9.5. Новая ЦСУ для федерального проекта (замена уральской) +## 21.5. Новая ЦСУ для федерального проекта (замена уральской) В ходе развития проекта АСБИ существовали **две версии** ЦСУ: @@ -92,4 +92,4 @@ --- -[← Оглавление](../README.md) · [← Раздел 8: Формирование протокольных списков](08.md) · [Раздел 10: Сегмент управления ТСПУ →](10.md) +[← Оглавление](../README.md) · [← Раздел 20: Сегмент управления ТСПУ](management-segment.md) · [Раздел 22: Распознавание протоколов и двухстадийная блокировка →](protocol-blocking.md) diff --git a/docs/echelon.md b/docs/echelon.md index a024b1e..4fcfe61 100644 --- a/docs/echelon.md +++ b/docs/echelon.md @@ -1,10 +1,10 @@ -# 7. Эшелонированная система (ТСПУ тип Б) +# 4. Эшелонированная система (ТСПУ тип Б) -[← Оглавление](../README.md) · [← Раздел 6: Места установки ТСПУ](06.md) +[← Оглавление](../README.md) · [← Раздел 3: Места установки ТСПУ](placement.md) --- -## 7.1. Назначение: обработка трафика, не прошедшего через ТСПУ тип А +## 4.1. Назначение: обработка трафика, не прошедшего через ТСПУ тип А Эшелонированная система (ТСПУ тип Б, второй эшелон) предназначена для **обработки трафика, который не прошёл через стандартные ТСПУ** (тип А, первый эшелон). @@ -14,7 +14,7 @@ Идея эшелонирования возникла как способ **сократить общее количество ТСПУ**, развёртываемых по стране. Вместо установки ТСПУ тип А у каждого мелкого оператора на уровне доступа, можно у нескольких крупных операторов в ключевых точках установить двухстадийную систему фильтрации, что позволяет снизить затраты на реализацию проекта. -## 7.2. Проблема асимметричного трафика у крупных операторов +## 4.2. Проблема асимметричного трафика у крупных операторов Сеть крупного оператора связи, если идти от абонентов к выходу в интернет, делится на несколько сегментов: @@ -48,13 +48,13 @@ В таких случаях традиционная схема фильтрации **не работает**: на фильтре ТСПУ тип А сессия «не соберётся», потому что одна сторона сессии проходит через ТСПУ, а ответная — возвращается иным путём, минуя его. Для обработки такого **асимметричного трафика** и предназначен ТСПУ тип Б. -## 7.3. Балансировщик Eco Highway +## 4.3. Балансировщик Eco Highway Эшелонированная система, как и ТСПУ тип А, состоит из балансировщика и фильтров, но с существенными отличиями. Балансировщик эшелона называется **Eco Highway** (в отличие от **EcoFilter Balancer** в ТСПУ тип А). Аппаратная платформа **одинакова** — это тот же одноюнитовый 32-портовый коммутатор на базе чипа **Barefoot Tofino**. Различается только **программное обеспечение**. Ключевое отличие Eco Highway: он **сам выполняет фильтрацию трафика** на основе заголовков L3/L4 (IP-адреса, порты), а не просто распределяет трафик по фильтрам. -### 7.3.1. BGP-загрузка списков фильтрации из ЦСУ +### 4.3.1. BGP-загрузка списков фильтрации из ЦСУ В отличие от EcoFilter Balancer, где правила фильтрации (flow rules) задаются вручную и исчисляются единицами, на Eco Highway списки фильтрации: @@ -72,7 +72,7 @@ | Белый список | Ресурсы, исключённые из фильтрации | | Port redirect | Трафик, подлежащий отправке на фильтры | -### 7.3.2. Блокировка по IP-адресам на уровне балансировщика (Telegram, реестр РКН) +### 4.3.2. Блокировка по IP-адресам на уровне балансировщика (Telegram, реестр РКН) Eco Highway самостоятельно блокирует трафик, который можно идентифицировать по IP-адресам и портам — **без отправки на фильтры**: @@ -81,7 +81,7 @@ Eco Highway самостоятельно блокирует трафик, кот Принципиальное отличие от ТСПУ тип А: на первом эшелоне блокировка протоколов (Telegram и др.) выполняется **на фильтрах** с помощью DPI. На втором эшелоне эта блокировка выполняется **на самом балансировщике** по IP-спискам. Более того, в прошивке фильтров, предназначенных для эшелонированной системы, возможности блокировки протоколов (например, Telegram) **отсутствуют** — они просто не нужны, поскольку этим занимается Eco Highway. -### 7.3.3. Фильтры в режиме On-a-stick, VLAN-разделение LAN/WAN +### 4.3.3. Фильтры в режиме On-a-stick, VLAN-разделение LAN/WAN Фильтры в эшелонированной системе подключены **иначе**, чем в ТСПУ тип А: @@ -99,7 +99,7 @@ Eco Highway самостоятельно блокирует трафик, кот Таким образом, логическое разделение LAN/WAN сохраняется, но на уровне физики все интерфейсы фильтра однотипные. -### 7.3.4. Фильтры занимаются только URL-фильтрацией по реестру РКН +### 4.3.4. Фильтры занимаются только URL-фильтрацией по реестру РКН Поскольку блокировка по IP-адресам и протоколам выполняется самим Eco Highway, фильтры в эшелонированной системе занимаются **исключительно URL-фильтрацией** по реестру Роскомнадзора — той частью блокировки, которая требует глубокого анализа содержимого пакетов (DPI) и не может быть выполнена на уровне балансировщика. @@ -107,13 +107,13 @@ Eco Highway самостоятельно блокирует трафик, кот Благодаря упрощённому функционалу (нет распознавания протоколов, нет логирования соединений) производительность фильтров на эшелоне **несколько выше**, чем на ТСПУ тип А — примерно на 15%. Однако разница невелика, и при проектировании рекомендуется использовать те же расчётные цифры производительности, что и для ТСПУ тип А. -## 7.4. Два конвейера (Pipeline) в Eco Highway +## 4.4. Два конвейера (Pipeline) в Eco Highway Внутри чипа Barefoot Tofino, на котором построен балансировщик, существуют **два независимых конвейера** (Pipeline 1 и Pipeline 2) — логические структуры, обрабатывающие входящий трафик на высокой скорости. Каждый конвейер обладает собственным **независимым набором ресурсов**: памятью и вычислительной мощностью. На обычном балансировщике (EcoFilter Balancer) оба конвейера **настроены идентично** — в какой бы конвейер ни попал пакет, обработка будет одинаковой. На Eco Highway конвейеры **настраиваются по-разному** — это позволяет в два раза увеличить доступное количество правил фильтрации. -### 7.4.1. Разделение портов между конвейерами +### 4.4.1. Разделение портов между конвейерами Все физические порты балансировщика **жёстко привязаны** к одному из двух конвейеров на заводском уровне — примерно половина портов обслуживается Pipeline 1, половина — Pipeline 2. @@ -124,7 +124,7 @@ Eco Highway самостоятельно блокирует трафик, кот Принцип чётных/нечётных портов, используемый на EcoFilter Balancer, на эшелоне **не соблюдается** и не имеет значения. -### 7.4.2. Физическая перемычка между конвейерами +### 4.4.2. Физическая перемычка между конвейерами Поскольку конвейеры **логически изолированы** друг от друга внутри чипа (прямой связи между ними нет), для передачи пакета из одного конвейера в другой используется **физическая перемычка** (jumper) — кабель, соединяющий порт одного конвейера с портом другого. @@ -151,7 +151,7 @@ Eco Highway самостоятельно блокирует трафик, кот Перемычка должна быть рассчитана на **весь объём трафика**, проходящего через балансировщик. В худшем случае весь трафик может пройти через перемычку, поэтому она не должна стать узким местом. При большом количестве высокоскоростных каналов может потребоваться несколько перемычек. -### 7.4.3. Прохождение пакета: drop / отправка на фильтр / переход на второй конвейер +### 4.4.3. Прохождение пакета: drop / отправка на фильтр / переход на второй конвейер Когда пакет попадает на вход Eco Highway, он проходит следующий путь: @@ -167,13 +167,13 @@ Eco Highway самостоятельно блокирует трафик, кот Также важно: хотя порты привязаны к конвейерам на входе, на **выходе** пакет может быть отправлен через **любой порт** — это логическая сущность обработки, а не жёсткая привязка входа к выходу. Пакет, пришедший через определённый LAN-порт, всё равно вернётся через **парный** ему WAN-порт (сохраняется привязка к линку оператора), но маршрут внутри балансировщика может быть произвольным. -### 7.4.4. Удвоение количества правил фильтрации +### 4.4.4. Удвоение количества правил фильтрации Разделение правил между двумя конвейерами позволяет **в два раза увеличить** общее количество правил фильтрации на Eco Highway. Память внутри чипа Barefoot Tofino, хранящая эти правила, является **очень быстрой** (работает на скорости провода), но крайне ограниченной по объёму — это, по сути, программируемый TCAM (Content-Addressable Memory). Каждое дополнительное правило — на вес золота. На обычном EcoFilter Balancer, где оба конвейера идентичны, удвоение невозможно — один и тот же набор правил дублируется. На Eco Highway каждый конвейер несёт **свой уникальный набор**, удваивая суммарную ёмкость. -## 7.5. Отличия EcoFilter Balancer от Eco Highway +## 4.5. Отличия EcoFilter Balancer от Eco Highway | Характеристика | EcoFilter Balancer (тип А) | Eco Highway (тип Б) | | --------------------------- | -------------------------- | ------------------------------------------- | @@ -190,7 +190,7 @@ Eco Highway самостоятельно блокирует трафик, кот Разрабатываются обе платформы **одной группой программистов**, и код во многом пересекается. Решения, созданные в рамках реализации Eco Highway, нередко переносятся на EcoFilter Balancer (например, команды программного байпаса), и наоборот. -## 7.6. Отсутствие логирования на Eco Highway (только real-time) +## 4.6. Отсутствие логирования на Eco Highway (только real-time) На Eco Highway **не ведётся логирование** — информация о дропнутых и перенаправленных пакетах **не отправляется** на серверы логирования. Доступен только **просмотр в реальном времени** (real-time) на самом устройстве, без сохранения истории. @@ -204,14 +204,14 @@ Eco Highway самостоятельно блокирует трафик, кот - **Программный байпас** — можно перевести Eco Highway в режим полного программного байпаса и проверить, восстанавливается ли доступность у оператора; - **Проверка на фильтрах** — убедиться, что нужная сессия не обрабатывается и на фильтрах второго эшелона. -## 7.7. Прозрачный пропуск трафика, уже обработанного ТСПУ тип А +## 4.7. Прозрачный пропуск трафика, уже обработанного ТСПУ тип А Eco Highway должен уметь **различать** трафик, уже обработанный ТСПУ тип А на первом эшелоне, и трафик, который первый эшелон не видел. Трафик, который **уже прошёл** через ТСПУ тип А (на нижнем уровне, на уровне доступа), **не должен обрабатываться повторно** на втором эшелоне. Для этого на Eco Highway предусмотрена возможность **прозрачного пропуска** такого трафика — он просто «пролетает насквозь» без фильтрации. -Это позволяет избежать двойной обработки и связанных с ней проблем (удвоение сессий, ложные срабатывания, избыточная нагрузка), аналогичных проблемам двойного прохождения при on-a-stick подключении (подробнее — в [разделе 6.4.3](06.md)). +Это позволяет избежать двойной обработки и связанных с ней проблем (удвоение сессий, ложные срабатывания, избыточная нагрузка), аналогичных проблемам двойного прохождения при on-a-stick подключении (подробнее — в [разделе 3.4.3](placement.md)). --- -[← Оглавление](../README.md) · [← Раздел 6: Места установки ТСПУ](06.md) · [Раздел 8: Формирование протокольных списков →](08.md) +[← Оглавление](../README.md) · [← Раздел 3: Места установки ТСПУ](placement.md) · [Раздел 5: Байпас →](bypass.md) diff --git a/docs/filter-acl-pools.md b/docs/filter-acl-pools.md index edf7b7c..b9bfa6b 100644 --- a/docs/filter-acl-pools.md +++ b/docs/filter-acl-pools.md @@ -1,12 +1,12 @@ # 16. Фильтр: ACL и пулы — запуск трафика на обработку -[← Оглавление](../README.md) · [← Раздел 15: Фильтр: настройка интерфейсов и общих параметров](15.md) +[← Оглавление](../README.md) · [← Раздел 15: Фильтр: настройка интерфейсов и общих параметров](filter-interfaces.md) --- Чтобы фильтр начал обрабатывать трафик, необходимо выполнить два действия: **создать пул** и **привязать к нему ACL**. Без этих настроек — какие бы DPI-листы ни были сконфигурированы — весь трафик будет прозрачно пропускаться через устройство без какой-либо обработки. -Это одна из ключевых стадий в пути прохождения пакета через фильтр (подробнее — в [разделе 5.1](05.md)): IP-пакет должен попасть в ACL и в пул, чтобы далее передаваться на обработку движком DPI. +Это одна из ключевых стадий в пути прохождения пакета через фильтр (подробнее — в [разделе 10.1](filter.md)): IP-пакет должен попасть в ACL и в пул, чтобы далее передаваться на обработку движком DPI. > **Важно:** при заводской (дефолтной) конфигурации фильтра пулы и ACL **отсутствуют**. Их необходимо создать вручную при первоначальной настройке. @@ -74,7 +74,7 @@ ACL (Access Control List) — это набор правил, определяю apply ``` -Правила обрабатываются **по порядку номеров** — первое совпавшее правило определяет судьбу пакета. Это аналогично работе ACL на маршрутизаторах: если пакет совпал с правилом `allow`, он направляется в пул; если с правилом `deny` — этот пул для пакета больше не рассматривается и проверяются следующие пулы; не попав ни в один пул, пакет прозрачно проходит через фильтр ([раздел 5.1.2](05.md)). +Правила обрабатываются **по порядку номеров** — первое совпавшее правило определяет судьбу пакета. Это аналогично работе ACL на маршрутизаторах: если пакет совпал с правилом `allow`, он направляется в пул; если с правилом `deny` — этот пул для пакета больше не рассматривается и проверяются следующие пулы; не попав ни в один пул, пакет прозрачно проходит через фильтр ([раздел 10.1.2](filter.md)). ## 16.2. Создание пула: `create pool`, тип = fake (без NAT) @@ -165,13 +165,13 @@ ACL (Access Control List) — это набор правил, определяю Помимо connection log, в пуле присутствуют: -- **Тайм-ауты** — наследуются из секции `nat_defaults` при создании пула (подробнее — в [разделе 15.3](15.md)). При необходимости могут быть переопределены на уровне пула; +- **Тайм-ауты** — наследуются из секции `nat_defaults` при создании пула (подробнее — в [разделе 15.3](filter-interfaces.md)). При необходимости могут быть переопределены на уровне пула; - **Ограничения на пользователей (limiter)** — актуальны только для NAT, в проекте ТСПУ **не используются**; - **Параметр `hairpin`** — по умолчанию включён, актуален для режима с трансляцией адресов (позволяет абонентам обмениваться трафиком через NAT, не выходя вовне). В проекте ТСПУ менять не требуется. ## 16.6. IPv6 в пуле -Поддержка IPv6 в пуле настраивается аналогично глобальным настройкам IPv6 (подробнее — в [разделе 15.4](15.md)): +Поддержка IPv6 в пуле настраивается аналогично глобальным настройкам IPv6 (подробнее — в [разделе 15.4](filter-interfaces.md)): | Параметр | Описание | | --------------------- | ------------------------------------------------------------ | @@ -197,14 +197,14 @@ ACL (Access Control List) — это набор правил, определяю | **Интервал отправки** | Период отправки heartbeat-пакетов | | **Список каналов** | Каналы (линки) байпаса, по которым выполняется проверка | -На Урале осталось несколько площадок с такой схемой. С байпасами Silicom, которые сами отправляют heartbeat-пакеты и сами проверяют доступность каналов, секция не нужна (подробнее о байпасах — в [разделе 3.3](03.md); аналогичная настройка на балансировщике — в [разделе 21.8](21.md)). +На Урале осталось несколько площадок с такой схемой. С байпасами Silicom, которые сами отправляют heartbeat-пакеты и сами проверяют доступность каналов, секция не нужна (подробнее о байпасах — в [разделе 5.3](bypass.md); аналогичная настройка на балансировщике — в [разделе 8.8](balancer-config.md)). --- ### Диагностическая заметка: `show cps` показывает ноль -Если команда `show cps` показывает нулевое количество создаваемых сессий, одна из возможных причин — трафик **не попадает в пул**. Это может означать, что ACL не отбирает трафик: через фильтр могут идти гигабиты и десятки гигабит, но если пакеты не совпадают с правилами ACL привязанного пула, сессии создаваться не будут (подробнее — в [разделе 18.9](18.md)). +Если команда `show cps` показывает нулевое количество создаваемых сессий, одна из возможных причин — трафик **не попадает в пул**. Это может означать, что ACL не отбирает трафик: через фильтр могут идти гигабиты и десятки гигабит, но если пакеты не совпадают с правилами ACL привязанного пула, сессии создаваться не будут (подробнее — в [разделе 18.9](filter-monitoring.md)). --- -[← Оглавление](../README.md) · [← Раздел 15: Фильтр: настройка интерфейсов и общих параметров](15.md) · [Раздел 17: Фильтр: настройка DPI →](17.md) +[← Оглавление](../README.md) · [← Раздел 15: Фильтр: настройка интерфейсов и общих параметров](filter-interfaces.md) · [Раздел 17: Фильтр: настройка DPI →](filter-dpi.md) diff --git a/docs/filter-cli.md b/docs/filter-cli.md index 5fb4408..3595cba 100644 --- a/docs/filter-cli.md +++ b/docs/filter-cli.md @@ -1,6 +1,6 @@ # 13. Фильтр: первоначальная настройка и CLI -[← Оглавление](../README.md) · [← Раздел 12: Сессии и трансляции на фильтре](12.md) +[← Оглавление](../README.md) · [← Раздел 12: Фильтр: сессии и трансляции](filter-sessions.md) --- @@ -22,7 +22,7 @@ - **Логин:** `admin` - **Пароль:** `econat` -Данного пользователя можно удалить и создать новых (подробнее о настройке пользователей — в [разделе 14.4](14.md)). +Данного пользователя можно удалить и создать новых (подробнее о настройке пользователей — в [разделе 14.4](filter-subsystems.md)). ## 13.3. Операционный режим (>) и конфигурационный режим (#) @@ -175,4 +175,4 @@ CLI поддерживает стандартный набор средств н --- -[← Оглавление](../README.md) · [← Раздел 12: Сессии и трансляции на фильтре](12.md) · [Раздел 14: Фильтр: конфигурация подсистем →](14.md) +[← Оглавление](../README.md) · [← Раздел 12: Фильтр: сессии и трансляции](filter-sessions.md) · [Раздел 14: Фильтр: конфигурация подсистем →](filter-subsystems.md) diff --git a/docs/filter-dpi.md b/docs/filter-dpi.md index f2556e9..0637d9a 100644 --- a/docs/filter-dpi.md +++ b/docs/filter-dpi.md @@ -1,6 +1,6 @@ # 17. Фильтр: настройка DPI -[← Оглавление](../README.md) · [← Раздел 16: Фильтр: ACL и пулы](16.md) +[← Оглавление](../README.md) · [← Раздел 16: Фильтр: ACL и пулы](filter-acl-pools.md) --- @@ -100,7 +100,7 @@ - Ошибки на интерфейсе фильтра (в одном случае проблема решилась перезагрузкой фильтра); - Проблемы на стороне коммутатора или промежуточного оборудования. -При диагностике проблем скачивания следует обращать внимание на скорость и ошибки на management-интерфейсе. Команда `dpi run` позволяет принудительно инициировать обновление всех DPI-листов (подробнее — в [разделе 18.13.4](18.md)). +При диагностике проблем скачивания следует обращать внимание на скорость и ошибки на management-интерфейсе. Команда `dpi run` позволяет принудительно инициировать обновление всех DPI-листов (подробнее — в [разделе 18.13.4](filter-monitoring.md)). > **Примечание:** запуск `dpi run` не гарантирует, что реестр будет скачан — сервер РКН может ответить, что обновлений нет, и в этом случае ничего скачано не будет. @@ -195,7 +195,7 @@ - Для **HTTP**: абоненту отправляется HTTP-редирект на страницу-заглушку (по документации производителя — ответ «307 Temporary Redirect»); - Для **HTTPS**: абоненту и серверу отправляется TCP Reset, разрывающий соединение (поскольку содержимое зашифровано и подмена ответа невозможна). -**Режим ignore** — используется для **первой стадии двухстадийной блокировки**: фильтр распознаёт протоколы и отправляет логи на SPFS, но сам трафик не блокирует. Данные передаются в ЦСУ для формирования очищенных списков (подробнее — в [разделе 8](08.md)). +**Режим ignore** — используется для **первой стадии двухстадийной блокировки**: фильтр распознаёт протоколы и отправляет логи на SPFS, но сам трафик не блокирует. Данные передаются в ЦСУ для формирования очищенных списков (подробнее — в [разделе 22](protocol-blocking.md)). Также в секции DPI-листа присутствует параметр **logs on/off** — включение журналирования срабатываний данного списка. В проекте ТСПУ эта функциональность, как правило, используется. @@ -307,4 +307,4 @@ Download URL задаёт источник списков для DPI-листо --- -[← Оглавление](../README.md) · [← Раздел 16: Фильтр: ACL и пулы](16.md) · [Раздел 18: Фильтр: мониторинг и диагностика →](18.md) +[← Оглавление](../README.md) · [← Раздел 16: Фильтр: ACL и пулы](filter-acl-pools.md) · [Раздел 18: Фильтр: мониторинг и диагностика →](filter-monitoring.md) diff --git a/docs/filter-firmware.md b/docs/filter-firmware.md index 5ee6da5..3f87c1b 100644 --- a/docs/filter-firmware.md +++ b/docs/filter-firmware.md @@ -1,6 +1,6 @@ # 19. Фильтр: обновление прошивки -[← Оглавление](../README.md) · [← Раздел 18: Фильтр: мониторинг и диагностика](18.md) +[← Оглавление](../README.md) · [← Раздел 18: Фильтр: мониторинг и диагностика](filter-monitoring.md) --- @@ -117,4 +117,4 @@ --- -[← Оглавление](../README.md) · [← Раздел 18: Фильтр: мониторинг и диагностика](18.md) · [Раздел 20: Балансировщик: аппаратная платформа →](20.md) +[← Оглавление](../README.md) · [← Раздел 18: Фильтр: мониторинг и диагностика](filter-monitoring.md) · [Раздел 20: Сегмент управления ТСПУ →](management-segment.md) diff --git a/docs/filter-interfaces.md b/docs/filter-interfaces.md index ca28524..217844a 100644 --- a/docs/filter-interfaces.md +++ b/docs/filter-interfaces.md @@ -1,6 +1,6 @@ # 15. Фильтр: настройка интерфейсов и общих параметров -[← Оглавление](../README.md) · [← Раздел 14: Фильтр: конфигурация подсистем](14.md) +[← Оглавление](../README.md) · [← Раздел 14: Фильтр: конфигурация подсистем](filter-subsystems.md) --- @@ -91,7 +91,7 @@ ## 15.3. Тайм-ауты сессий и трансляций -В секции `nat_defaults` также настраиваются **тайм-ауты** для сессий и трансляций (подробнее о сессиях и трансляциях — в [разделе 12](12.md)): +В секции `nat_defaults` также настраиваются **тайм-ауты** для сессий и трансляций (подробнее о сессиях и трансляциях — в [разделе 12](filter-sessions.md)): - Тайм-ауты для **трансляций** и **сессий** задаются **раздельно**; - Параметры различаются по типу протокола (TCP, UDP, ICMP); @@ -120,4 +120,4 @@ --- -[← Оглавление](../README.md) · [← Раздел 14: Фильтр: конфигурация подсистем](14.md) · [Раздел 16: Фильтр: ACL и пулы →](16.md) +[← Оглавление](../README.md) · [← Раздел 14: Фильтр: конфигурация подсистем](filter-subsystems.md) · [Раздел 16: Фильтр: ACL и пулы →](filter-acl-pools.md) diff --git a/docs/filter-monitoring.md b/docs/filter-monitoring.md index efe6cf5..16d6d17 100644 --- a/docs/filter-monitoring.md +++ b/docs/filter-monitoring.md @@ -1,6 +1,6 @@ # 18. Фильтр: мониторинг и диагностика -[← Оглавление](../README.md) · [← Раздел 17: Фильтр: настройка DPI](17.md) +[← Оглавление](../README.md) · [← Раздел 17: Фильтр: настройка DPI](filter-dpi.md) --- @@ -202,7 +202,7 @@ **Нулевое значение** может означать: 1. **Трафик не проходит** через фильтр вообще; -2. **Трафик проходит, но не попадает в пул** — ACL не отбирает трафик, сессии не создаются. Через фильтр могут идти гигабиты и десятки гигабит, но `show cps` будет показывать ноль (подробнее — в [разделе 16](16.md)). +2. **Трафик проходит, но не попадает в пул** — ACL не отбирает трафик, сессии не создаются. Через фильтр могут идти гигабиты и десятки гигабит, но `show cps` будет показывать ноль (подробнее — в [разделе 16](filter-acl-pools.md)). ## 18.10. `show statistic` — статистика сессий и пулов, значение Optimal (= 20%) @@ -243,7 +243,7 @@ ## 18.12. Системный журнал: `show syslog`, ротация двух файлов -Помимо логирования на внешний сервер (см. [раздел 14.8](14.md)), логи хранятся **внутри устройства** на локальном разделе. +Помимо логирования на внешний сервер (см. [раздел 14.8](filter-subsystems.md)), логи хранятся **внутри устройства** на локальном разделе. Особенности внутреннего хранения: @@ -319,8 +319,8 @@ | `ping <адрес>` | Бесконечный пинг до указанного хоста (прервать — `Ctrl+C`) | | `traceroute <адрес>` | Трассировка маршрута до хоста | -> **Важно:** ping и traceroute работают **только через management-интерфейс**. Фильтр — это L2-устройство без IP-интерфейсов в тракте данных, поэтому инициировать трафик через LAN/WAN-интерфейсы **невозможно** (подробнее — в [разделе 5.2](05.md)). +> **Важно:** ping и traceroute работают **только через management-интерфейс**. Фильтр — это L2-устройство без IP-интерфейсов в тракте данных, поэтому инициировать трафик через LAN/WAN-интерфейсы **невозможно** (подробнее — в [разделе 10.2](filter.md)). --- -[← Оглавление](../README.md) · [← Раздел 17: Фильтр: настройка DPI](17.md) · [Раздел 19: Фильтр: обновление прошивки →](19.md) +[← Оглавление](../README.md) · [← Раздел 17: Фильтр: настройка DPI](filter-dpi.md) · [Раздел 19: Фильтр: обновление прошивки →](filter-firmware.md) diff --git a/docs/filter-platform.md b/docs/filter-platform.md index cb2ea36..db0bd0c 100644 --- a/docs/filter-platform.md +++ b/docs/filter-platform.md @@ -1,6 +1,6 @@ # 11. Фильтр: аппаратная платформа -[← Оглавление](../README.md) · [← Раздел 10: Сегмент управления ТСПУ](10.md) +[← Оглавление](../README.md) · [← Раздел 10: Фильтр: принцип работы](filter.md) --- @@ -108,7 +108,7 @@ Интерфейсы нумеруются с единицы и объединены в пары соседних номеров (te1/te2, te3/te4 …): в каждой паре чётный — LAN, нечётный — WAN. -Этот принцип чётных/нечётных портов **един** для всех моделей и поколений фильтров. Тот же принцип по договорённости принят при проектировании на балансировщиках EcoFilter Balancer, где жёсткой привязки нет ([раздел 4.3.1](04.md)); на Eco Highway он **не соблюдается** ([раздел 7.4.1](07.md)). +Этот принцип чётных/нечётных портов **един** для всех моделей и поколений фильтров. Тот же принцип по договорённости принят при проектировании на балансировщиках EcoFilter Balancer, где жёсткой привязки нет ([раздел 6.3.1](balancer.md)); на Eco Highway он **не соблюдается** ([раздел 4.4.1](echelon.md)). Разделение LAN/WAN прослеживается через всё оборудование ТСПУ — от байпасов через балансировщики до фильтров. Это фундаментальный принцип архитектуры: трафик от абонентов всегда приходит со стороны LAN, трафик из интернета — со стороны WAN. @@ -139,4 +139,4 @@ --- -[← Оглавление](../README.md) · [← Раздел 10: Сегмент управления ТСПУ](10.md) · [Раздел 12: Сессии и трансляции на фильтре →](12.md) +[← Оглавление](../README.md) · [← Раздел 10: Фильтр: принцип работы](filter.md) · [Раздел 12: Фильтр: сессии и трансляции →](filter-sessions.md) diff --git a/docs/filter-sessions.md b/docs/filter-sessions.md index 169dea7..1e43aae 100644 --- a/docs/filter-sessions.md +++ b/docs/filter-sessions.md @@ -1,6 +1,6 @@ -# 12. Сессии и трансляции на фильтре +# 12. Фильтр: сессии и трансляции -[← Оглавление](../README.md) · [← Раздел 11: Фильтр: аппаратная платформа](11.md) +[← Оглавление](../README.md) · [← Раздел 11: Фильтр: аппаратная платформа](filter-platform.md) --- @@ -58,7 +58,7 @@ └──────────────┘ └──────────────┘ └──────────────┘ ``` -Несмотря на то, что в режиме без NAT поля Local и Global дублируются, структура сессии остаётся прежней — это наследие архитектуры платформы, начинавшейся как CGNAT-устройство (подробнее — в [разделе 11.6](11.md)). На практике это означает, что команды фильтрации с ключевым словом `global` в нашем проекте **не имеют большого смысла** — достаточно использовать `local` и `remote`. +Несмотря на то, что в режиме без NAT поля Local и Global дублируются, структура сессии остаётся прежней — это наследие архитектуры платформы, начинавшейся как CGNAT-устройство (подробнее — в [разделе 11.6](filter-platform.md)). На практике это означает, что команды фильтрации с ключевым словом `global` в нашем проекте **не имеют большого смысла** — достаточно использовать `local` и `remote`. ## 12.4. Направление сессии: Egress (от абонента) / Ingress (к абоненту) @@ -94,7 +94,7 @@ То есть для пакетов со стороны LAN: Source IP → Local IP, Destination IP → Remote IP. Для пакетов со стороны WAN: поля **меняются местами** — Destination IP → Local IP, Source IP → Remote IP. -Это **крайне важный принцип** для траблшутинга. Если при просмотре сессий в поле Local IP появляются интернет-адреса (которые там быть не должны), это признак проблемы на пути прохождения трафика — например, **перепутки LAN/WAN** (подробнее — в [разделе 24.6](24.md)). +Это **крайне важный принцип** для траблшутинга. Если при просмотре сессий в поле Local IP появляются интернет-адреса (которые там быть не должны), это признак проблемы на пути прохождения трафика — например, **перепутки LAN/WAN** (подробнее — в [разделе 23.6](troubleshooting.md)). ## 12.6. Связь трансляций и сессий: одна трансляция — много сессий @@ -122,7 +122,7 @@ ## 12.7. Тайм-ауты сессий и трансляций -Тайм-ауты для сессий и трансляций задаются **раздельно** в секции NAT Defaults конфигурации фильтра (подробнее — в [разделе 15.3](15.md)): +Тайм-ауты для сессий и трансляций задаются **раздельно** в секции NAT Defaults конфигурации фильтра (подробнее — в [разделе 15.3](filter-interfaces.md)): - **Тайм-аут сессии** — время с момента последнего пакета, после которого сессия удаляется; - **Тайм-аут трансляции** — время с момента удаления последней связанной сессии, после которого удаляется сама трансляция. @@ -188,4 +188,4 @@ API для удалённого доступа к данным фильтра о --- -[← Оглавление](../README.md) · [← Раздел 11: Фильтр: аппаратная платформа](11.md) · [Раздел 13: Фильтр: первоначальная настройка и CLI →](13.md) +[← Оглавление](../README.md) · [← Раздел 11: Фильтр: аппаратная платформа](filter-platform.md) · [Раздел 13: Фильтр: первоначальная настройка и CLI →](filter-cli.md) diff --git a/docs/filter-subsystems.md b/docs/filter-subsystems.md index c254753..855c6ef 100644 --- a/docs/filter-subsystems.md +++ b/docs/filter-subsystems.md @@ -1,6 +1,6 @@ # 14. Фильтр: конфигурация подсистем -[← Оглавление](../README.md) · [← Раздел 13: Фильтр: первоначальная настройка и CLI](13.md) +[← Оглавление](../README.md) · [← Раздел 13: Фильтр: первоначальная настройка и CLI](filter-cli.md) --- @@ -43,7 +43,7 @@ nameservers 192.168.1.45 8.8.8.8 8.8.4.4 ``` -Также можно использовать режим многострочного ввода через скобки (см. [раздел 13.8 — «мышеловка»](13.md)). +Также можно использовать режим многострочного ввода через скобки (см. [раздел 13.8 — «мышеловка»](filter-cli.md)). ## 14.3. Терминал (SSH): auto-logout, prompt, нумерация строк @@ -198,7 +198,7 @@ ## 14.10. Журналирование протоколов (debug logger) — отправка на SPFS -Секция **debug logger** (несмотря на название «debug», это штатная функциональность) отвечает за отправку **протокольных логов** — результатов распознавания протоколов движком DPI — на серверы **SPFS** для дальнейшего формирования очищенных списков блокировки (подробнее о полном цикле — в [разделе 8](08.md)). +Секция **debug logger** (несмотря на название «debug», это штатная функциональность) отвечает за отправку **протокольных логов** — результатов распознавания протоколов движком DPI — на серверы **SPFS** для дальнейшего формирования очищенных списков блокировки (подробнее о полном цикле — в [разделе 22](protocol-blocking.md)). ### 14.10.1. Выбор протоколов (all / конкретные) @@ -229,4 +229,4 @@ --- -[← Оглавление](../README.md) · [← Раздел 13: Фильтр: первоначальная настройка и CLI](13.md) · [Раздел 15: Фильтр: настройка интерфейсов и общих параметров →](15.md) +[← Оглавление](../README.md) · [← Раздел 13: Фильтр: первоначальная настройка и CLI](filter-cli.md) · [Раздел 15: Фильтр: настройка интерфейсов и общих параметров →](filter-interfaces.md) diff --git a/docs/filter.md b/docs/filter.md index 7489ce2..a59634e 100644 --- a/docs/filter.md +++ b/docs/filter.md @@ -1,16 +1,16 @@ -# 5. Фильтр (EcoFilter) +# 10. Фильтр: принцип работы -[← Оглавление](../README.md) · [← Раздел 4: Балансировщик](04.md) +[← Оглавление](../README.md) · [← Раздел 9: Балансировщик: мониторинг и диагностика](balancer-monitoring.md) --- -Фильтр — основное устройство ТСПУ: он анализирует трафик и применяет к нему политики блокировки. Это сервер EcoFilter на платформе RDP.ru EcoSGE. Программный комплекс фильтра вырос из CGNAT-устройства, и трафик на нём обрабатывает процесс **EcoNAT** — на всех ядрах процессора, кроме одного сервисного ([раздел 4.5.2](04.md)). Из функций платформы (NAT, BRAS, управление качеством сервиса, URL-фильтрация, DPI) в ТСПУ задействованы две: **EcoFilter** — фильтрация по спискам (реестр Роскомнадзора и другие списки) и **EcoDPI** — распознавание протоколов и приложений вплоть до седьмого уровня модели OSI. Происхождением от CGNAT объясняются понятия, с которыми приходится работать на фильтре: пулы, трансляции и сессии, секция общих параметров `nat_defaults` ([разделы 11.6](11.md), [12](12.md), [15.2](15.md) и [16](16.md)). +Фильтр — основное устройство ТСПУ: он анализирует трафик и применяет к нему политики блокировки. Это сервер EcoFilter на платформе RDP.ru EcoSGE. Программный комплекс фильтра вырос из CGNAT-устройства, и трафик на нём обрабатывает процесс **EcoNAT** — на всех ядрах процессора, кроме одного сервисного ([раздел 6.5.2](balancer.md)). Из функций платформы (NAT, BRAS, управление качеством сервиса, URL-фильтрация, DPI) в ТСПУ задействованы две: **EcoFilter** — фильтрация по спискам (реестр Роскомнадзора и другие списки) и **EcoDPI** — распознавание протоколов и приложений вплоть до седьмого уровня модели OSI. Происхождением от CGNAT объясняются понятия, с которыми приходится работать на фильтре: пулы, трансляции и сессии, секция общих параметров `nat_defaults` ([разделы 11.6](filter-platform.md), [12](filter-sessions.md), [15.2](filter-interfaces.md) и [16](filter-acl-pools.md)). -## 5.1. Путь пакета через фильтр +## 10.1. Путь пакета через фильтр -Порты фильтра, через которые идёт трафик, объединены в пары: чётный порт пары — LAN (сторона абонентов), нечётный — WAN (сторона интернета) ([раздел 11.5](11.md)). По этой ориентации фильтр определяет, какой адрес сессии локальный (абонентский), а какой удалённый ([раздел 12.5](12.md)), поэтому перепутанные LAN и WAN нарушают обработку ([раздел 24.6](24.md)). Проходящий через фильтр кадр покидает его только через парный порт. Исключение — пакеты, которые фильтр сам формирует при блокировке: ответ абоненту (перенаправление или TCP Reset) уходит обратно в LAN-порт, через который пришёл запрос. За балансировщиком кадр приходит с 4-байтным служебным заголовком: по нему фильтр выбирает ядро для обработки и с тем же заголовком возвращает кадр на балансировщик ([раздел 4.5.3](04.md)). +Порты фильтра, через которые идёт трафик, объединены в пары: чётный порт пары — LAN (сторона абонентов), нечётный — WAN (сторона интернета) ([раздел 11.5](filter-platform.md)). По этой ориентации фильтр определяет, какой адрес сессии локальный (абонентский), а какой удалённый ([раздел 12.5](filter-sessions.md)), поэтому перепутанные LAN и WAN нарушают обработку ([раздел 23.6](troubleshooting.md)). Проходящий через фильтр кадр покидает его только через парный порт. Исключение — пакеты, которые фильтр сам формирует при блокировке: ответ абоненту (перенаправление или TCP Reset) уходит обратно в LAN-порт, через который пришёл запрос. За балансировщиком кадр приходит с 4-байтным служебным заголовком: по нему фильтр выбирает ядро для обработки и с тем же заголовком возвращает кадр на балансировщик ([раздел 6.5.3](balancer.md)). -Так фильтры подключаются в ТСПУ тип А. В эшелонированной системе (ТСПУ тип Б) фильтр подключён к балансировщику Eco Highway по схеме on-a-stick: порты равноправны, направление обозначает служебный VLAN-тег, который фильтр после обработки меняет на парный, а распознаванием протоколов фильтры там не занимаются ([разделы 7.3.3](07.md) и [7.3.4](07.md)). +Так фильтры подключаются в ТСПУ тип А. В эшелонированной системе (ТСПУ тип Б) фильтр подключён к балансировщику Eco Highway по схеме on-a-stick: порты равноправны, направление обозначает служебный VLAN-тег, который фильтр после обработки меняет на парный, а распознаванием протоколов фильтры там не занимаются ([разделы 4.3.3](echelon.md) и [4.3.4](echelon.md)). Каждый пакет проходит **цепочку проверок**. Если на каком-то этапе пакет под обработку не подпадает, фильтр сразу передаёт его в парный порт без изменений, и пакет продолжает путь по сети оператора так, будто фильтра в тракте нет. До движка DPI доходит только трафик, прошедший все предварительные проверки: @@ -45,9 +45,9 @@ перенаправление) ``` -Даже первую, самую простую проверку («IP-пакет или нет») выполняет программное ядро фильтра — процесс EcoNAT. Если процесс завис или фильтр перегружен настолько, что перестал обрабатывать трафик, не проходит и она: keep-alive-пакеты балансировщика перестают возвращаться, и балансировщик переводит эту пару портов в программный байпас, а при включённой перебалансировке перераспределяет её трафик по остальным парам портов ([раздел 4.6](04.md)). Поэтому keep-alive проверяют не только физический канал, но и то, что фильтр продолжает обрабатывать трафик. В схеме без балансировщика ту же роль играют heartbeat-пакеты байпаса ([раздел 3.1](03.md)). +Даже первую, самую простую проверку («IP-пакет или нет») выполняет программное ядро фильтра — процесс EcoNAT. Если процесс завис или фильтр перегружен настолько, что перестал обрабатывать трафик, не проходит и она: keep-alive-пакеты балансировщика перестают возвращаться, и балансировщик переводит эту пару портов в программный байпас, а при включённой перебалансировке перераспределяет её трафик по остальным парам портов ([раздел 6.6](balancer.md)). Поэтому keep-alive проверяют не только физический канал, но и то, что фильтр продолжает обрабатывать трафик. В схеме без балансировщика ту же роль играют heartbeat-пакеты байпаса ([раздел 5.1](bypass.md)). -### 5.1.1. Проверка: IP-пакет или нет +### 10.1.1. Проверка: IP-пакет или нет Сначала фильтр ищет в кадре IP-пакет. Инкапсуляция на стыке оператора зависит от его технологий и от места установки ТСПУ, и вариантов много: @@ -57,7 +57,7 @@ - PPPoE-трафик, в том числе с двумя VLAN-тегами и внутри MPLS; - и другие комбинации. -Фильтр не снимает эти заголовки, а разбирает стек, чтобы добраться до IP-пакета: MPLS-метки он просматривает до конца стека, а сколько VLAN-тегов разбирать, задаёт параметр `vlan_mode` (VLAN Mode) в секции `nat_defaults` ([раздел 15.2.1](15.md)): +Фильтр не снимает эти заголовки, а разбирает стек, чтобы добраться до IP-пакета: MPLS-метки он просматривает до конца стека, а сколько VLAN-тегов разбирать, задаёт параметр `vlan_mode` (VLAN Mode) в секции `nat_defaults` ([раздел 15.2.1](filter-interfaces.md)): | Значение `vlan_mode` | Где фильтр ищет IP-пакет | | ------------------------- | -------------------------------------------------------------------------- | @@ -72,17 +72,17 @@ В документации производителя описаны ещё две настройки этого этапа: - `inner_vlan` и `outer_vlan` — значения TPID внутреннего и внешнего VLAN-тегов (по умолчанию оба 0x8100). Они доступны на платформах с сетевыми контроллерами Intel серий 710/810 и нужны для правильной обработки QinQ: значение задаётся для всего устройства и должно совпадать с тем, как теги формирует оборудование оператора (например, TPID 0x88A8 у внешнего тега по IEEE 802.1ad или встречающийся на старом оборудовании 0x9100); -- `pppoe_analyzer` — обработка трафика PPPoE (по умолчанию выключена). При установке ТСПУ до BRAS, где идёт PPPoE-трафик ([раздел 6.1.1](06.md)), её стоит проверить. +- `pppoe_analyzer` — обработка трафика PPPoE (по умолчанию выключена). При установке ТСПУ до BRAS, где идёт PPPoE-трафик ([раздел 3.1.1](placement.md)), её стоит проверить. -У фильтра ограничений на типы инкапсуляции больше, чем у балансировщика ([раздел 4.7](04.md)): например, балансировщик разбирает до трёх VLAN-тегов, а фильтр — не больше двух. Кадр, в котором фильтр IP-пакет не нашёл, проходит через него прозрачно, без анализа. +У фильтра ограничений на типы инкапсуляции больше, чем у балансировщика ([раздел 6.7](balancer.md)): например, балансировщик разбирает до трёх VLAN-тегов, а фильтр — не больше двух. Кадр, в котором фильтр IP-пакет не нашёл, проходит через него прозрачно, без анализа. -Кадры без IP-пакета фильтр передаёт в парный порт на этой же проверке. За балансировщиком до фильтра доходят практически только keep-alive-пакеты балансировщика — прочие не-IP-кадры балансировщик пропускает сам, не отправляя на фильтры ([раздел 4.7](04.md)). Keep-alive возвращаются на балансировщик, который по времени их прохождения контролирует путь через фильтр ([раздел 4.6.1](04.md)). В схеме без балансировщика через фильтр прозрачно проходят и служебные кадры сети оператора — например, ARP или LACP, а heartbeat-кадры байпаса Silicom, подключённого к фильтру напрямую, тоже проходят в парный порт без обработки ([раздел 3.4](03.md)). +Кадры без IP-пакета фильтр передаёт в парный порт на этой же проверке. За балансировщиком до фильтра доходят практически только keep-alive-пакеты балансировщика — прочие не-IP-кадры балансировщик пропускает сам, не отправляя на фильтры ([раздел 6.7](balancer.md)). Keep-alive возвращаются на балансировщик, который по времени их прохождения контролирует путь через фильтр ([раздел 6.6.1](balancer.md)). В схеме без балансировщика через фильтр прозрачно проходят и служебные кадры сети оператора — например, ARP или LACP, а heartbeat-кадры байпаса Silicom, подключённого к фильтру напрямую, тоже проходят в парный порт без обработки ([раздел 5.4](bypass.md)). -### 5.1.2. Проверка по ACL (привязка к пулу) +### 10.1.2. Проверка по ACL (привязка к пулу) Найденный IP-пакет фильтр проверяет на принадлежность к **пулу**. Пул — понятие из CGNAT: там он задаёт тип трансляции и набор внешних адресов, а привязанный к пулу **ACL** (Access Control List) определяет, какой трафик этот пул обслуживает. DPI обрабатывает только трафик, попавший в какой-либо пул, поэтому пул нужен и там, где адреса не транслируются. В ТСПУ используются пулы типа **fake**: трансляции в них нет — что пришло, то и ушло. -Минимальная рабочая настройка — включённый (`enable`) пул типа `fake` с привязанным ACL. Новый пул создаётся с типом `cgnat`, поэтому тип `fake` задаётся явно ([раздел 16](16.md)). +Минимальная рабочая настройка — включённый (`enable`) пул типа `fake` с привязанным ACL. Новый пул создаётся с типом `cgnat`, поэтому тип `fake` задаётся явно ([раздел 16](filter-acl-pools.md)). Правило ACL состоит из: @@ -98,15 +98,15 @@ - совпало правило `deny` — этот пул для пакета больше не рассматривается, проверяются следующие; - не совпало ни одно правило — тоже переход к следующему пулу. -Если подходящего пула не нашлось, пакет прозрачно уходит в парный порт. Назначать нескольким пулам одинаковый приоритет не следует: по документации производителя тогда будет задействован только один из них. IPv6-трафик отбирается собственными настройками пула: обработку IPv6 нужно включить, иначе сессии по IPv6 не заводятся и этот трафик проходит через фильтр прозрачно ([разделы 15.4](15.md) и [16.6](16.md)). +Если подходящего пула не нашлось, пакет прозрачно уходит в парный порт. Назначать нескольким пулам одинаковый приоритет не следует: по документации производителя тогда будет задействован только один из них. IPv6-трафик отбирается собственными настройками пула: обработку IPv6 нужно включить, иначе сессии по IPv6 не заводятся и этот трафик проходит через фильтр прозрачно ([разделы 15.4](filter-interfaces.md) и [16.6](filter-acl-pools.md)). -Пул выбирается при создании сессии — по первому пакету потока; следующие пакеты фильтр находит в таблице сессий, и вся дальнейшая обработка ведётся в рамках сессий ([раздел 12](12.md)). Здесь фильтр может и отбросить пакет ещё до DPI: по умолчанию TCP-сессия заводится только по пакету с флагом SYN, а TCP-пакет без SYN, для которого сессии нет, отбрасывается. В ТСПУ такое поведение отключают параметром `permit_invalid_flow` ([раздел 5.2](#52-работа-на-уровне-l2-фильтр-как-прозрачный-провод)). +Пул выбирается при создании сессии — по первому пакету потока; следующие пакеты фильтр находит в таблице сессий, и вся дальнейшая обработка ведётся в рамках сессий ([раздел 12](filter-sessions.md)). Здесь фильтр может и отбросить пакет ещё до DPI: по умолчанию TCP-сессия заводится только по пакету с флагом SYN, а TCP-пакет без SYN, для которого сессии нет, отбрасывается. В ТСПУ такое поведение отключают параметром `permit_invalid_flow` ([раздел 10.2](#102-работа-на-уровне-l2-фильтр-как-прозрачный-провод)). -> **Важно:** в заводской конфигурации фильтра пулов и ACL нет. Пока они не созданы, фильтр пропускает весь трафик прозрачно, какие бы DPI-листы ни были настроены. Признак такой ситуации — нулевая скорость создания сессий в `show cps` при идущем через фильтр трафике ([раздел 18.9](18.md)). +> **Важно:** в заводской конфигурации фильтра пулов и ACL нет. Пока они не созданы, фильтр пропускает весь трафик прозрачно, какие бы DPI-листы ни были настроены. Признак такой ситуации — нулевая скорость создания сессий в `show cps` при идущем через фильтр трафике ([раздел 18.9](filter-monitoring.md)). -### 5.1.3. Проверка по DPI-листу (IP-подсети) +### 10.1.3. Проверка по DPI-листу (IP-подсети) -Следующий этап — **DPI-листы**. DPI-лист объединяет настройки одной политики фильтрации: на какой трафик она распространяется, что в нём ищется (загружаемый список IP-адресов, доменов и URL, распознаваемые протоколы) и что делать при совпадении ([раздел 5.1.5](#515-решение-пропустить-или-заблокировать-drop)). Подробно настройки DPI-листов описаны в [разделе 17.4](17.md). +Следующий этап — **DPI-листы**. DPI-лист объединяет настройки одной политики фильтрации: на какой трафик она распространяется, что в нём ищется (загружаемый список IP-адресов, доменов и URL, распознаваемые протоколы) и что делать при совпадении ([раздел 10.1.5](#1015-решение-пропустить-или-заблокировать-drop)). Подробно настройки DPI-листов описаны в [разделе 17.4](filter-dpi.md). Набор листов задан прошивкой: это листы с номерами 0–16 — лист 0 и шестнадцать листов 1–16. Каждый лист включается и выключается независимо. В более поздних версиях ПО, по документации производителя, листы создаются по мере необходимости командой `create dpilist N` — в стандартной конфигурации с номерами 0–24, по запросу заказчика — до 1000. @@ -119,17 +119,17 @@ | `no_ip_remote` | удалённые адреса (серверов), исключённые из обработки листом | | `ipv6` / `no_ipv6` | то же для IPv6 | -Исключения проверяются первыми: адрес из `no_ip` листом не обрабатывается, даже если входит в `ip`. Штатно в `ip` задаётся сеть `0.0.0.0/0` для всех VLAN — тогда лист действует на весь трафик, дошедший до DPI. Добавить адрес абонента в `no_ip` — удобный способ диагностики: если у абонента после этого что-то изменилось (например, заработало приложение), этот лист на его трафик действительно влиял ([раздел 17.4.8](17.md)). +Исключения проверяются первыми: адрес из `no_ip` листом не обрабатывается, даже если входит в `ip`. Штатно в `ip` задаётся сеть `0.0.0.0/0` для всех VLAN — тогда лист действует на весь трафик, дошедший до DPI. Добавить адрес абонента в `no_ip` — удобный способ диагностики: если у абонента после этого что-то изменилось (например, заработало приложение), этот лист на его трафик действительно влиял ([раздел 17.4.8](filter-dpi.md)). В более поздних версиях ПО этих параметров в описании DPI-листа уже нет (в руководстве пользователя EcoSGE 3.1.8 они остались лишь в отдельных примерах конфигурации): вместо них к листу привязывается ACL (`acl`, `aclv6`). Трафик, совпавший с разрешающим правилом, обрабатывается листом, совпавший с запрещающим — передаётся следующему листу; значение по умолчанию `none` равносильно `permit ip any any`, то есть лист действует на весь трафик. Аналог диагностики через `no_ip` здесь — запрещающее правило для адреса абонента в ACL листа. Пакет, адреса которого не подпадают ни под один включённый лист, DPI не анализирует — он прозрачно уходит в парный порт. Листы применяются в порядке возрастания номера; если сработали несколько листов, выполняется действие листа с наименьшим номером. Лист с `behaviour ignore` других листов при этом не перекрывает: по руководству EcoSGE 3.1.8 совпавший с ним трафик передаётся на проверку следующему листу. -В ТСПУ фильтрация по реестру Роскомнадзора выполняется в листе 0. В ранних версиях ПО настройки реестра находятся прямо в листе 0; в более поздних они вынесены в отдельный раздел, лист для реестра выбирается параметром `list_number` (по умолчанию 0; в руководстве EcoSGE 3.1.8 значение по умолчанию не задано, и лист указывают явно), а все листы устроены одинаково ([раздел 17.2](17.md)). Действие (`behaviour`) задаётся для листа целиком, а лист 0 блокирует по реестру, поэтому распознавание протоколов (`ignore`) и блокировку по очищенным спискам из ЦСУ (`block`, например в листе 5) настраивают в других листах ([раздел 8](08.md)). +В ТСПУ фильтрация по реестру Роскомнадзора выполняется в листе 0. В ранних версиях ПО настройки реестра находятся прямо в листе 0; в более поздних они вынесены в отдельный раздел, лист для реестра выбирается параметром `list_number` (по умолчанию 0; в руководстве EcoSGE 3.1.8 значение по умолчанию не задано, и лист указывают явно), а все листы устроены одинаково ([раздел 17.2](filter-dpi.md)). Действие (`behaviour`) задаётся для листа целиком, а лист 0 блокирует по реестру, поэтому распознавание протоколов (`ignore`) и блокировку по очищенным спискам из ЦСУ (`block`, например в листе 5) настраивают в других листах ([раздел 22](protocol-blocking.md)). -### 5.1.4. Обработка движком DPI +### 10.1.4. Обработка движком DPI -Трафик, прошедший предварительные проверки, анализирует **движок DPI**. Он сверяет трафик со списками фильтрации — IP-адресами, доменами и URL (для HTTP — по запрошенному URL, для HTTPS — по имени сервера в SNI, [раздел 17.5](17.md)) — и распознаёт протоколы и приложения. +Трафик, прошедший предварительные проверки, анализирует **движок DPI**. Он сверяет трафик со списками фильтрации — IP-адресами, доменами и URL (для HTTP — по запрошенному URL, для HTTPS — по имени сервера в SNI, [раздел 17.5](filter-dpi.md)) — и распознаёт протоколы и приложения. Распознавание — это **многофакторный анализ сессии**, а не отдельного пакета: движку нужно несколько пакетов сессии в обоих направлениях. Кроме очевидных полей — адресов и портов источника и назначения — учитывается не один десяток признаков, например: @@ -137,11 +137,11 @@ - частота прохождения пакетов; - частота появления тех или иных ключевых слов внутри пакетов. -У трафика, который шифруется и намеренно скрывает свою природу (протоколы мессенджеров, обфусцированные VPN), явных полей, указывающих на протокол, нет, поэтому он распознаётся по косвенным признакам. Такое распознавание **не стопроцентно**: другой шифрованный трафик может быть принят, например, за Telegram, и его блокировка задела бы полезные ресурсы. Поэтому для блокировки таких протоколов применяется двухэтапная схема: сначала фильтры только распознают трафик и отправляют логи, а блокируют уже по спискам, очищенным от ложных срабатываний в ЦСУ ([разделы 8](08.md) и [23](23.md)). Распознавание можно обойти — например, протоколом, который маскируется под другой. Если протокол в новой версии перестал распознаваться, нужна новая сигнатура ([раздел 23.4](23.md)). +У трафика, который шифруется и намеренно скрывает свою природу (протоколы мессенджеров, обфусцированные VPN), явных полей, указывающих на протокол, нет, поэтому он распознаётся по косвенным признакам. Такое распознавание **не стопроцентно**: другой шифрованный трафик может быть принят, например, за Telegram, и его блокировка задела бы полезные ресурсы. Поэтому для блокировки таких протоколов применяется двухстадийная схема: сначала фильтры только распознают трафик и отправляют логи, а блокируют уже по спискам, очищенным от ложных срабатываний в ЦСУ ([раздел 22](protocol-blocking.md)). Распознавание можно обойти — например, протоколом, который маскируется под другой. Если протокол в новой версии перестал распознаваться, нужна новая сигнатура ([раздел 22.3](protocol-blocking.md)). -Модуль DPI можно выключить целиком — тогда весь трафик проходит через фильтр прозрачно, без анализа. Так проверяют, связана ли проблема абонента с обработкой на фильтре вообще ([раздел 17.1.1](17.md)). +Модуль DPI можно выключить целиком — тогда весь трафик проходит через фильтр прозрачно, без анализа. Так проверяют, связана ли проблема абонента с обработкой на фильтре вообще ([раздел 17.1.1](filter-dpi.md)). -### 5.1.5. Решение: пропустить или заблокировать (drop) +### 10.1.5. Решение: пропустить или заблокировать (drop) По результату анализа фильтр решает судьбу пакета: в общем случае — пропустить его в парный порт или отбросить (drop), если трафик попадает под запрещающую политику. Что делать при срабатывании, задаёт параметр `behaviour` DPI-листа: @@ -157,39 +157,39 @@ **Блокировка (`block`)** — основной режим для реестра Роскомнадзора и для очищенных протокольных списков: - **HTTP** — запрос к заблокированному ресурсу не пропускается, а абоненту отправляется ответ с перенаправлением на страницу-заглушку оператора, сообщающую, что ресурс заблокирован. Адрес страницы задаёт параметр `redirect_url`; по документации производителя это ответ «307 Temporary Redirect» с этим адресом в заголовке `Location`. URL передаётся открыто, поэтому блокировать можно конкретную страницу; -- **HTTPS** — содержимое зашифровано, и подменить ответ нельзя: ресурс определяется по домену в SNI, а соединение разрывается пакетами TCP Reset. Блокируется домен целиком ([раздел 17.5.3](17.md)). По документации производителя проверяется и сертификат сервера, если он передаётся открыто (до TLS 1.3), а соединение без SNI пропускается; -- **трафик с MPLS-метками** — ответ абоненту фильтр сам сформировать не может: MPLS-путь однонаправлен, и стек меток обратного направления фильтру неизвестен. Поэтому запрос абонента пропускается к серверу, фильтр дожидается ответного пакета в той же сессии и подменяет его содержимое на перенаправление или TCP Reset, сохраняя метки ([раздел 4.8](04.md)); -- **протоколы, блокировка которых включена в DPI-листе** (указаны в `protocols` листа с `behaviour block`) — пакеты заблокированной сессии отбрасываются, TCP Reset при этом не отправляется (см. ниже про send RST). Вместо полной блокировки протокол можно «деградировать»: параметры деградации (protocols capacity) задают для протокола значение от 0 до 100 в условных единицах (это не проценты): 0 — полная блокировка, 100 — полный пропуск, промежуточные значения — сброс части пакетов сессии с вероятностью, зависящей от значения. Сама по себе настройка деградации — даже значение 0 — ничего не блокирует: она действует только на протоколы, блокировка которых включена в DPI-листе, и не затрагивает лист распознавания с `ignore` ([раздел 17.3](17.md)). +- **HTTPS** — содержимое зашифровано, и подменить ответ нельзя: ресурс определяется по домену в SNI, а соединение разрывается пакетами TCP Reset. Блокируется домен целиком ([раздел 17.5.3](filter-dpi.md)). По документации производителя проверяется и сертификат сервера, если он передаётся открыто (до TLS 1.3), а соединение без SNI пропускается; +- **трафик с MPLS-метками** — ответ абоненту фильтр сам сформировать не может: MPLS-путь однонаправлен, и стек меток обратного направления фильтру неизвестен. Поэтому запрос абонента пропускается к серверу, фильтр дожидается ответного пакета в той же сессии и подменяет его содержимое на перенаправление или TCP Reset, сохраняя метки ([раздел 6.8](balancer.md)); +- **протоколы, блокировка которых включена в DPI-листе** (указаны в `protocols` листа с `behaviour block`) — пакеты заблокированной сессии отбрасываются, TCP Reset при этом не отправляется (см. ниже про send RST). Вместо полной блокировки протокол можно «деградировать»: параметры деградации (protocols capacity) задают для протокола значение от 0 до 100 в условных единицах (это не проценты): 0 — полная блокировка, 100 — полный пропуск, промежуточные значения — сброс части пакетов сессии с вероятностью, зависящей от значения. Сама по себе настройка деградации — даже значение 0 — ничего не блокирует: она действует только на протоколы, блокировка которых включена в DPI-листе, и не затрагивает лист распознавания с `ignore` ([раздел 17.3](filter-dpi.md)). -**Распознавание (`ignore`)** — первая стадия двухэтапной блокировки: лист со списком распознаваемых протоколов срабатывает, но трафик не трогает, а логи о распознанных сессиях уходят на SPFS и далее в ЦСУ ([разделы 8](08.md) и [14.10](14.md)). ЦСУ отсеивает ложные срабатывания и загружает очищенные списки в **другой** DPI-лист — с `behaviour block`. +**Распознавание (`ignore`)** — первая стадия двухстадийной блокировки: лист со списком распознаваемых протоколов срабатывает, но трафик не трогает, а логи о распознанных сессиях уходят на SPFS и далее в ЦСУ ([разделы 22](protocol-blocking.md) и [14.10](filter-subsystems.md)). ЦСУ отсеивает ложные срабатывания и загружает очищенные списки в **другой** DPI-лист — с `behaviour block`. **Белый список.** Параметр `whitelist_mode` переключает лист из режима чёрного списка (по умолчанию: совпавшее блокируется, остальное пропускается) в режим белого: пропускается только совпавшее, всё остальное блокируется. В ТСПУ этот режим не используется — ошибка в таком листе может отрезать абонентам весь трафик; он нужен в других сценариях, например вместе с функциями BRAS. -**TCP Reset при блокировке протоколов (send RST).** Приложение (например, Telegram), получив TCP Reset в ответ на попытку соединения, тут же пытается соединиться снова — непрерывно и очень быстро, порождая огромное число сессий; наблюдались случаи, когда мобильные устройства абонентов из-за этого начинали тормозить. Поэтому отправку TCP Reset при блокировке протоколов можно отключить общим параметром модуля DPI send RST, и в ТСПУ он **всегда `off`**: попытка соединения просто отбрасывается, соединение висит и обрывается по тайм-ауту, и лавины новых сессий не возникает ([раздел 17.1.2](17.md)). В руководствах пользователя EcoSGE такого общего параметра нет; в более поздних версиях ПО блокировку без TCP Reset и без перенаправления задают для отдельного листа значением `behaviour drop`. +**TCP Reset при блокировке протоколов (send RST).** Приложение (например, Telegram), получив TCP Reset в ответ на попытку соединения, тут же пытается соединиться снова — непрерывно и очень быстро, порождая огромное число сессий; наблюдались случаи, когда мобильные устройства абонентов из-за этого начинали тормозить. Поэтому отправку TCP Reset при блокировке протоколов можно отключить общим параметром модуля DPI send RST, и в ТСПУ он **всегда `off`**: попытка соединения просто отбрасывается, соединение висит и обрывается по тайм-ауту, и лавины новых сессий не возникает ([раздел 17.1.2](filter-dpi.md)). В руководствах пользователя EcoSGE такого общего параметра нет; в более поздних версиях ПО блокировку без TCP Reset и без перенаправления задают для отдельного листа значением `behaviour drop`. -## 5.2. Работа на уровне L2: фильтр как «прозрачный провод» +## 10.2. Работа на уровне L2: фильтр как «прозрачный провод» -Хотя фильтр анализирует трафик вплоть до седьмого уровня модели OSI, в топологии сети он работает на **уровне L2**. Для оператора и его оборудования фильтр — **прозрачный провод**: кадры входят в один порт пары и выходят из парного, а изменения вносятся только в пакеты блокируемых сессий. Это обеспечивают несколько свойств и настроек; описание относится к подключению парами портов в ТСПУ тип А (о схеме on-a-stick — в [разделе 7.3.3](07.md)). +Хотя фильтр анализирует трафик вплоть до седьмого уровня модели OSI, в топологии сети он работает на **уровне L2**. Для оператора и его оборудования фильтр — **прозрачный провод**: кадры входят в один порт пары и выходят из парного, а изменения вносятся только в пакеты блокируемых сессий. Это обеспечивают несколько свойств и настроек; описание относится к подключению парами портов в ТСПУ тип А (о схеме on-a-stick — в [разделе 4.3.3](echelon.md)). -**Нет L3-интерфейсов в тракте.** В ОС Linux, на которой построен фильтр, виден только management-интерфейс. Порты тракта, как и лог-интерфейсы, отданы под управление **DPDK** (Data Plane Development Kit) и процессу EcoNAT, который обрабатывает пакеты напрямую, минуя сетевой стек ОС. IP-адресов у портов тракта нет: ping и traceroute с фильтра выполняются только через management-интерфейс ([раздел 18.14](18.md)), а собственного трафика в тракт фильтр (при выключенном LLDP — см. ниже) не инициирует. Исключение — пакеты, которые он вставляет в блокируемые сессии: перенаправление и TCP Reset, адресованные участникам сессии. +**Нет L3-интерфейсов в тракте.** В ОС Linux, на которой построен фильтр, виден только management-интерфейс. Порты тракта, как и лог-интерфейсы, отданы под управление **DPDK** (Data Plane Development Kit) и процессу EcoNAT, который обрабатывает пакеты напрямую, минуя сетевой стек ОС. IP-адресов у портов тракта нет: ping и traceroute с фильтра выполняются только через management-интерфейс ([раздел 18.14](filter-monitoring.md)), а собственного трафика в тракт фильтр (при выключенном LLDP — см. ниже) не инициирует. Исключение — пакеты, которые он вставляет в блокируемые сессии: перенаправление и TCP Reset, адресованные участникам сессии. **Заголовки инкапсуляции сохраняются.** VLAN-теги, MPLS-метки и другие заголовки фильтр не снимает и не меняет: он разбирает их только для того, чтобы найти IP-пакет, и все манипуляции выполняет с IP-пакетом. Кадр выходит из фильтра с тем же стеком заголовков, с каким вошёл, — включая 4-байтный заголовок балансировщика. -**Пересылка включена.** Параметр `forward_traffic` в `nat_defaults` (по умолчанию `on`) разрешает пересылку кадров через фильтр; значение `off` нужно, только когда фильтр анализирует зеркалированный трафик и обратно от него ничего не ждут. В ТСПУ фильтр стоит в разрыв, поэтому `forward_traffic` всегда `on`, а режим работы модуля DPI (`functionality_mode`) — обычный, для схемы «в разрыв», а не для зеркалированного трафика ([разделы 15.2.3](15.md) и [17.1.3](17.md)). +**Пересылка включена.** Параметр `forward_traffic` в `nat_defaults` (по умолчанию `on`) разрешает пересылку кадров через фильтр; значение `off` нужно, только когда фильтр анализирует зеркалированный трафик и обратно от него ничего не ждут. В ТСПУ фильтр стоит в разрыв, поэтому `forward_traffic` всегда `on`, а режим работы модуля DPI (`functionality_mode`) — обычный, для схемы «в разрыв», а не для зеркалированного трафика ([разделы 15.2.3](filter-interfaces.md) и [17.1.3](filter-dpi.md)). -**LLDP выключен.** По документации производителя LLDP на платформе по умолчанию включён: устройство периодически (в разных редакциях документации — раз в 30 или 60 секунд) рассылает LLDP-сообщения через все задействованные интерфейсы, и соседнее оборудование видит его в своей топологии. В ТСПУ LLDP выключают (`lldp off` в `nat_defaults`) по просьбе операторов связи: оборудование должно оставаться невидимым и не появляться на схемах их сети ([раздел 15.2.5](15.md)). +**LLDP выключен.** По документации производителя LLDP на платформе по умолчанию включён: устройство периодически (в разных редакциях документации — раз в 30 или 60 секунд) рассылает LLDP-сообщения через все задействованные интерфейсы, и соседнее оборудование видит его в своей топологии. В ТСПУ LLDP выключают (`lldp off` в `nat_defaults`) по просьбе операторов связи: оборудование должно оставаться невидимым и не появляться на схемах их сети ([раздел 15.2.5](filter-interfaces.md)). -**L2 MTU — 9216 байт.** Параметр `l2mtu` задаёт максимальный размер принимаемого Ethernet-кадра — с заголовками, но без контрольной суммы. Кадр длиннее этого значения фильтр не пропускает, а отбрасывает (такие потери видны в выводе `show interface <имя>` как «Packets droped because of L2MTU»). Значение по умолчанию — 1522 байта (в более поздних версиях ПО, по документации производителя, — 9216), максимум — 9692 байта. В ТСПУ ставят 9216 — распространённый предельный размер jumbo-кадра у сетевого оборудования; на портах балансировщиков MTU выставляют около 9000 байт. Для абонентского трафика этого хватает с большим запасом, тогда как при значении 1522 не прошёл бы уже 1500-байтный IP-пакет в QinQ-кадре с заголовком балансировщика (14 + 8 + 4 + 1500 = 1526 байт). Если же оператор передаёт jumbo-кадры, кадр вместе с 4-байтным заголовком должен укладываться и в L2 MTU фильтра, и в MTU портов балансировщика — это согласуют при проектировании ([раздел 4.5.3](04.md)). +**L2 MTU — 9216 байт.** Параметр `l2mtu` задаёт максимальный размер принимаемого Ethernet-кадра — с заголовками, но без контрольной суммы. Кадр длиннее этого значения фильтр не пропускает, а отбрасывает (такие потери видны в выводе `show interface <имя>` как «Packets droped because of L2MTU»). Значение по умолчанию — 1522 байта (в более поздних версиях ПО, по документации производителя, — 9216), максимум — 9692 байта. В ТСПУ ставят 9216 — распространённый предельный размер jumbo-кадра у сетевого оборудования; на портах балансировщиков MTU выставляют около 9000 байт. Для абонентского трафика этого хватает с большим запасом, тогда как при значении 1522 не прошёл бы уже 1500-байтный IP-пакет в QinQ-кадре с заголовком балансировщика (14 + 8 + 4 + 1500 = 1526 байт). Если же оператор передаёт jumbo-кадры, кадр вместе с 4-байтным заголовком должен укладываться и в L2 MTU фильтра, и в MTU портов балансировщика — это согласуют при проектировании ([раздел 6.5.3](balancer.md)). **`permit_invalid_flow` включён.** По умолчанию параметр выключен: TCP-сессия заводится только по пакету с флагом SYN, а TCP-пакеты без SYN, для которых сессии нет, считаются ошибочными или вредоносными и отбрасываются. Для NAT-устройства это нормальное поведение, для фильтра — опасное: он часто видит TCP-сессии не с начала, а «с середины»: -- **после возврата ТСПУ из байпаса в рабочий режим** — из аппаратного байпаса в Inline или из программного байпаса балансировщика, в том числе отдельной пары портов ([разделы 3.5](03.md) и [4.6.2](04.md)), — а также при первом включении в тракт на фильтры сразу приходит трафик множества уже установленных сессий, SYN которых фильтр не видел. С выключенным параметром фильтр будет его дропать: все эти TCP-сессии абонентов оборвутся по тайм-ауту, и их придётся устанавливать заново; -- **при перераспределении трафика** — когда балансировщик перебалансирует нагрузку и сессии переезжают на другой фильтр ([раздел 4.6.3](04.md)), а также после перезапуска фильтра, когда таблица сессий пуста; +- **после возврата ТСПУ из байпаса в рабочий режим** — из аппаратного байпаса в Inline или из программного байпаса балансировщика, в том числе отдельной пары портов ([разделы 5.5](bypass.md) и [6.6.2](balancer.md)), — а также при первом включении в тракт на фильтры сразу приходит трафик множества уже установленных сессий, SYN которых фильтр не видел. С выключенным параметром фильтр будет его дропать: все эти TCP-сессии абонентов оборвутся по тайм-ауту, и их придётся устанавливать заново; +- **при перераспределении трафика** — когда балансировщик перебалансирует нагрузку и сессии переезжают на другой фильтр ([раздел 6.6.3](balancer.md)), а также после перезапуска фильтра, когда таблица сессий пуста; - **при несимметричном трафике** — когда исходящий трафик сессии прошёл через одну площадку или один фильтр, а ответный — через другой: второй фильтр не видел SYN, с которого абонент начал соединение, и сессия там не заведётся; - **для долго молчащих TCP-соединений** (по документации производителя): когда сессия на фильтре удалена по тайм-ауту неактивности, следующий пакет соединения приходит уже без SYN. -Поэтому в ТСПУ параметр **всегда включён**: фильтр принимает пакеты «с середины» и заводит для них сессии. Параметр глобальный — действует на всё устройство и в пулах не переопределяется; изменение применяется командой `apply` ([раздел 15.2.6](15.md)). +Поэтому в ТСПУ параметр **всегда включён**: фильтр принимает пакеты «с середины» и заводит для них сессии. Параметр глобальный — действует на всё устройство и в пулах не переопределяется; изменение применяется командой `apply` ([раздел 15.2.6](filter-interfaces.md)). --- -[← Оглавление](../README.md) · [← Раздел 4: Балансировщик](04.md) · [Раздел 6: Места установки ТСПУ →](06.md) +[← Оглавление](../README.md) · [← Раздел 9: Балансировщик: мониторинг и диагностика](balancer-monitoring.md) · [Раздел 11: Фильтр: аппаратная платформа →](filter-platform.md) diff --git a/docs/management-segment.md b/docs/management-segment.md index c74ba8f..5a4728c 100644 --- a/docs/management-segment.md +++ b/docs/management-segment.md @@ -1,10 +1,10 @@ -# 10. Сегмент управления ТСПУ +# 20. Сегмент управления ТСПУ -[← Оглавление](../README.md) · [← Раздел 9: Центральная система управления](09.md) +[← Оглавление](../README.md) · [← Раздел 19: Фильтр: обновление прошивки](filter-firmware.md) --- -## 10.1. Адресация: 10.<регион>.<площадка>.0/24 +## 20.1. Адресация: 10.<регион>.<площадка>.0/24 Каждая площадка ТСПУ имеет собственный **сегмент управления** — выделенную подсеть для management-интерфейсов всех устройств. Адресация сегмента управления построена по единой схеме: @@ -21,7 +21,7 @@ Таким образом, для площадки в Москве management-адрес будет выглядеть как `10.77.<номер_площадки>.0/24`. -## 10.2. Распределение адресов: байпасы, балансировщики, BMC, фильтры, IPMI, SPFS, СПХД +## 20.2. Распределение адресов: байпасы, балансировщики, BMC, фильтры, IPMI, SPFS, СПХД Все 256 адресов подсети /24 распределяются между устройствами площадки по фиксированной схеме: @@ -57,7 +57,7 @@ - **SPFS** (.231–.235) — серверы предварительного формирования списков; - **СПХД** (.241–.245) — серверы предварительного хранения данных (syslog-серверы), используемые для хранения системных журналов со всех устройств площадки. -## 10.3. Шлюз по умолчанию — криптошлюз «Континент» +## 20.3. Шлюз по умолчанию — криптошлюз «Континент» Адрес **.254** в подсети управления закреплён за **криптошлюзом «Континент»**, который является **шлюзом по умолчанию** для всех устройств площадки. @@ -75,7 +75,7 @@ Каждая площадка ТСПУ связана **с обеими площадками ЦСУ** (основной и резервной), что обеспечивает отказоустойчивость управления. -## 10.4. Подсеть логирования (единая для всех ТСПУ) +## 20.4. Подсеть логирования (единая для всех ТСПУ) Помимо основной подсети управления (/24), в сегменте управления присутствует **отдельная подсеть логирования**. Эта подсеть используется для лог-интерфейсов фильтров — выделенных высокопроизводительных интерфейсов (DPDK), через которые передаются журналы соединений (connection log). @@ -85,4 +85,4 @@ --- -[← Оглавление](../README.md) · [← Раздел 9: Центральная система управления](09.md) · [Раздел 11: Фильтр: аппаратная платформа →](11.md) +[← Оглавление](../README.md) · [← Раздел 19: Фильтр: обновление прошивки](filter-firmware.md) · [Раздел 21: Центральная система управления →](central-management.md) diff --git a/docs/overview.md b/docs/overview.md index f6683c0..8093f44 100644 --- a/docs/overview.md +++ b/docs/overview.md @@ -13,7 +13,7 @@ - **ТСПУ** (технические средства противодействия угрозам) — комплексы оборудования, устанавливаемые непосредственно у операторов связи, в разрыв их каналов связи; - **Центральная система управления (ЦСУ)** — централизованная система, с которой взаимодействуют все ТСПУ и через которую выполняются основные операции по управлению их оборудованием: доступ к устройствам площадок, формирование и распространение списков фильтрации, мониторинг, логирование, централизованная установка программного обеспечения. -ЦСУ размещается в двух физически независимых ЦОД — на основной и резервной площадках — с резервированием. Связь площадок ТСПУ с ЦСУ организована через интернет по шифрованным VPN-каналам: каждая площадка ТСПУ связана как с основной, так и с резервной площадкой ЦСУ, а площадки ЦСУ связаны VPN-каналом между собой. На текущем этапе ЦСУ обслуживает порядка **350 площадок** ТСПУ и суммарно около **5 000 устройств**; в дальнейшем система будет расширяться (подробнее — в [разделах 9](09.md) и [10](10.md)). На схемах ЦСУ обозначается как **ЦСУО** — центральная система управления оборудованием. +ЦСУ размещается в двух физически независимых ЦОД — на основной и резервной площадках — с резервированием. Связь площадок ТСПУ с ЦСУ организована через интернет по шифрованным VPN-каналам: каждая площадка ТСПУ связана как с основной, так и с резервной площадкой ЦСУ, а площадки ЦСУ связаны VPN-каналом между собой. На текущем этапе ЦСУ обслуживает порядка **350 площадок** ТСПУ и суммарно около **5 000 устройств**; в дальнейшем система будет расширяться (подробнее — в [разделах 21](central-management.md) и [20](management-segment.md)). На схемах ЦСУ обозначается как **ЦСУО** — центральная система управления оборудованием. image @@ -36,16 +36,16 @@ _Общая схема АСБИ: центральная система упра ## 1.3. Что такое ТСПУ — комплекс оборудования у операторов связи -**ТСПУ** (Технические средства противодействия угрозам) — это комплекс оборудования, который устанавливается **в разрыв каналов связи оператора**: каналы оператора разрываются и заворачиваются на ТСПУ, а именно на его байпасы. Основные устройства ТСПУ — фильтры — выполняют фильтрацию и обработку проходящего трафика: распознавание протоколов средствами DPI (Deep Packet Inspection), фильтрацию по реестру Роскомнадзора, блокировку и деградацию протоколов (подробнее — в [разделах 5](05.md), [17](17.md) и [23](23.md)). +**ТСПУ** (Технические средства противодействия угрозам) — это комплекс оборудования, который устанавливается **в разрыв каналов связи оператора**: каналы оператора разрываются и заворачиваются на ТСПУ, а именно на его байпасы. Основные устройства ТСПУ — фильтры — выполняют фильтрацию и обработку проходящего трафика: распознавание протоколов средствами DPI (Deep Packet Inspection), фильтрацию по реестру Роскомнадзора, блокировку и деградацию протоколов (подробнее — в [разделах 10](filter.md), [17](filter-dpi.md) и [22](protocol-blocking.md)). -Ключевой принцип работы ТСПУ — **прозрачность для оператора**. Фильтры обрабатывают трафик на канальном уровне (L2) — на пути прохождения трафика нет L3-интерфейсов, а байпасы и балансировщики только передают его между парными портами. Поэтому для внешнего наблюдателя ТСПУ представляет собой «провод»: трафик, вошедший через определённый канал связи оператора, обязательно возвращается в тот же канал — ТСПУ не меняет прохождение пакетов по каналам оператора. По требованию операторов оборудование должно быть незаметно в их сети; поэтому, например, на фильтрах отключается протокол LLDP (подробнее — в [разделах 4.3.2](04.md), [5.2](05.md) и [15.2.5](15.md)). +Ключевой принцип работы ТСПУ — **прозрачность для оператора**. Фильтры обрабатывают трафик на канальном уровне (L2) — на пути прохождения трафика нет L3-интерфейсов, а байпасы и балансировщики только передают его между парными портами. Поэтому для внешнего наблюдателя ТСПУ представляет собой «провод»: трафик, вошедший через определённый канал связи оператора, обязательно возвращается в тот же канал — ТСПУ не меняет прохождение пакетов по каналам оператора. По требованию операторов оборудование должно быть незаметно в их сети; поэтому, например, на фильтрах отключается протокол LLDP (подробнее — в [разделах 6.3.2](balancer.md), [10.2](filter.md) и [15.2.5](filter-interfaces.md)). -ТСПУ может устанавливаться в нескольких различных местах сети оператора (подробнее — в [разделе 6](06.md)). На одной площадке оператора может быть развёрнуто различное количество оборудования в зависимости от количества каналов связи и объёма трафика — от двух-трёх фильтров на небольших площадках до полутора десятков на крупных. +ТСПУ может устанавливаться в нескольких различных местах сети оператора (подробнее — в [разделе 3](placement.md)). На одной площадке оператора может быть развёрнуто различное количество оборудования в зависимости от количества каналов связи и объёма трафика — от двух-трёх фильтров на небольших площадках до полутора десятков на крупных. Существует два типа ТСПУ: - **ТСПУ тип А** (первый эшелон) — основной тип, который используется практически везде. Под «ТСПУ» без уточнения типа подразумевается именно тип А; -- **ТСПУ тип Б** (второй эшелон, эшелонированная система) — устанавливается на уровне ядра сети крупных операторов для обработки трафика, который не прошёл через ТСПУ тип А; эшелоны позволяют сократить число ТСПУ, устанавливаемых у мелких операторов по всей стране (подробнее — в [разделе 7](07.md)). +- **ТСПУ тип Б** (второй эшелон, эшелонированная система) — устанавливается на уровне ядра сети крупных операторов для обработки трафика, который не прошёл через ТСПУ тип А; эшелоны позволяют сократить число ТСПУ, устанавливаемых у мелких операторов по всей стране (подробнее — в [разделе 4](echelon.md)). ## 1.4. Общая схема: байпасы, балансировщики, фильтры, сегмент управления @@ -75,7 +75,7 @@ _Состав ТСПУ. Слева — абоненты и оборудован - **LAN-порты** — смотрят в сторону абонентов (в сторону оборудования оператора, за которым находятся абоненты: BRAS, CGNAT и т. п.); - **WAN-порты** — смотрят в сторону интернета. -Как это разделение закреплено на портах фильтров и балансировщиков, описано в [разделах 2.2](02.md), [4.3](04.md) и [11.5](11.md). +Как это разделение закреплено на портах фильтров и балансировщиков, описано в [разделах 2.2](traffic-flow.md), [6.3](balancer.md) и [11.5](filter-platform.md). ### Байпасы @@ -83,11 +83,11 @@ _Состав ТСПУ. Слева — абоненты и оборудован Скорость байпаса зависит от модели и установленных модулей: как правило, это **10 или 100 Гбит/с**; площадок с гигабитными линками мало. После байпасов все каналы приходят на балансировщики. -Байпас — последнее средство сохранить трафик оператора при отказе ТСПУ: при обесточивании оборудования или при потере контроля пути через ТСПУ он замыкает каналы оператора напрямую, минуя остальные устройства ТСПУ (при обесточивании у оператора возможны флапы линков). Режимы работы байпасов, их отличия для проектов и переход на отечественные устройства описаны в [разделе 3](03.md). +Байпас — последнее средство сохранить трафик оператора при отказе ТСПУ: при обесточивании оборудования или при потере контроля пути через ТСПУ он замыкает каналы оператора напрямую, минуя остальные устройства ТСПУ (при обесточивании у оператора возможны флапы линков). Режимы работы байпасов, их отличия для проектов и переход на отечественные устройства описаны в [разделе 5](bypass.md). ### Балансировщики -Балансировщики — это **высокопроизводительные программируемые коммутаторы**, принимающие трафик от байпасов и распределяющие его по подключённым фильтрам. В ТСПУ тип А используется балансировщик **EcoFilter Balancer**, в эшелонированной системе — **Eco Highway** (см. [раздел 7](07.md)). +Балансировщики — это **высокопроизводительные программируемые коммутаторы**, принимающие трафик от байпасов и распределяющие его по подключённым фильтрам. В ТСПУ тип А используется балансировщик **EcoFilter Balancer**, в эшелонированной системе — **Eco Highway** (см. [раздел 4](echelon.md)). Основные характеристики: @@ -95,11 +95,11 @@ _Состав ТСПУ. Слева — абоненты и оборудован - пропускная способность — **3,2 Тбит/с**, практически на полной скорости при размере пакета более 160 байт; как правило, этой производительности хватает с большим запасом; - количество балансировщиков зависит от количества каналов связи и от объёма операторского трафика. -Подробно принципы балансировки описаны в [разделе 4](04.md), аппаратная платформа — в [разделе 20](20.md). +Подробно принципы балансировки описаны в [разделе 6](balancer.md), аппаратная платформа — в [разделе 7](balancer-platform.md). ### Фильтры -Фильтры (**EcoFilter**) — это **основные устройства ТСПУ**, занимающиеся непосредственно анализом и обработкой трафика. На фильтрах ТСПУ тип А выполняются распознавание протоколов, фильтрация по реестру Роскомнадзора, блокировка и деградация трафика (в эшелонированной системе блокировка по спискам выполняется на балансировщике Eco Highway — см. [раздел 7](07.md)). +Фильтры (**EcoFilter**) — это **основные устройства ТСПУ**, занимающиеся непосредственно анализом и обработкой трафика. На фильтрах ТСПУ тип А выполняются распознавание протоколов, фильтрация по реестру Роскомнадзора, блокировка и деградация трафика (в эшелонированной системе блокировка по спискам выполняется на балансировщике Eco Highway — см. [раздел 4](echelon.md)). Количество фильтров зависит **исключительно от объёма трафика**, который необходимо обрабатывать, а не от числа каналов оператора: @@ -110,7 +110,7 @@ _Состав ТСПУ. Слева — абоненты и оборудован Фильтры подключаются к балансировщикам преимущественно интерфейсами **10 Гбит/с Ethernet** (на отдельных площадках — 1 Гбит/с); интерфейсов 100 Гбит/с у фильтров проекта нет. Поэтому количество каналов между балансировщиком и фильтрами не совпадает с количеством операторских каналов и может быть достаточно велико. -Путь пакета через фильтр описан в [разделе 5](05.md), модельный ряд и аппаратная платформа — в [разделе 11](11.md). +Путь пакета через фильтр описан в [разделе 10](filter.md), модельный ряд и аппаратная платформа — в [разделе 11](filter-platform.md). ### Сегмент управления @@ -118,10 +118,10 @@ _Состав ТСПУ. Слева — абоненты и оборудован Вспомогательные серверы сегмента управления: -- **SPFS** (сервер предварительного формирования списков, на схемах — СПФС) — принимает с фильтров протокольные логи о распознанных сессиях и передаёт их в ЦСУ, где формируются списки блокировки (подробнее — в [разделе 8](08.md)); -- **СПХД** (сервер предварительного хранения данных) — хранит системные логи устройств площадки; используется в федеральном проекте (подробнее — в [разделе 14.8](14.md)). +- **SPFS** (сервер предварительного формирования списков, на схемах — СПФС) — принимает с фильтров протокольные логи о распознанных сессиях и передаёт их в ЦСУ, где формируются списки блокировки (подробнее — в [разделе 22](protocol-blocking.md)); +- **СПХД** (сервер предварительного хранения данных) — хранит системные логи устройств площадки; используется в федеральном проекте (подробнее — в [разделе 14.8](filter-subsystems.md)). -Адресация и устройство сегмента управления описаны в [разделе 10](10.md). +Адресация и устройство сегмента управления описаны в [разделе 20](management-segment.md). ### Простейший вариант ТСПУ @@ -137,8 +137,8 @@ _Простейший вариант ТСПУ: байпас и фильтр в В таком варианте балансировщик не требуется, поскольку весь трафик обрабатывается одним фильтром. Ограничение: могут быть подключены только каналы **1 или 10 Гбит/с** Ethernet, так как фильтры проекта не имеют интерфейсов 100 Гбит/с — только 1G и 10G в зависимости от модели. -В типовой конфигурации, в отличие от простейшей, присутствуют все компоненты: байпасы по количеству каналов оператора, один или несколько балансировщиков и необходимое по объёму трафика число фильтров. Балансировщики принимают трафик от байпасов, распределяют его по фильтрам, а обработанный трафик возвращают через тот же байпас в тот же канал оператора. Типовая схема и прохождение трафика через все участки ТСПУ подробно рассмотрены в [разделе 2](02.md). +В типовой конфигурации, в отличие от простейшей, присутствуют все компоненты: байпасы по количеству каналов оператора, один или несколько балансировщиков и необходимое по объёму трафика число фильтров. Балансировщики принимают трафик от байпасов, распределяют его по фильтрам, а обработанный трафик возвращают через тот же байпас в тот же канал оператора. Типовая схема и прохождение трафика через все участки ТСПУ подробно рассмотрены в [разделе 2](traffic-flow.md). --- -[← Оглавление](../README.md) · [Раздел 2: Прохождение трафика через ТСПУ →](02.md) +[← Оглавление](../README.md) · [Раздел 2: Прохождение трафика через ТСПУ →](traffic-flow.md) diff --git a/docs/placement.md b/docs/placement.md index 4616a5e..6bc329d 100644 --- a/docs/placement.md +++ b/docs/placement.md @@ -1,6 +1,6 @@ -# 6. Места установки ТСПУ в сети оператора +# 3. Места установки ТСПУ в сети оператора -[← Оглавление](../README.md) · [← Раздел 5: Фильтр](05.md) +[← Оглавление](../README.md) · [← Раздел 2: Прохождение трафика через ТСПУ](traffic-flow.md) --- @@ -16,7 +16,7 @@ Инкапсуляция на стыке оператора, в разрыв которого встаёт ТСПУ, зависит от технологий конкретного оператора и от места установки в его сети. Это могут быть чистые IP-пакеты, пакеты с VLAN-тегами (одним или двумя — QinQ), пакеты с MPLS-метками, PPPoE-пакеты и различные комбинации. ТСПУ должно уметь разбираться со всеми этими заголовками, чтобы добраться до IP-трафика и выполнить его обработку. -## 6.1. До BRAS/BPE/BNG (между абонентами и терминацией сессий) +## 3.1. До BRAS/BPE/BNG (между абонентами и терминацией сессий) Первая возможная точка установки — **между абонентами и устройствами терминации абонентских сессий**. Такими устройствами могут быть: @@ -29,15 +29,15 @@ При установке в этой точке ТСПУ располагается максимально близко к абонентам — до того, как трафик пройдёт через какую-либо обработку на стороне оператора. -### 6.1.1. Особенность: PPPoE-трафик +### 3.1.1. Особенность: PPPoE-трафик Основная особенность установки **до BRAS** — наличие **PPPoE-трафика**. Широкополосные абоненты подключаются к BRAS по протоколу PPPoE, и этот трафик представляет собой дополнительный уровень инкапсуляции, который необходимо обрабатывать. Важно: PPPoE-трафик существует **только на участке до BRAS**. Выше BRAS (то есть ближе к интернету) PPPoE-трафика в нормально функционирующих сетях не бывает — BRAS терминирует PPPoE-сессии и дальше передаёт обычные IP-пакеты. -Наличие PPPoE не является критической проблемой — это ещё один уровень инкапсуляции, который фильтру нужно разбирать. Однако его необходимо учитывать при настройке: VLAN-теги фильтр разбирает согласно параметру `vlan_mode` (в проекте — `qinq`), а для обработки самого PPPoE в документации производителя описан отдельный параметр `pppoe_analyzer` (по умолчанию выключен; подробнее — в [разделе 5.1.1](05.md)). +Наличие PPPoE не является критической проблемой — это ещё один уровень инкапсуляции, который фильтру нужно разбирать. Однако его необходимо учитывать при настройке: VLAN-теги фильтр разбирает согласно параметру `vlan_mode` (в проекте — `qinq`), а для обработки самого PPPoE в документации производителя описан отдельный параметр `pppoe_analyzer` (по умолчанию выключен; подробнее — в [разделе 10.1.1](filter.md)). -## 6.2. До CGNAT (после BRAS) — наиболее удобная точка +## 3.2. До CGNAT (после BRAS) — наиболее удобная точка Вторая точка установки — **между BRAS и CGNAT**. На этом участке BRAS уже терминировал абонентские сессии, но трафик ещё не прошёл трансляцию адресов (NAT). @@ -46,7 +46,7 @@ 1. **Отсутствие PPPoE** — трафик PPPoE уже терминирован на BRAS, что означает меньшее количество заголовков инкапсуляции для обработки; 2. **Видимость абонентских адресов** — серые (частные) IP-адреса абонентов ещё не прошли через NAT-трансляцию и доступны для анализа. -### 6.2.1. Видимость серых абонентских IP-адресов +### 3.2.1. Видимость серых абонентских IP-адресов На участке до CGNAT фильтры ТСПУ видят **серые** (частные) IP-адреса абонентов — те самые адреса, которые непосредственно назначены абонентским устройствам. Это даёт существенные преимущества при диагностике: @@ -56,11 +56,11 @@ Эта возможность особенно ценна при траблшутинге — прямая связь между физическим абонентом и его сессиями на ТСПУ значительно ускоряет поиск и устранение проблем. -## 6.3. После CGNAT (ближе к выходу в интернет) +## 3.3. После CGNAT (ближе к выходу в интернет) Третья точка установки — **после CGNAT**, ближе к выходу в общую сеть интернет. На этом участке трафик уже прошёл трансляцию адресов. -### 6.3.1. Только белые адреса, сложности траблшутинга +### 3.3.1. Только белые адреса, сложности траблшутинга После CGNAT серых абонентских адресов **больше не видно** — на фильтрах ТСПУ будут присутствовать только **белые** (публичные) IP-адреса из NAT-пула оператора. @@ -70,11 +70,11 @@ - Для идентификации абонента необходимо **взаимодействовать с оператором** — запрашивать у него информацию о том, в какие порты и IP-адреса был транслирован конкретный абонент на CGNAT; - Процесс диагностики становится **значительно более длительным** и требует координации между командой ТСПУ и оператором связи. -С точки зрения самой фильтрации (блокировки, распознавания протоколов) размещение после CGNAT не вносит каких-либо ограничений — функциональность ТСПУ остаётся полной. Основное неудобство касается диагностики и траблшутинга. Кроме того, за одним адресом NAT-пула стоит много абонентов, а балансировщик распределяет трафик по парам адресов, поэтому трафик многих абонентов к одному ресурсу попадает на одно ядро фильтра ([раздел 4.5.1](04.md)). +С точки зрения самой фильтрации (блокировки, распознавания протоколов) размещение после CGNAT не вносит каких-либо ограничений — функциональность ТСПУ остаётся полной. Основное неудобство касается диагностики и траблшутинга. Кроме того, за одним адресом NAT-пула стоит много абонентов, а балансировщик распределяет трафик по парам адресов, поэтому трафик многих абонентов к одному ресурсу попадает на одно ядро фильтра ([раздел 6.5.1](balancer.md)). > **Примечание:** в ряде случаев подсистемы BRAS и CGNAT могут быть **совмещены в одном устройстве**. В этом случае участок «между BRAS и CGNAT» (наиболее удобная точка установки) попросту отсутствует — ТСПУ может быть установлено либо до этого комбинированного устройства, либо после него. -## 6.4. Режим On-a-stick (BRAS/CGNAT подключены петлёй) +## 3.4. Режим On-a-stick (BRAS/CGNAT подключены петлёй) Помимо трёх линейных точек установки, существует особый вариант размещения ТСПУ — когда сервисное оборудование оператора (BRAS и/или CGNAT) подключено **в режиме on-a-stick** (петлёй). @@ -101,7 +101,7 @@ | **CGNAT on-a-stick** | Трафик до CGNAT + трафик после CGNAT (сегменты 2 + 3) | | **BRAS + CGNAT on-a-stick**| Трафик до обоих устройств + трафик после обоих (сегменты 1 + 3) | -### 6.4.1. Двойное прохождение трафика через ТСПУ +### 3.4.1. Двойное прохождение трафика через ТСПУ При подключении on-a-stick трафик проходит через ТСПУ **дважды**: @@ -110,7 +110,7 @@ Это означает, что каждая абонентская сессия потенциально **видна фильтрам дважды**, причём на втором проходе адреса могут быть уже другими (после NAT-трансляции на CGNAT). Без дополнительных мер это приводит к удвоению количества сессий и удвоению нагрузки на ТСПУ. -### 6.4.2. Разделение по VLAN для обработки трафика одного направления +### 3.4.2. Разделение по VLAN для обработки трафика одного направления **Наиболее удобная конфигурация** при подключении on-a-stick — когда оператор чётко разделяет трафик по VLAN: @@ -119,14 +119,14 @@ В этом случае на ТСПУ можно настроить обработку **только нужного VLAN** (например, трафика до CGNAT, где видны серые абонентские адреса), а второй VLAN — **прозрачно пропустить** на уровне балансировщика, даже не отправляя его на фильтры. -Это достигается через **flow rules** балансировщика (подробнее — в [разделе 4.4](04.md)): +Это достигается через **flow rules** балансировщика (подробнее — в [разделе 6.4](balancer.md)): - Правило с действием `balancing` — для VLAN, который нужно обрабатывать (трафик отправляется на фильтры); - Правило с действием `bypass` — для VLAN, который нужно пропустить (трафик прозрачно проходит через балансировщик). В результате фильтры обрабатывают трафик **только один раз**, каждый абонент виден единожды, путаницы с сессиями не возникает. -### 6.4.3. Проблемы двойной обработки и best practice +### 3.4.3. Проблемы двойной обработки и best practice Если оператор **не может** чётко отделить трафик до и после BRAS/CGNAT (например, оба направления идут в одном VLAN), возникает ситуация **двойной обработки**. Её последствия: @@ -142,4 +142,4 @@ --- -[← Оглавление](../README.md) · [← Раздел 5: Фильтр](05.md) · [Раздел 7: Эшелонированная система →](07.md) +[← Оглавление](../README.md) · [← Раздел 2: Прохождение трафика через ТСПУ](traffic-flow.md) · [Раздел 4: Эшелонированная система →](echelon.md) diff --git a/docs/protocol-blocking.md b/docs/protocol-blocking.md index ef32193..e63a607 100644 --- a/docs/protocol-blocking.md +++ b/docs/protocol-blocking.md @@ -1,18 +1,18 @@ -# 23. Распознавание протоколов (DPI Engine) +# 22. Распознавание протоколов и двухстадийная блокировка -[← Оглавление](../README.md) · [← Раздел 22: Балансировщик: мониторинг и диагностика](22.md) +[← Оглавление](../README.md) · [← Раздел 21: Центральная система управления](central-management.md) --- Распознавание протоколов — одна из ключевых функций фильтра ТСПУ. Внутренний движок DPI анализирует проходящие сессии и определяет, к какому протоколу или приложению они относятся: Telegram, WhatsApp, Viber, OpenVPN, BitTorrent и другие. Распознавание особенно важно для **шифрованного трафика**, где нет очевидных полей, указывающих на конкретный протокол, и идентификация выполняется **косвенным образом**. -## 23.1. Многофакторный анализ сессий +## 22.1. Многофакторный анализ сессий DPI-движок фильтра анализирует не отдельные пакеты, а **целые сессии**. Для распознавания необходимо, чтобы в рамках одной сессии прошло **несколько пакетов** в обоих направлениях — одного первого пакета недостаточно. Анализ проводится по **множеству параметров одновременно** — их может быть десяток и более. Совокупность этих параметров формирует уникальный «профиль» трафика конкретного протокола. -### 23.1.1. Размеры пакетов и их вариации +### 22.1.1. Размеры пакетов и их вариации Один из ключевых параметров анализа — **размеры пакетов** в рамках сессии и их **вариации**: @@ -22,7 +22,7 @@ DPI-движок фильтра анализирует не отдельные Разные протоколы и приложения генерируют пакеты с **характерными размерными профилями**. Например, голосовой трафик мессенджера будет иметь иной размерный профиль, чем передача файлов через тот же мессенджер. -### 23.1.2. Частота прохождения пакетов +### 22.1.2. Частота прохождения пакетов **Частота прохождения пакетов** — ещё один важный параметр: @@ -32,7 +32,7 @@ DPI-движок фильтра анализирует не отдельные Голосовые вызовы, например, генерируют поток пакетов с **регулярными короткими интервалами**, тогда как обмен текстовыми сообщениями создаёт **нерегулярный** трафик с длительными паузами. -### 23.1.3. Ключевые слова и паттерны внутри пакетов +### 22.1.3. Ключевые слова и паттерны внутри пакетов DPI-движок также анализирует **содержимое пакетов** — ищет характерные ключевые слова, последовательности байтов и структурные паттерны: @@ -42,7 +42,7 @@ DPI-движок также анализирует **содержимое пак Помимо очевидных параметров (source/destination IP, порты), анализируются **менее очевидные** признаки, которые в совокупности позволяют отнести сессию к конкретному протоколу. -### 23.1.4. Особенности анализа шифрованного трафика +### 22.1.4. Особенности анализа шифрованного трафика Шифрованный трафик представляет **особую сложность** для распознавания: @@ -54,7 +54,7 @@ DPI-движок также анализирует **содержимое пак > **Принцип работы:** DPI-движок берёт сессию (не один пакет, а несколько пакетов в обоих направлениях), анализирует их по множеству параметров и принимает решение — например, «данный трафик в этой сессии — это Telegram» или «это WhatsApp». -## 23.2. Ложноположительные срабатывания +## 22.2. Ложноположительные срабатывания Многофакторный анализ **не является стопроцентным** — возможны **ложноположительные срабатывания** (false positives), когда один шифрованный трафик по тем же косвенным критериям ошибочно распознаётся как другой протокол. @@ -68,9 +68,39 @@ DPI-движок также анализирует **содержимое пак **Последствия ложного срабатывания:** если фильтр ошибочно распознал легитимный трафик как блокируемый протокол и сразу заблокировал его — пользователь потеряет доступ к полезному ресурсу. Именно поэтому прямая блокировка по результатам DPI на фильтре **не применяется** для протоколов — вместо этого используется двухстадийная схема. -## 23.3. Двухстадийная блокировка: распознавание → очистка в ЦСУ → блокировка +## 22.3. Обфускация и борьба с обходом блокировок -Для минимизации ложноположительных срабатываний блокировка протоколов выполняется **в два этапа** (подробная схема — в [разделе 8](08.md)): +Обфускация — это намеренное изменение характеристик протокола, направленное на то, чтобы DPI-движок **не смог его распознать**. Это постоянная «гонка вооружений» между разработчиками средств обхода блокировок и разработчиками систем фильтрации. + +### Принцип «нанайских мальчиков» + +Борьба между системами обхода и системами блокировки описывается как **постоянное противостояние**: одна сторона в какой-то момент имеет преимущество, которое затем нивелируется следующим шагом противоположной стороны. + +### Типы обфускации и возможности распознавания + +| Тип обфускации | Возможность распознавания | +| ------------------------------------------- | ---------------------------------------------------------------------- | +| **Простая** (например, XOR) | Фильтр может «развернуть» обфускацию и распознать протокол | +| **Протокол притворяется другим** | Распознавание возможно, но требует разработки новых сигнатур и методик | +| **Качественная имитация другого протокола** | Распознать **невозможно** без разработки принципиально нового подхода | + +### Обновление сигнатур + +Когда обнаруживается, что новая версия приложения или протокола **перестала распознаваться** фильтром, это означает необходимость: + +1. **Анализа изменений** — что именно изменилось в новой версии протокола; +2. **Разработки новой сигнатуры** — обновление правил распознавания для учёта изменений; +3. **Обновления прошивки** — доставка обновлённого DPI-движка на фильтры. + +> **Практический подход:** к этому процессу следует относиться с пониманием — это нормальная и ожидаемая ситуация. Полное и постоянное распознавание всех протоколов **невозможно** в принципе. Задача системы — поддерживать актуальные сигнатуры и оперативно реагировать на изменения. + +### Защита от ложных блокировок при борьбе с обфускацией + +Двухстадийная система блокировки (раздел 22.4) особенно важна в контексте борьбы с обфускацией. Обфусцированный трафик **по определению** имеет нестандартный профиль, что повышает вероятность ложноположительного срабатывания. Централизованная очистка на ЦСУ снижает этот риск, сопоставляя данные с множества источников. + +## 22.4. Двухстадийная блокировка: распознавание → очистка в ЦСУ → блокировка + +Для минимизации ложноположительных срабатываний блокировка протоколов выполняется **в два этапа** (этапы подробно описаны ниже — в [разделах 22.5–22.10](#225-первый-этап-распознавание-протоколов-на-фильтрах-тспу-тип-а)): ```text ┌─────────────────────────────────────────────────────────────────┐ @@ -128,38 +158,155 @@ DPI-движок также анализирует **содержимое пак ### Время полного цикла -От момента появления нового, ранее неизвестного сервера блокируемого протокола до его фактической блокировки проходит **от 5 до 15 минут** (подробнее — в [разделе 8.6](08.md)). +От момента появления нового, ранее неизвестного сервера блокируемого протокола до его фактической блокировки проходит **от 5 до 15 минут** (подробнее — в [разделе 22.10](#2210-время-полного-цикла-блокировки-515-минут)). -## 23.4. Обфускация и борьба с обходом блокировок +## 22.5. Первый этап: распознавание протоколов на фильтрах (ТСПУ тип А) -Обфускация — это намеренное изменение характеристик протокола, направленное на то, чтобы DPI-движок **не смог его распознать**. Это постоянная «гонка вооружений» между разработчиками средств обхода блокировок и разработчиками систем фильтрации. +Блокировка протоколов (Telegram, WhatsApp, Viber и др.) в системе ТСПУ реализована **в два этапа** — так называемая двухстадийная блокировка. Необходимость двухстадийного подхода обусловлена природой распознавания шифрованного трафика: фильтр анализирует сессию по множеству косвенных признаков (размеры пакетов, частота прохождения, вариации размеров, ключевые слова внутри пакетов), и такое распознавание **не является стопроцентным**. Возможны ложноположительные срабатывания — когда другой шифрованный трафик по тем же критериям ошибочно распознаётся как, например, Telegram. Прямая блокировка по результатам DPI на фильтре привела бы к случайной блокировке легитимных ресурсов. -### Принцип «нанайских мальчиков» +На **первом этапе** фильтры ТСПУ тип А выполняют только **распознавание** протоколов, но **не блокируют** их: -Борьба между системами обхода и системами блокировки описывается как **постоянное противостояние**: одна сторона в какой-то момент имеет преимущество, которое затем нивелируется следующим шагом противоположной стороны. +1. Трафик проходит через фильтр и обрабатывается движком DPI; +2. DPI-движок анализирует каждую сессию по множеству параметров (многофакторный анализ) и определяет, к какому протоколу она относится; +3. Фильтр фиксирует результат распознавания в виде **протокольного лога** — записи о том, что конкретная сессия предварительно опознана как сессия определённого протокола; +4. Сессия при этом **не блокируется** — трафик продолжает проходить без ограничений. -### Типы обфускации и возможности распознавания +Распознавание выполняется в отдельном DPI-листе, на котором установлен режим **behavior: ignore** — это означает, что срабатывание правил фиксируется, но никаких блокирующих действий не предпринимается. Лист 0 для этого не используется: в нём по умолчанию работает фильтрация по реестру Роскомнадзора ([раздел 10.1.3](filter.md)). -| Тип обфускации | Возможность распознавания | -| ------------------------------------------- | ---------------------------------------------------------------------- | -| **Простая** (например, XOR) | Фильтр может «развернуть» обфускацию и распознать протокол | -| **Протокол притворяется другим** | Распознавание возможно, но требует разработки новых сигнатур и методик | -| **Качественная имитация другого протокола** | Распознать **невозможно** без разработки принципиально нового подхода | +## 22.6. Отправка логов на SPFS (сервер предварительного формирования списков) -### Обновление сигнатур +Протокольные логи с результатами распознавания отправляются с фильтров на **SPFS** (сервер предварительного формирования списков), расположенный на той же площадке ТСПУ. -Когда обнаруживается, что новая версия приложения или протокола **перестала распознаваться** фильтром, это означает необходимость: +Отправка настраивается в секции **debug logger** конфигурации фильтра: -1. **Анализа изменений** — что именно изменилось в новой версии протокола; -2. **Разработки новой сигнатуры** — обновление правил распознавания для учёта изменений; -3. **Обновления прошивки** — доставка обновлённого DPI-движка на фильтры. +- **Включение отправки** — секция активируется для нужных протоколов; +- **Выбор протоколов** — по умолчанию `all` (все распознаваемые протоколы), но можно указать только конкретные (Telegram, WhatsApp и т.д.); +- **Количество пакетов на протокол** — определяет, сколько пакетов из каждой распознанной сессии будет отправлено в лог. По умолчанию значение 0 (без ограничения, что соответствует первым 30 пакетам). На практике для корректного анализа достаточно **3 пакетов** — это значение было подтверждено в ходе тестов на Урале. Значение 30 генерирует избыточный объём лог-трафика; +- **Лог-интерфейс** — по умолчанию используется выделенный лог-интерфейс (DPDK). Возможно переключение на management-интерфейс, однако это **не рекомендуется**, так как производительность отправки логов значительно снизится; +- **Адрес и порт назначения** — указываются координаты сервера SPFS на площадке. -> **Практический подход:** к этому процессу следует относиться с пониманием — это нормальная и ожидаемая ситуация. Полное и постоянное распознавание всех протоколов **невозможно** в принципе. Задача системы — поддерживать актуальные сигнатуры и оперативно реагировать на изменения. +SPFS занимается **накоплением** поступающих протокольных логов со всех фильтров площадки и их **предварительной обработкой** перед отправкой в центральную систему управления. -### Защита от ложных блокировок при борьбе с обфускацией +## 22.7. Передача логов по GRPC в центральную систему управления -Двухстадийная система блокировки (раздел 23.3) особенно важна в контексте борьбы с обфускацией. Обфусцированный трафик **по определению** имеет нестандартный профиль, что повышает вероятность ложноположительного срабатывания. Централизованная очистка на ЦСУ снижает этот риск, сопоставляя данные с множества источников. +Накопленные и предварительно обработанные логи SPFS передаёт в **центральную систему управления (ЦСУ)** по протоколу **gRPC**. + +```text + ТСПУ тип А (площадка) Центральная система управления + ┌──────────────────────┐ ┌──────────────────────────┐ + │ │ │ │ + │ Фильтр 1 ──┐ │ │ Подсистема формирования │ + │ Фильтр 2 ──┼→ SPFS ├── gRPC ───→│ списков фильтрации │ + │ Фильтр N ──┘ │ │ │ + │ │ VPN │ • Сбор логов со всех │ + └──────────────────────┘ (Континент)│ площадок ТСПУ тип А │ + │ • Сохранение в БД │ + ТСПУ тип А (площадка) │ • Периодический анализ │ + ┌──────────────────────┐ │ • Формирование списков │ + │ │ │ │ + │ Фильтр 1 ──┐ │ └──────────────────────────┘ + │ Фильтр 2 ──┼→ SPFS ├── gRPC ───→ + │ Фильтр N ──┘ │ + │ │ + └──────────────────────┘ +``` + +ЦСУ представляет собой **многокомпонентную распределённую систему**, развёрнутую на двух независимых площадках. Связь между площадками ТСПУ и ЦСУ осуществляется через **VPN** (криптошлюз «Континент»). Данные поступают со **всех площадок** ТСПУ тип А по всей стране — это порядка 350 площадок и около 5 000 устройств. + +Протокольные логи отправляются **только с фильтров ТСПУ тип А** (первого эшелона). Фильтры ТСПУ тип Б (эшелон) протокольных логов **не генерируют** — на них отсутствует функционал распознавания протоколов, поскольку блокировка протоколов на эшелоне выполняется самим балансировщиком Eco Highway по уже готовым спискам. + +## 22.8. Анализ, очистка от ложных срабатываний, формирование списков + +Внутри ЦСУ за обработку протокольных логов отвечает **подсистема формирования списков фильтрации**. Эта подсистема выполняет несколько ключевых функций: + +**Сбор и хранение.** Логи со всех площадок ТСПУ тип А сохраняются в базе данных ЦСУ. Система агрегирует данные с множества фильтров, что даёт ей **значительно более полную картину**, чем та, которую видит каждый отдельный фильтр. + +**Периодический анализ.** С заданной периодичностью подсистема проводит анализ накопленных данных. Периодичность анализа — **настраиваемый параметр**: можно запускать анализ раз в минуту, раз в 5 минут и т.д. Более частый анализ требует большей производительности серверов. + +**Очистка от ложных срабатываний.** Ключевое преимущество централизованного анализа — возможность проведения **более глубокого анализа**, чем на отдельном фильтре: + +- **Сопоставление сессий с различных устройств** — ЦСУ видит данные с множества фильтров на разных площадках, а не только с одного конкретного. Это позволяет выявлять закономерности, недоступные на уровне единичного фильтра; +- **Статистический анализ** — использование накопленных статистических данных для верификации результатов распознавания; +- **Обогащение данных** — дополнение результатов распознавания сторонней информацией для повышения точности; +- **Выделение конкретных адресов** — на примере Telegram: из всех сессий, распознанных как Telegram, формируется список IP-адресов и портов, на которых были обнаружены серверы Telegram или его прокси различных типов. + +**Формирование очищенных списков.** По результатам анализа создаются **очищенные списки**, в которых вероятность ложноположительного срабатывания **крайне низка**. Эти списки содержат конкретные IP-адреса и порты (для каждого протокола — свой список), которые система с высокой степенью уверенности идентифицировала как принадлежащие блокируемому протоколу. + +## 22.9. Загрузка очищенных списков обратно на фильтры (HTTP) и на Eco Highway (BGP) + +Сформированные очищенные списки загружаются обратно на оборудование ТСПУ двумя путями: + +### Загрузка на фильтры ТСПУ тип А (по HTTP) + +Очищенные списки загружаются на фильтры по протоколу **HTTP** в **отдельный DPI-лист**, отличный от того, в котором выполняется распознавание: + +| DPI-лист | Назначение | Behavior | +|----------|-----------|----------| +| Лист распознавания | Распознавание протоколов (первый этап) | **ignore** — срабатывание фиксируется, но не блокируется | +| DPI-лист 5 (пример) | Блокировка по очищенным спискам из ЦСУ | **block** — трафик блокируется | + +Таким образом, на одном фильтре **одновременно работают два процесса**: +- в листе распознавания продолжается распознавание новых сессий и отправка логов; +- в DPI-листе 5 выполняется блокировка по уже проверенным и очищенным спискам. + +### Загрузка на Eco Highway (по BGP) + +Те же очищенные списки, но в **несколько ином формате**, загружаются по протоколу **BGP** на балансировщики **Eco Highway** (ТСПУ тип Б). На эшелоне блокировка протоколов выполняется **самим балансировщиком** по IP-адресам и портам — без участия фильтров. + +```text + Центральная система управления + ┌──────────────────────────────┐ + │ Очищенные списки │ + │ (IP + порт для каждого │ + │ протокола) │ + └───────┬──────────┬──────────┘ + │ │ + HTTP │ │ BGP + │ │ + ▼ ▼ + ┌───────────┐ ┌───────────┐ + │ Фильтры │ │ Eco │ + │ ТСПУ А │ │ Highway │ + │ │ │ ТСПУ Б │ + │ DPI-лист 5│ │ │ + │ behavior: │ │ Блокировка│ + │ block │ │ по L3/L4 │ + └───────────┘ └───────────┘ +``` + +Фильтры ТСПУ тип Б получают от Eco Highway только тот трафик, который требует URL-фильтрации по реестру РКН. Блокировка протоколов в прошивке фильтров эшелона **отсутствует** — она не нужна, поскольку этим занимается сам балансировщик. + +## 22.10. Время полного цикла блокировки: ~5–15 минут + +Полный цикл двухстадийной блокировки — от момента появления нового, ранее неизвестного сервера блокируемого протокола до его фактической блокировки — составляет **от 5 до 15 минут**. + +```text + ┌────────────────────────────────────────────────────────────────┐ + │ Полный цикл блокировки │ + │ │ + │ 1. Абонент подключается к новому серверу ─┐ │ + │ (например, новая Telegram-прокси) │ │ + │ │ ~5–15 мин │ + │ 2. Фильтр распознаёт протокол (DPI) │ │ + │ 3. Лог отправляется на SPFS │ │ + │ 4. SPFS передаёт в ЦСУ (gRPC) │ │ + │ 5. ЦСУ анализирует и формирует список │ │ + │ 6. Список загружается на фильтры (HTTP) │ │ + │ и Eco Highway (BGP) │ │ + │ 7. Блокировка активируется ─┘ │ + └────────────────────────────────────────────────────────────────┘ +``` + +Эти данные получены в ходе тестирования эшелонированной системы в тестовой зоне в Сургуте. Время полного цикла **зависит от настроек**: + +- **Периодичность анализа на ЦСУ** — чем чаще запускается анализ базы данных (например, раз в минуту вместо раз в 5 минут), тем быстрее формируются списки, но тем выше нагрузка на серверы; +- **Настройки SPFS** — параметры накопления и предварительной обработки логов; +- **Количество сессий по данному протоколу** — при большом количестве сессий (много абонентов используют блокируемый протокол) блокировка срабатывает быстрее, так как данных для анализа больше. + +**Важно:** до момента обновления списка фильтр **не обрывает** существующие сессии блокируемого протокола. Например, если появилась новая Telegram-прокси, которая ранее нигде не была зафиксирована, абонент может свободно работать через неё до тех пор, пока фильтр не получит обновлённый список, содержащий адрес этой прокси. + +Поскольку проект подобного масштаба реализуется впервые, текущие параметры основаны на эмпирических данных из тестовых сегментов. Не исключена корректировка параметров в ту или иную сторону по мере накопления опыта эксплуатации. Если серверы будут перегружаться, можно снизить частоту анализа — это увеличит время блокировки, но позволит существующим серверам справляться с нагрузкой. --- -[← Оглавление](../README.md) · [← Раздел 22: Балансировщик: мониторинг и диагностика](22.md) · [Раздел 24: Траблшутинг →](24.md) +[← Оглавление](../README.md) · [← Раздел 21: Центральная система управления](central-management.md) · [Раздел 23: Траблшутинг →](troubleshooting.md) diff --git a/docs/traffic-flow.md b/docs/traffic-flow.md index b22fadf..58719e6 100644 --- a/docs/traffic-flow.md +++ b/docs/traffic-flow.md @@ -1,6 +1,6 @@ # 2. Прохождение трафика через ТСПУ -[← Оглавление](../README.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md) +[← Оглавление](../README.md) · [← Раздел 1: Введение и общая архитектура АСБИ](overview.md) --- @@ -30,7 +30,7 @@ _Типовая схема ТСПУ: 1 — стык оператора (N × 10/ └─────────────────────────────────────────────┘ ``` -В обратном пакете (от ресурса к абоненту) source и destination меняются местами. Эта терминология (local/remote) используется далее во всей документации, в том числе при описании сессий на фильтре ([раздел 12](12.md)). +В обратном пакете (от ресурса к абоненту) source и destination меняются местами. Эта терминология (local/remote) используется далее во всей документации, в том числе при описании сессий на фильтре ([раздел 12](filter-sessions.md)). image @@ -38,7 +38,7 @@ _Стык оператора: адреса и порты в прямом и об ### Инкапсуляция на стыке оператора -На стыке оператора связи пакет может иметь различную дополнительную инкапсуляцию. Она зависит от технологий, применяемых конкретным оператором, от места в сети, куда устанавливается ТСПУ ([раздел 6](06.md)), и от других факторов. +На стыке оператора связи пакет может иметь различную дополнительную инкапсуляцию. Она зависит от технологий, применяемых конкретным оператором, от места в сети, куда устанавливается ТСПУ ([раздел 3](placement.md)), и от других факторов. Общая структура кадра Ethernet с учётом возможных дополнительных заголовков: @@ -60,7 +60,7 @@ _Стык оператора: адреса и порты в прямом и об | **MPLS** | Одна или несколько MPLS-меток | | **VLAN + MPLS** | VLAN-тег(и), за ними стек MPLS-меток | | **Ethernet поверх MPLS** | Внутри MPLS-меток — вложенный Ethernet-кадр со своими VLAN-тегами (псевдопровод EoMPLS, VPLS), и только затем IP | -| **PPPoE** | PPPoE-заголовок и PPP-заголовок перед IP; характерен для участка абонент → BRAS ([раздел 6.1](06.md)) | +| **PPPoE** | PPPoE-заголовок и PPP-заголовок перед IP; характерен для участка абонент → BRAS ([раздел 3.1](placement.md)) | | **PPPoE + MPLS** | PPPoE-кадр, в свою очередь упакованный в MPLS (например, перенос PPPoE до BRAS через псевдопровод) | Вариантов инкапсуляции в операторских сетях очень много, и перечислить их исчерпывающе невозможно — на стыке может встретиться практически что угодно. Ключевой момент: **ТСПУ должен уметь разбирать все эти заголовки**, чтобы добраться до IP-пакета и выполнить его анализ и обработку. Все манипуляции выполняются только с IP-пакетом; заголовки инкапсуляции, стоящие перед ним (VLAN-теги, MPLS-метки, PPPoE), ни балансировщик, ни фильтр не снимают и не модифицируют — пакет возвращается оператору с тем же стеком заголовков, с которым пришёл. Служебный заголовок, который балансировщик добавляет для передачи пакета фильтру внутри ТСПУ, снимается до возврата пакета оператору (см. [2.4](#24-типовая-схема-тспу)). Если IP-пакета в стеке заголовков не обнаружено, такой трафик пропускается прозрачно и на фильтры не отправляется. @@ -83,13 +83,13 @@ _Стык оператора: адреса и порты в прямом и об Эта идеология **прослеживается через всё оборудование ТСПУ** — от байпасов до балансировщиков и фильтров. Все порты на любом устройстве ТСПУ можно разделить на две группы: порты в сторону абонентов (LAN) и порты в сторону интернета (WAN). Порты всегда работают **парами** LAN + WAN: на байпасе это Net0/Net1 и Mon0/Mon1, на балансировщике — линки и группы портов, на фильтре — пары соседних интерфейсов. Ни LAN-, ни WAN-порты не имеют IP-адресов и не участвуют в маршрутизации. -На **фильтрах** разделение реализовано жёстко: интерфейсы нумеруются с единицы и объединены в пары соседних номеров (te1/te2, te3/te4 …), в каждой паре **чётный** порт — LAN, **нечётный** — WAN ([раздел 11.5](11.md)). На **балансировщиках** жёсткой привязки нет, но такое же разделение принято по договорённости при проектировании схем: чётные порты назначаются LAN-портами, нечётные — WAN-портами, причём как для портов в сторону оператора, так и для портов в сторону фильтров. Для 10-гигабитных портов чётность определяется по второй цифре номера (например, p4-2 — LAN, p4-1 — WAN), для 100-гигабитных — по единственной цифре (p10 — LAN, p9 — WAN); подробнее — в [разделе 4.3](04.md). +На **фильтрах** разделение реализовано жёстко: интерфейсы нумеруются с единицы и объединены в пары соседних номеров (te1/te2, te3/te4 …), в каждой паре **чётный** порт — LAN, **нечётный** — WAN ([раздел 11.5](filter-platform.md)). На **балансировщиках** жёсткой привязки нет, но такое же разделение принято по договорённости при проектировании схем: чётные порты назначаются LAN-портами, нечётные — WAN-портами, причём как для портов в сторону оператора, так и для портов в сторону фильтров. Для 10-гигабитных портов чётность определяется по второй цифре номера (например, p4-2 — LAN, p4-1 — WAN), для 100-гигабитных — по единственной цифре (p10 — LAN, p9 — WAN); подробнее — в [разделе 6.3](balancer.md). Этот принцип является основой для корректной обработки трафика: пакет, вошедший через определённый LAN-порт, после обработки обязательно выходит через парный ему WAN-порт (и наоборот). Устройства ТСПУ не изучают MAC-адреса и не ведут таблиц коммутации — кадр всегда передаётся строго в парный порт, поэтому для оборудования оператора ТСПУ неотличим от отрезка кабеля. ## 2.3. Простейший вариант ТСПУ (один байпас, один фильтр) -В минимальной конфигурации (см. также [раздел 1.4](01.md)) ТСПУ состоит всего из трёх компонентов: +В минимальной конфигурации (см. также [раздел 1.4](overview.md)) ТСПУ состоит всего из трёх компонентов: - **один байпас** — для одного-двух каналов связи оператора; - **один фильтр** — для обработки всего проходящего трафика; @@ -114,7 +114,7 @@ _Стык оператора: адреса и порты в прямом и об В таком варианте **балансировщик не нужен**, поскольку весь трафик обрабатывается одним фильтром и распределение по нескольким фильтрам не требуется. Порты байпаса Mon0 и Mon1 подключаются непосредственно к паре портов фильтра: Mon0 — к LAN-порту, Mon1 — к WAN-порту. Heartbeat-пакеты, которыми байпас проверяет канал до фильтра, в этой схеме доходят до фильтра; это служебные кадры, которые фильтр без обработки передаёт в парный порт, и контур проверки замыкается. -Ограничения этой схемы: могут быть подключены только каналы **1 Гбит/с** или **10 Гбит/с** Ethernet, поскольку фильтры проекта (модели 2020/2040 и 4080/4120/4160 — [раздел 11](11.md)) не имеют интерфейсов 100 Гбит/с — только 1G и 10G в зависимости от конкретной модели; пропускная способность ограничена одним фильтром, а при его отказе байпас замыкает канал, и трафик проходит без анализа. По техническому описанию производителя 2024 года интерфейсы 100GE (2 × QSFP28) есть только у более поздней старшей модели EcoFilter 5200 (см. [указатель оборудования](../tspu-equipment/README.md)). +Ограничения этой схемы: могут быть подключены только каналы **1 Гбит/с** или **10 Гбит/с** Ethernet, поскольку фильтры проекта (модели 2020/2040 и 4080/4120/4160 — [раздел 11](filter-platform.md)) не имеют интерфейсов 100 Гбит/с — только 1G и 10G в зависимости от конкретной модели; пропускная способность ограничена одним фильтром, а при его отказе байпас замыкает канал, и трафик проходит без анализа. По техническому описанию производителя 2024 года интерфейсы 100GE (2 × QSFP28) есть только у более поздней старшей модели EcoFilter 5200 (см. [указатель оборудования](../tspu-equipment/README.md)). ## 2.4. Типовая схема ТСПУ @@ -149,7 +149,7 @@ _Стык оператора: адреса и порты в прямом и об ### Этап 1: Байпас -Канал связи оператора физически разрывается и заводится на байпас: порты **Net0/Net1** смотрят в сторону оборудования оператора (LAN и WAN соответственно), порты **Mon0/Mon1** — в сторону балансировщика. В штатном режиме (Inline) байпас прозрачно пропускает трафик насквозь: Net0 → Mon0 в сторону балансировщика и Mon1 → Net1 обратно (и то же самое для другого направления). Байпас обеспечивает защиту канала: при потере heartbeat-контроля до балансировщика, при пропадании линков Mon или при обесточивании он замыкает линки напрямую, минуя остальное оборудование ТСПУ. У байпасов Silicom переключение между режимами Inline, TAP и Active Bypass для оператора безболезненно — теряются лишь пакеты, которые в момент переключения уже ушли в сторону балансировщика, но не успели вернуться (байпасы GL Sun пилотного проекта таких режимов не имеют и переключаются с флапом линка — [раздел 3.3](03.md)). +Канал связи оператора физически разрывается и заводится на байпас: порты **Net0/Net1** смотрят в сторону оборудования оператора (LAN и WAN соответственно), порты **Mon0/Mon1** — в сторону балансировщика. В штатном режиме (Inline) байпас прозрачно пропускает трафик насквозь: Net0 → Mon0 в сторону балансировщика и Mon1 → Net1 обратно (и то же самое для другого направления). Байпас обеспечивает защиту канала: при потере heartbeat-контроля до балансировщика, при пропадании линков Mon или при обесточивании он замыкает линки напрямую, минуя остальное оборудование ТСПУ. У байпасов Silicom переключение между режимами Inline, TAP и Active Bypass для оператора безболезненно — теряются лишь пакеты, которые в момент переключения уже ушли в сторону балансировщика, но не успели вернуться (байпасы GL Sun пилотного проекта таких режимов не имеют и переключаются с флапом линка — [раздел 5.3](bypass.md)). Байпас контролирует доступность канала до балансировщика служебными heartbeat-пакетами, которые отправляются из Mon0 и должны вернуться в Mon1 (и наоборот); до фильтров эти пакеты не доходят — балансировщик прозрачно заворачивает их обратно. Если heartbeat-пакеты перестают проходить, байпас автоматически переключает канал в режим TAP или Active Bypass. @@ -157,13 +157,13 @@ _Стык оператора: адреса и порты в прямом и об _Байпас: порты NET0/NET1 в сторону оператора, MON0/MON1 в сторону балансировщика, режимы passive/active bypass, TAP и Inline, контуры heartbeat MON0 → MON1 и MON1 → MON0 через балансировщик._ -Подробнее о режимах работы байпаса — в [разделе 3](03.md). +Подробнее о режимах работы байпаса — в [разделе 5](bypass.md). ### Этап 2: Балансировщик — линки и исключение служебного трафика Все порты балансировщика делятся на две группы: порты, подключённые через байпасы к оборудованию оператора, и порты, к которым подключены фильтры; и те и другие организованы парами LAN/WAN. По умолчанию никакой конфигурации в балансировщике нет — номера и назначение портов выбираются при проектировании конкретного узла, поэтому номера портов в примерах условны. -На входе в балансировщик порты в сторону оператора объединяются в **линки** — логические пары LAN + WAN. Пакет, вошедший в LAN-порт линка, после обработки всегда выходит через WAN-порт того же линка (и наоборот) и ни в какой другой порт попасть не может. Так ТСПУ не меняет прохождение пакетов по каналам оператора: пакет, отправленный оператором в конкретный канал, выходит из ТСПУ в продолжение того же канала, и трафик разных линков никогда не смешивается. Соблюдается также правило проектирования: все каналы одного агрегированного линка (LAG) оператора заводятся на один и тот же балансировщик — иначе прямое и обратное направления одной сессии, разнесённые оператором по разным каналам агрегата, могут попасть на разные балансировщики и, следовательно, на разные фильтры ([раздел 4.3.3](04.md)). +На входе в балансировщик порты в сторону оператора объединяются в **линки** — логические пары LAN + WAN. Пакет, вошедший в LAN-порт линка, после обработки всегда выходит через WAN-порт того же линка (и наоборот) и ни в какой другой порт попасть не может. Так ТСПУ не меняет прохождение пакетов по каналам оператора: пакет, отправленный оператором в конкретный канал, выходит из ТСПУ в продолжение того же канала, и трафик разных линков никогда не смешивается. Соблюдается также правило проектирования: все каналы одного агрегированного линка (LAG) оператора заводятся на один и тот же балансировщик — иначе прямое и обратное направления одной сессии, разнесённые оператором по разным каналам агрегата, могут попасть на разные балансировщики и, следовательно, на разные фильтры ([раздел 6.3.3](balancer.md)). К каждому линку привязаны **правила** (flow rules) балансировщика — они применяются в порядке приоритетов, и возможных действий два: отправить трафик в группу балансировки, то есть на фильтры, или прямо на входе вернуть его оператору через парный порт линка (действие bypass; не путать с устройством «байпас»). Возвращаются без анализа, как правило: @@ -172,7 +172,7 @@ _Байпас: порты NET0/NET1 в сторону оператора, MON0/M - служебный трафик оператора, выделенный, например, в отдельный VLAN; - прочий трафик, который не нужно и нежелательно анализировать. -С таким трафиком на фильтрах ничего плохого произойти не должно, но лучше его не трогать: анализировать его бессмысленно, а служебные протоколы чувствительны к задержкам и потерям. Условия правил могут включать VLAN-теги, количество MPLS-меток, IP-адреса, L4-порты и MAC-адреса: например, если известно, что в VLAN 1 идёт служебный трафик оператора, его можно вернуть оператору целиком. Отбор по MPLS-меткам технически возможен, но практического смысла не имеет. Сами теги и метки балансировщик при этом не снимает: на фильтр пакет уходит с тем же набором меток. Настройка правил описана в [разделе 21.7](21.md). +С таким трафиком на фильтрах ничего плохого произойти не должно, но лучше его не трогать: анализировать его бессмысленно, а служебные протоколы чувствительны к задержкам и потерям. Условия правил могут включать VLAN-теги, количество MPLS-меток, IP-адреса, L4-порты и MAC-адреса: например, если известно, что в VLAN 1 идёт служебный трафик оператора, его можно вернуть оператору целиком. Отбор по MPLS-меткам технически возможен, но практического смысла не имеет. Сами теги и метки балансировщик при этом не снимает: на фильтр пакет уходит с тем же набором меток. Настройка правил описана в [разделе 8.7](balancer-config.md). image @@ -188,7 +188,7 @@ _Логика балансировщика: порты в сторону опе Балансировщик разбирает стек заголовков (VLAN, MPLS и т. д.) и вычисляет хэш именно от IP-пакета, найденного под инкапсуляцией. Если IP-пакета в стеке нет, трафик пропускается прозрачно и на фильтры не отправляется. -При вычислении хэша учитывается также число обрабатывающих ядер фильтра (все ядра процессора, кроме одного сервисного, — параметр `nat-unit-queues`), поэтому результат однозначно определяет не только пару портов, но и конкретное **ядро фильтра**, которое будет обрабатывать пакет, — трафик сразу равномерно распределяется по всем ядрам ([раздел 4.5.2](04.md), [21.5.2](21.md)). Балансировка выполняется аппаратно, программируемым чипом, и не логируется: узнать, на какой фильтр попала конкретная сессия, можно только поиском на фильтрах ([раздел 24.2](24.md)). +При вычислении хэша учитывается также число обрабатывающих ядер фильтра (все ядра процессора, кроме одного сервисного, — параметр `nat-unit-queues`), поэтому результат однозначно определяет не только пару портов, но и конкретное **ядро фильтра**, которое будет обрабатывать пакет, — трафик сразу равномерно распределяется по всем ядрам ([раздел 6.5.2](balancer.md), [8.5.2](balancer-config.md)). Балансировка выполняется аппаратно, программируемым чипом, и не логируется: узнать, на какой фильтр попала конкретная сессия, можно только поиском на фильтрах ([раздел 23.2](troubleshooting.md)). Для передачи информации о балансировке к пакету добавляется **дополнительный 4-байтовый заголовок** (по структуре похож на VLAN-тег, но таковым не является). Этот заголовок сообщает фильтру, на какое ядро направить пакет. После обработки фильтр возвращает пакет с тем же 4-байтовым заголовком, по нему балансировщик определяет, в какой именно операторский линк вернуть пакет, и снимает заголовок перед отправкой оператору. Так достигается корректное прохождение трафика: пакет, пришедший из конкретного порта оператора, возвращается в тот же порт независимо от того, каким фильтром он был обработан. @@ -198,9 +198,9 @@ _Логика балансировщика: порты в сторону опе - более того — на одну и ту же пару портов и на одно и то же **ядро** этого фильтра; - сессия никогда не распределяется по разным фильтрам, поэтому её всегда можно собрать и проанализировать на одном устройстве. -Распределение детерминировано, пока состав группы не меняется; при включённой перебалансировке после отказа группы портов хэш пересчитывается, и часть сессий переезжает на другие фильтры ([раздел 4.6.3](04.md)). Обратная сторона принципа: одна сессия не может быть разбалансирована. Если, например, 200 Гбит/с трафика идут с одного адреса источника на один адрес назначения по одному протоколу, весь этот поток попадёт на один порт одного фильтра и даже на одно его ядро. Равномерная балансировка опирается на то, что в операторском трафике огромное количество разных сессий. +Распределение детерминировано, пока состав группы не меняется; при включённой перебалансировке после отказа группы портов хэш пересчитывается, и часть сессий переезжает на другие фильтры ([раздел 6.6.3](balancer.md)). Обратная сторона принципа: одна сессия не может быть разбалансирована. Если, например, 200 Гбит/с трафика идут с одного адреса источника на один адрес назначения по одному протоколу, весь этот поток попадёт на один порт одного фильтра и даже на одно его ядро. Равномерная балансировка опирается на то, что в операторском трафике огромное количество разных сессий. -Отказоустойчивость на этом участке обеспечивает сам балансировщик — это второй, независимый от heartbeat байпаса (этап 1) контур контроля: в каждую пару портов в сторону фильтра он отправляет keep-alive-пакеты (через LAN-порт, с возвратом через WAN-порт), и если они перестают проходить — порт фильтра или сам фильтр перестал обрабатывать трафик, — трафик этой группы портов программно байпасится, то есть возвращается оператору без обработки, либо, в зависимости от настроек, перебалансируется на рабочие группы. В проекте перебалансировку предполагается отключить — тогда на время недоступности группы её трафик проходит без анализа. Подробнее — в [разделе 4.6](04.md). +Отказоустойчивость на этом участке обеспечивает сам балансировщик — это второй, независимый от heartbeat байпаса (этап 1) контур контроля: в каждую пару портов в сторону фильтра он отправляет keep-alive-пакеты (через LAN-порт, с возвратом через WAN-порт), и если они перестают проходить — порт фильтра или сам фильтр перестал обрабатывать трафик, — трафик этой группы портов программно байпасится, то есть возвращается оператору без обработки, либо, в зависимости от настроек, перебалансируется на рабочие группы. В проекте перебалансировку предполагается отключить — тогда на время недоступности группы её трафик проходит без анализа. Подробнее — в [разделе 6.6](balancer.md). ### Этап 4: Обработка на фильтре @@ -208,13 +208,13 @@ _Логика балансировщика: порты в сторону опе 1. **Проверка: IP-пакет или нет.** После разбора инкапсуляции фильтр проверяет, есть ли внутри IPv4- или IPv6-пакет. Не-IP кадры без какой-либо обработки выводятся в парный порт; в типовой схеме до фильтра из не-IP трафика доходят практически только keep-alive-пакеты балансировщика, которые таким образом возвращаются балансировщику. -2. **Проверка по ACL.** ACL на фильтре задают, какой трафик подлежит анализу, и привязаны к пулу — логической сущности, в которую попадает отобранный трафик для дальнейшей обработки ([раздел 16](16.md)). Пакет, не попавший ни в один пул (ни одно разрешающее правило ACL его не отобрало), анализу не подлежит и прозрачно передаётся в парный порт. +2. **Проверка по ACL.** ACL на фильтре задают, какой трафик подлежит анализу, и привязаны к пулу — логической сущности, в которую попадает отобранный трафик для дальнейшей обработки ([раздел 16](filter-acl-pools.md)). Пакет, не попавший ни в один пул (ни одно разрешающее правило ACL его не отобрало), анализу не подлежит и прозрачно передаётся в парный порт. -3. **Проверка по DPI-листу.** В DPI-листе указаны IP-подсети и адреса, подлежащие проверке ([раздел 17.4](17.md)). Если IP-адреса пакета не попадают в обработку DPI-листа — пакет прозрачно пропускается. +3. **Проверка по DPI-листу.** В DPI-листе указаны IP-подсети и адреса, подлежащие проверке ([раздел 17.4](filter-dpi.md)). Если IP-адреса пакета не попадают в обработку DPI-листа — пакет прозрачно пропускается. -4. **Обработка движком DPI.** Только пакеты, прошедшие все предыдущие проверки, попадают на анализ DPI-движком. По результатам анализа принимается решение: пропустить пакет либо отбросить его (drop), если он попадает под запрещающие политики; при блокировке ресурса абоненту дополнительно отправляется HTTP-редирект (для HTTP) или TCP Reset (для HTTPS) ([раздел 17.4.4](17.md); особенности для трафика с MPLS — см. ниже). +4. **Обработка движком DPI.** Только пакеты, прошедшие все предыдущие проверки, попадают на анализ DPI-движком. По результатам анализа принимается решение: пропустить пакет либо отбросить его (drop), если он попадает под запрещающие политики; при блокировке ресурса абоненту дополнительно отправляется HTTP-редирект (для HTTP) или TCP Reset (для HTTPS) ([раздел 17.4.4](filter-dpi.md); особенности для трафика с MPLS — см. ниже). -Глубина разбора инкапсуляции на фильтре задаётся настройкой (параметр `vlan_mode`, в проекте всегда `qinq` — [раздел 15.2.1](15.md)); ограничения фильтра по типам инкапсуляции несколько строже, чем у балансировщика. +Глубина разбора инкапсуляции на фильтре задаётся настройкой (параметр `vlan_mode`, в проекте всегда `qinq` — [раздел 15.2.1](filter-interfaces.md)); ограничения фильтра по типам инкапсуляции несколько строже, чем у балансировщика. Фильтр работает на уровне **L2**: в тракте передачи трафика у него нет L3-интерфейсов, он не является ни маршрутизатором, ни коммутатором и всегда передаёт кадр строго в парный порт. С точки зрения сети оператора фильтр представляет собой **«прозрачный провод»**: все заголовки инкапсуляции (VLAN-теги, MPLS-метки и т. д.) проходят через фильтр без изменений. Фильтр разбирает стек заголовков только для того, чтобы добраться до IP-пакета и выполнить анализ; пропускаемый трафик покидает фильтр в неизменном виде, изменения вносятся только в пакеты блокируемых сессий (drop, подмена на HTTP-редирект или TCP Reset). @@ -224,14 +224,14 @@ _Логика балансировщика: порты в сторону опе _Путь пакета через фильтр: вход через LAN-порт (te2), проверки «IP-пакет?», «попадает в pool/ACL?», «попадает в обработку DPI?», затем DPI с решением pass/drop; выход через парный WAN-порт (te1)._ -Подробнее путь пакета через фильтр описан в [разделе 5](05.md). +Подробнее путь пакета через фильтр описан в [разделе 10](filter.md). ### Особенность: HTTP-редирект и TCP Reset при наличии MPLS -Особый случай — блокировка трафика с MPLS-метками, когда фильтру нужно отправить абоненту **HTTP-редирект** (перенаправление на страницу-заглушку; по документации производителя — ответ «307 Temporary Redirect») при блокировке HTTP-ресурса или **TCP Reset** при блокировке HTTPS-ресурса ([раздел 17.4](17.md)). Фильтр не может просто сформировать такой пакет сам: MPLS-путь однонаправлен, и метки, с которыми пришёл пакет абонента, действительны только для направления в сторону интернета — стек меток обратного направления фильтру неизвестен. +Особый случай — блокировка трафика с MPLS-метками, когда фильтру нужно отправить абоненту **HTTP-редирект** (перенаправление на страницу-заглушку; по документации производителя — ответ «307 Temporary Redirect») при блокировке HTTP-ресурса или **TCP Reset** при блокировке HTTPS-ресурса ([раздел 17.4](filter-dpi.md)). Фильтр не может просто сформировать такой пакет сам: MPLS-путь однонаправлен, и метки, с которыми пришёл пакет абонента, действительны только для направления в сторону интернета — стек меток обратного направления фильтру неизвестен. -Поэтому для трафика с MPLS-метками фильтр пропускает запрос абонента к ресурсу как есть, дожидается первого ответного пакета той же сессии — он приходит уже с корректными метками обратного направления — и подставляет вместо его содержимого HTTP-редирект (для HTTP) или TCP Reset (для HTTPS: подменить зашифрованный ответ нельзя, ресурс определяется по SNI в ClientHello — [раздел 17.5.3](17.md)), сохраняя метки. Модифицированный пакет доставляется абоненту с корректной инкапсуляцией, и блокировка срабатывает штатно. Для QUIC (UDP/443) TCP Reset неприменим — это UDP-протокол; распознавание QUIC на фильтре включается отдельным списком ресурсов ([раздел 17.4.9](17.md)). Подробнее механизм описан в [разделе 4.8](04.md). +Поэтому для трафика с MPLS-метками фильтр пропускает запрос абонента к ресурсу как есть, дожидается первого ответного пакета той же сессии — он приходит уже с корректными метками обратного направления — и подставляет вместо его содержимого HTTP-редирект (для HTTP) или TCP Reset (для HTTPS: подменить зашифрованный ответ нельзя, ресурс определяется по SNI в ClientHello — [раздел 17.5.3](filter-dpi.md)), сохраняя метки. Модифицированный пакет доставляется абоненту с корректной инкапсуляцией, и блокировка срабатывает штатно. Для QUIC (UDP/443) TCP Reset неприменим — это UDP-протокол; распознавание QUIC на фильтре включается отдельным списком ресурсов ([раздел 17.4.9](filter-dpi.md)). Подробнее механизм описан в [разделе 6.8](balancer.md). --- -[← Оглавление](../README.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md) · [Раздел 3: Байпас →](03.md) +[← Оглавление](../README.md) · [← Раздел 1: Введение и общая архитектура АСБИ](overview.md) · [Раздел 3: Места установки ТСПУ →](placement.md) diff --git a/docs/troubleshooting.md b/docs/troubleshooting.md index 4a11d56..3c38e77 100644 --- a/docs/troubleshooting.md +++ b/docs/troubleshooting.md @@ -1,12 +1,12 @@ -# 24. Траблшутинг +# 23. Траблшутинг -[← Оглавление](../README.md) · [← Раздел 23: Распознавание протоколов (DPI Engine)](23.md) +[← Оглавление](../README.md) · [← Раздел 22: Распознавание протоколов и двухстадийная блокировка](protocol-blocking.md) --- Диагностика проблем на ТСПУ — комплексная задача, требующая понимания архитектуры системы, принципов прохождения трафика и взаимодействия компонентов. В данном разделе описаны типовые подходы к траблшутингу, которые применяются при обращениях операторов связи и абонентов. -## 24.1. Общий подход к диагностике проблем доступности +## 23.1. Общий подход к диагностике проблем доступности При обращении оператора или абонента с жалобой на недоступность ресурса необходимо последовательно пройти несколько шагов: @@ -46,11 +46,11 @@ **Если проблема существует прямо сейчас** — шансы на успешную диагностику значительно выше. В этом случае важно работать **в реальном времени** совместно с абонентом или оператором. -## 24.2. Поиск сессии абонента: обход фильтров площадки +## 23.2. Поиск сессии абонента: обход фильтров площадки Первый практический шаг — **найти сессии** конкретного абонента к конкретному ресурсу на фильтрах площадки. -Балансировщик не ведёт журнала распределения и не сообщает, на какой фильтр отправлена сессия ([раздел 4.5.4](04.md)), поэтому поиск выполняется на каждом фильтре площадки — вручную или простым скриптом. Оба направления сессии всегда находятся на одном и том же фильтре. +Балансировщик не ведёт журнала распределения и не сообщает, на какой фильтр отправлена сессия ([раздел 6.5.4](balancer.md)), поэтому поиск выполняется на каждом фильтре площадки — вручную или простым скриптом. Оба направления сессии всегда находятся на одном и том же фильтре. ### Поиск по локальному адресу @@ -88,13 +88,13 @@ | Сессии **не найдены ни на одном фильтре** | Трафик абонента не проходит через ТСПУ — абонент идёт другим путём, либо проблема до ТСПУ | | Сессии есть, но ресурс недоступен | Возможна блокировка на уровне DPI — проверить DPI-листы | -> **Важно:** при поиске сессий помните принцип «локальный адрес всегда на первом месте» (см. [раздел 12](12.md)). Независимо от направления трафика, IP-адрес абонента записывается в поле local. Если в поле local отображаются адреса, которые не являются абонентскими (интернет-адреса), — это признак перепутки LAN/WAN (см. раздел 24.6). +> **Важно:** при поиске сессий помните принцип «локальный адрес всегда на первом месте» (см. [раздел 12](filter-sessions.md)). Независимо от направления трафика, IP-адрес абонента записывается в поле local. Если в поле local отображаются адреса, которые не являются абонентскими (интернет-адреса), — это признак перепутки LAN/WAN (см. раздел 23.6). ### Особенности при установке после CGNAT -Если ТСПУ установлен **после CGNAT** (см. [раздел 6.3](06.md)), на фильтре видны только белые (транслированные) адреса. Для идентификации конкретного абонента необходимо **взаимодействие с оператором** — оператор должен сообщить, в какие порты и IP-адреса абонент был транслирован. +Если ТСПУ установлен **после CGNAT** (см. [раздел 3.3](placement.md)), на фильтре видны только белые (транслированные) адреса. Для идентификации конкретного абонента необходимо **взаимодействие с оператором** — оператор должен сообщить, в какие порты и IP-адреса абонент был транслирован. -## 24.3. Проверка ресурса в DPI-листах: `show dpi match` +## 23.3. Проверка ресурса в DPI-листах: `show dpi match` Команда `show dpi match` позволяет проверить, находится ли конкретный ресурс в списках блокировки: @@ -117,13 +117,13 @@ Если необходимо проверить наличие ресурса в списках, загруженных на **Eco Highway** (эшелонированная система), проверку следует выполнять **через центральную систему управления** — там хранятся все списки, загружаемые по BGP. -## 24.4. Программный байпас для исключения ТСПУ как причины проблемы +## 23.4. Программный байпас для исключения ТСПУ как причины проблемы Один из ключевых методов диагностики — **исключение ТСПУ** из пути прохождения трафика, чтобы определить, является ли ТСПУ причиной проблемы. ### Программный bypass на балансировщике -Наиболее удобный способ — программный bypass на балансировщике (см. [раздел 22.7](22.md)): +Наиболее удобный способ — программный bypass на балансировщике (см. [раздел 9.7](balancer-monitoring.md)): ```text call ecofilter-balancer set-bypass-ecofilter-unit unit <группа> bypass @@ -132,7 +132,7 @@ Преимущества: - **Нет флапов линков** — оператор ничего не замечает; -- **Гранулярность** — отдельные filter groups байпасятся автоматически по keep-alive, вручную переключается группа балансировки целиком ([раздел 4.6.2](04.md)); +- **Гранулярность** — отдельные filter groups байпасятся автоматически по keep-alive, вручную переключается группа балансировки целиком ([раздел 6.6.2](balancer.md)); - **Мгновенность** — переключение происходит немедленно. ### Bypass по правилам фильтрации (flow rules) @@ -146,11 +146,11 @@ apply ``` -Это позволяет исключить из обработки только **конкретный VLAN** или подсеть, не затрагивая остальной трафик. По статистике правила (пакеты/байты) можно убедиться, что трафик действительно проходит (см. [раздел 22.5](22.md)). +Это позволяет исключить из обработки только **конкретный VLAN** или подсеть, не затрагивая остальной трафик. По статистике правила (пакеты/байты) можно убедиться, что трафик действительно проходит (см. [раздел 9.5](balancer-monitoring.md)). ### Bypass на оптическом байпасе -Переключение на самом байпасе — более радикальный метод: он полностью снимает канал с фильтрации. У байпасов **Silicom** перевод сегмента в TAP или Active Bypass выполняется **без флапа линков** оператора — теряются лишь пакеты, находившиеся в этот момент внутри ТСПУ (см. [раздел 3.2.6](03.md)). У оптических байпасов **GL Sun** любое переключение **вызывает флапы линков** и, как правило, требует согласования с оператором (см. [раздел 3.3.2](03.md)). +Переключение на самом байпасе — более радикальный метод: он полностью снимает канал с фильтрации. У байпасов **Silicom** перевод сегмента в TAP или Active Bypass выполняется **без флапа линков** оператора — теряются лишь пакеты, находившиеся в этот момент внутри ТСПУ (см. [раздел 5.2.6](bypass.md)). У оптических байпасов **GL Sun** любое переключение **вызывает флапы линков** и, как правило, требует согласования с оператором (см. [раздел 5.3.2](bypass.md)). ### Интерпретация результатов @@ -159,9 +159,9 @@ | Проблема **исчезла** | ТСПУ являлось причиной — диагностировать дальше на уровне фильтров/DPI | | Проблема **осталась** | ТСПУ не является причиной — проблема на стороне ресурса, оператора или абонента | -## 24.5. Исключение абонента из обработки: параметр No IP +## 23.5. Исключение абонента из обработки: параметр No IP -Для точечной диагностики на уровне **конкретного абонента** используется параметр **No IP** в настройках DPI-листа (см. [раздел 17.4.8](17.md)). +Для точечной диагностики на уровне **конкретного абонента** используется параметр **No IP** в настройках DPI-листа (см. [раздел 17.4.8](filter-dpi.md)). ### No IP (исключение по локальному адресу) @@ -212,7 +212,7 @@ После завершения диагностики необходимо **удалить** добавленные записи No IP и применить конфигурацию. -## 24.6. Перепутки LAN/WAN и их диагностика +## 23.6. Перепутки LAN/WAN и их диагностика **Перепутка LAN/WAN** — ситуация, когда порты LAN и WAN подключены **наоборот**: LAN-порт подключён в сторону интернета, а WAN-порт — в сторону абонентов. @@ -225,7 +225,7 @@ Это происходит потому, что фильтр определяет направление трафика по портам: трафик, приходящий в LAN-порт, считается абонентским, а source IP записывается как local. Если LAN и WAN перепутаны, source IP интернет-хоста ошибочно записывается как local. -> **Ключевой принцип:** локальный (абонентский) IP-адрес **всегда записывается на первое место** в сессии (см. [раздел 12.5](12.md)). Если на первом месте оказался интернет-адрес — порты перепутаны. +> **Ключевой принцип:** локальный (абонентский) IP-адрес **всегда записывается на первое место** в сессии (см. [раздел 12.5](filter-sessions.md)). Если на первом месте оказался интернет-адрес — порты перепутаны. ### Где может произойти перепутка @@ -251,7 +251,7 @@ 3. Проверить физическое подключение кабелей; 4. Проверить конфигурацию линков на балансировщике. -## 24.7. Взаимодействие с оператором связи +## 23.7. Взаимодействие с оператором связи Эффективная диагностика часто требует **совместной работы** с оператором связи и конечным абонентом: @@ -272,7 +272,7 @@ **С оператором:** при переключениях bypass/primary необходимо **согласовывать работы** с оператором, так как переключение оптического байпаса вызывает флапы линков. Программный bypass на балансировщике не требует такого согласования. -## 24.8. Ограничения: L2-устройство, невозможность генерации трафика с фильтра +## 23.8. Ограничения: L2-устройство, невозможность генерации трафика с фильтра Фильтр ТСПУ — это устройство **уровня L2** (Layer 2). Это накладывает принципиальные ограничения на возможности диагностики: @@ -305,4 +305,4 @@ --- -[← Оглавление](../README.md) · [← Раздел 23: Распознавание протоколов (DPI Engine)](23.md) +[← Оглавление](../README.md) · [← Раздел 22: Распознавание протоколов и двухстадийная блокировка](protocol-blocking.md)