mirror of
https://github.com/DanielLavrushin/tspu-docs.git
synced 2026-09-27 17:28:00 +03:00
Новая нумерация и оглавление по частям, раздел 22 объединён, заглушки по старым адресам
This commit is contained in:
Daniel Lavrushin
@@ -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 <N>` — содержимое DPI-листа
|
||||
- 18.13.2. `show dpi state` — количество записей, дата последнего дампа
|
||||
- 18.13.3. `dpi load <N>` — ручная загрузка списка
|
||||
- 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)
|
||||
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [1. Введение и общая архитектура АСБИ](../docs/overview.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [2. Прохождение трафика через ТСПУ](../docs/traffic-flow.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [5. Байпас (Bypass)](../docs/bypass.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [6. Балансировщик: принцип работы](../docs/balancer.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [10. Фильтр: принцип работы](../docs/filter.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [3. Места установки ТСПУ в сети оператора](../docs/placement.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [4. Эшелонированная система (ТСПУ тип Б)](../docs/echelon.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [22. Распознавание протоколов и двухстадийная блокировка](../docs/protocol-blocking.md) (пункты 22.5–22.10).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [21. Центральная система управления (ЦСУ)](../docs/central-management.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [20. Сегмент управления ТСПУ](../docs/management-segment.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [11. Фильтр: аппаратная платформа](../docs/filter-platform.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [12. Фильтр: сессии и трансляции](../docs/filter-sessions.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [13. Фильтр: первоначальная настройка и CLI](../docs/filter-cli.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [14. Фильтр: конфигурация подсистем](../docs/filter-subsystems.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [15. Фильтр: настройка интерфейсов и общих параметров](../docs/filter-interfaces.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [16. Фильтр: ACL и пулы — запуск трафика на обработку](../docs/filter-acl-pools.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [17. Фильтр: настройка DPI](../docs/filter-dpi.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [18. Фильтр: мониторинг и диагностика](../docs/filter-monitoring.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [19. Фильтр: обновление прошивки](../docs/filter-firmware.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [7. Балансировщик: аппаратная платформа](../docs/balancer-platform.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [8. Балансировщик: конфигурация](../docs/balancer-config.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [9. Балансировщик: мониторинг и диагностика](../docs/balancer-monitoring.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [22. Распознавание протоколов и двухстадийная блокировка](../docs/protocol-blocking.md) (пункты 22.1–22.4).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
# Раздел перенесён
|
||||
|
||||
Документация реорганизована. Материал этой страницы теперь находится в разделе [23. Траблшутинг](../docs/troubleshooting.md).
|
||||
|
||||
[← Оглавление](../README.md)
|
||||
+31
-31
@@ -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)
|
||||
|
||||
+16
-16
@@ -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)
|
||||
|
||||
+13
-13
@@ -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)
|
||||
|
||||
+60
-60
@@ -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)
|
||||
|
||||
+34
-34
@@ -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)
|
||||
|
||||
@@ -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)
|
||||
|
||||
+19
-19
@@ -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)
|
||||
|
||||
@@ -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)
|
||||
|
||||
+3
-3
@@ -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)
|
||||
|
||||
+4
-4
@@ -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)
|
||||
|
||||
@@ -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)
|
||||
|
||||
@@ -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)
|
||||
|
||||
@@ -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)
|
||||
|
||||
@@ -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)
|
||||
|
||||
@@ -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)
|
||||
|
||||
@@ -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)
|
||||
|
||||
+41
-41
@@ -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)
|
||||
|
||||
@@ -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)
|
||||
|
||||
+16
-16
@@ -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)). На схемах ЦСУ обозначается как **ЦСУО** — центральная система управления оборудованием.
|
||||
|
||||
<img width="1838" height="839" alt="image" src="https://github.com/user-attachments/assets/ed6540bc-1fb2-4dd8-b0d6-56e376d63ddc" />
|
||||
|
||||
@@ -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)
|
||||
|
||||
+16
-16
@@ -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)
|
||||
|
||||
+177
-30
@@ -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)
|
||||
|
||||
+22
-22
@@ -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)).
|
||||
|
||||
<img width="1024" alt="image" src="https://github.com/user-attachments/assets/d4b641db-783f-41de-b94b-3211ec2767a3" />
|
||||
|
||||
@@ -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).
|
||||
|
||||
<img width="1024" alt="image" src="https://github.com/user-attachments/assets/e1640f7b-7bfa-4e79-abc5-0bc126f66b3a" />
|
||||
|
||||
@@ -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)
|
||||
|
||||
+20
-20
@@ -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)
|
||||
|
||||
Reference in New Issue
Block a user