10fb7f4e18
- Раздел 22: Балансировщик: мониторинг и диагностика - Раздел 23: Распознавание протоколов (DPI Engine) - Раздел 24: Траблшутинг Каждый раздел включает команды, описания и практические примеры для диагностики и мониторинга работы балансировщика и системы фильтрации.
22 KiB
2. Прохождение трафика через ТСПУ
← Оглавление · ← Раздел 1: Введение и общая архитектура АСБИ
2.1. Стык оператора связи: типы инкапсуляции
ТСПУ устанавливается в разрыв канала связи внутри сети оператора. На стыке, в который врезается ТСПУ, трафик представляет собой поток пакетов между оборудованием оператора — с одной стороны абоненты, с другой стороны интернет.
Рассмотрим прохождение пакета с точки зрения абонента. У абонента есть локальный IP-адрес и локальный порт (local IP, local port). У интернет-ресурса, к которому обращается абонент, есть удалённый IP-адрес и удалённый порт (remote IP, remote port).
Абонент → Интернет:
┌─────────────────────────────────────────────┐
│ Source: local IP : local port │
│ Destination: remote IP : remote port │
└─────────────────────────────────────────────┘
Интернет → Абонент:
┌─────────────────────────────────────────────┐
│ Source: remote IP : remote port │
│ Destination: local IP : local port │
└─────────────────────────────────────────────┘
При обратном пакете (от ресурса к абоненту) source и destination меняются местами.
Инкапсуляция на стыке оператора
На стыке оператора связи пакет может иметь различную дополнительную инкапсуляцию. Это зависит от технологий, применяемых конкретным оператором, и от места в сети, куда устанавливается ТСПУ.
Общая структура кадра Ethernet с учётом возможных дополнительных заголовков:
┌──────────┬─────────────────┬──────────────┬─────────┬──────┐
│ Ethernet │ Доп. заголовки │ IP-заголовок│ TCP/UDP │ Data │
│ заголовок│ (??? ) │ │ │ │
└──────────┴─────────────────┴──────────────┴─────────┴──────┘
В поле дополнительных заголовков могут встречаться:
| Тип инкапсуляции | Описание |
|---|---|
| Без инкапсуляции | Чистый IP-пакет, дополнительных заголовков нет |
| VLAN (802.1Q) | Один VLAN-тег (тегированный пакет) |
| QinQ (802.1ad) | Два VLAN-тега (дважды тегированный пакет) |
| MPLS | Одна или несколько MPLS-меток |
| MPLS + VLAN | Комбинация MPLS-меток и VLAN-тегов |
| PPPoE | PPP-инкапсуляция (характерна для участка до BRAS) |
| PPPoE + MPLS | PPP внутри MPLS-туннеля |
Вариантов инкапсуляции в операторских сетях очень много, и все они не могут быть перечислены исчерпывающим образом. Ключевой момент: ТСПУ должен уметь разбираться со всеми этими заголовками, чтобы добраться до IP-пакета и выполнить его анализ и обработку. Всё, что находится «поверх» IP-заголовка, прозрачно пропускается — никакие метки и теги ТСПУ не снимает и не модифицирует.
2.2. Разделение на LAN-порты и WAN-порты
Фундаментальный принцип организации портов на всех устройствах ТСПУ — разделение на LAN и WAN:
- LAN-порты — порты, смотрящие в сторону абонентов (внутренняя сторона сети оператора);
- WAN-порты — порты, смотрящие в сторону интернета (внешняя сторона).
Абоненты Интернет
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│ LAN-порт │ ◄── ТСПУ ──► │ WAN-порт │
└──────────┘ └──────────┘
Эта идеология прослеживается через всё оборудование ТСПУ — от байпасов до балансировщиков и фильтров. Все порты на любом устройстве ТСПУ можно разделить на две группы: порты в сторону абонентов (LAN) и порты в сторону интернета (WAN).
На фильтрах разделение реализовано жёстко: все чётные порты — LAN, все нечётные — WAN. На балансировщиках аналогичное разделение принято по договорённости при проектировании схем: чётные порты назначаются LAN-портами, нечётные — WAN-портами.
Этот принцип является основой для корректной обработки трафика: пакет, вошедший через определённый LAN-порт, после обработки обязательно выходит через парный ему WAN-порт (и наоборот), что обеспечивает прозрачность ТСПУ для сети оператора.
2.3. Простейший вариант ТСПУ (один байпас, один фильтр)
В минимальной конфигурации ТСПУ может состоять всего из трёх компонентов:
- один байпас — для одного-двух каналов связи оператора;
- один фильтр — для обработки всего проходящего трафика;
- сегмент управления — SPFS, СПХД, коммутатор, VPN-шлюз.
Оборудование Оборудование
оператора оператора
(LAN) (WAN)
│ │
│ ┌───────────┐ │
└────┤ Байпас ├────┘
└─────┬─────┘
│
┌─────┴─────┐
│ Фильтр │
└───────────┘
─────────────────────────────
Сегмент управления
(SPFS, СПХД, VPN)
В таком варианте балансировщик не нужен, поскольку весь трафик обрабатывается одним фильтром и распределение по нескольким фильтрам не требуется. Каналы от байпаса подключаются непосредственно к портам фильтра.
Ограничение: могут быть подключены только каналы 1 Гбит/с или 10 Гбит/с Ethernet, поскольку фильтры текущего проекта не поддерживают интерфейсы 100 Гбит/с — только 1G и 10G в зависимости от конкретной модели.
2.4. Типовая схема ТСПУ
В типовой конфигурации присутствуют все компоненты системы: байпасы, балансировщики и фильтры. Рассмотрим полный путь пакета через ТСПУ.
Общая схема прохождения трафика
Оборудование оператора Оборудование оператора
(сторона абонентов, LAN) (сторона интернета, WAN)
│ │ │ │
│ Канал 1 │ │ Канал 1 │
┌────┴───────────┴───┐ ┌────┴───────────┴───┐
│ Байпас 1 │ │ Байпас 1 │
│ Net0 Net1│ │ Mon0 Mon1 │
└────┬───────────┬───┘ └────┬───────────┬───┘
│ │ │ │
┌────┴───────────┴───────────────────┴───────────┴───┐
│ Балансировщик │
│ │
│ ┌─────────┐ ┌──────────────┐ ┌─────────────┐ │
│ │ Фильтры │ │ Группа │ │ Программный │ │
│ │ (Flow │──►│ балансировки │──►│ заголовок │ │
│ │ rules) │ │ (хэш) │ │ (+4 байта) │ │
│ └─────────┘ └──────────────┘ └─────────────┘ │
└───┬────┬────┬──────────────────────┬────┬────┬─────┘
│ │ │ │ │ │
┌──┴──┐ │ ┌──┴──┐ ┌──┴──┐ │ ┌──┴──┐
│Ф-р 1│ │ │Ф-р 2│ │Ф-р 1│ │ │Ф-р 2│
│ LAN │ │ │ LAN │ ... │ WAN │ │ │ WAN │
└─────┘ │ └─────┘ └─────┘ │ └─────┘
│ │
┌──┴──┐ ┌──┴──┐
│Ф-р N│ │Ф-р N│
│ LAN │ │ WAN │
└─────┘ └─────┘
Этап 1: Байпас
Канал связи оператора физически разрывается и заводится на байпас. Байпас обеспечивает защиту канала: в случае аварии он замыкает линки напрямую, минуя остальное оборудование ТСПУ. В штатном режиме (Inline) байпас прозрачно пропускает трафик дальше — в сторону балансировщика.
Подробнее о режимах работы байпаса — в разделе 3.
Этап 2: Балансировщик — фильтрация служебного трафика
На входе в балансировщик порты объединяются в линки — логические пары LAN + WAN. Трафик, пришедший через конкретный LAN-порт, обязательно возвращается через парный ему WAN-порт (и наоборот). Это гарантирует, что ТСПУ не нарушает маршрутизацию оператора.
Первым делом трафик проходит через правила фильтрации (flow rules) балансировщика. Здесь определяется, какой трафик следует отправить на анализ фильтрами, а какой — сразу вернуть обратно оператору (забайпасить). Байпасятся, как правило:
- служебные протоколы (например, BGP — TCP-порт 179);
- мультикаст-трафик;
- протоколы маршрутизации;
- прочий трафик, который не нужно и нежелательно анализировать.
В принципе, с таким трафиком на фильтрах ничего плохого не произойдёт, но лучше его не трогать — это снижает нагрузку и исключает потенциальное влияние на служебные протоколы оператора.
Этап 3: Балансировщик — распределение по фильтрам
Трафик, не попавший под правила байпаса, отправляется в группу балансировки. В этой группе подключены все фильтры площадки. Балансировщик распределяет пакеты по фильтрам на основе хэш-суммы, вычисляемой по трём параметрам:
- Source IP (адрес источника)
- Destination IP (адрес назначения)
- IP-протокол (TCP, UDP и т.д.)
К хэшу также добавляется количество ядер фильтров, чтобы пакет не просто попал на конкретный фильтр, но и был распределён на конкретное ядро для обработки.
Для передачи информации о балансировке к пакету добавляется дополнительный 4-байтовый заголовок (по структуре похож на VLAN-тег, но таковым не является). Этот заголовок сообщает фильтру, на какое ядро направить пакет. После обработки фильтр возвращает пакет с тем же 4-байтовым заголовком, по которому балансировщик определяет, в какой именно операторский линк нужно вернуть пакет.
Симметричность хэша — ключевое свойство балансировки. При вычислении хэша для обратного пакета (от интернета к абоненту) source и destination меняются местами, но итоговая хэш-сумма совпадает. Благодаря этому:
- оба направления одной сессии всегда попадают на один и тот же фильтр;
- более того — на одно и то же ядро этого фильтра;
- сессия никогда не распределяется по разным фильтрам, что позволяет корректно собирать и анализировать её на одном устройстве.
Этап 4: Обработка на фильтре
Пакет, попавший на фильтр, проходит через цепочку проверок:
Пакет
│
▼
┌──────────────────┐ Нет
│ IP-пакет? │──────────► Прозрачный пропуск
└────────┬─────────┘
│ Да
▼
┌──────────────────┐ Нет
│ Попал в ACL? │──────────► Прозрачный пропуск
│ (привязка к │
│ пулу) │
└────────┬─────────┘
│ Да
▼
┌──────────────────┐ Нет
│ Попал в │──────────► Прозрачный пропуск
│ DPI-лист? │
│ (IP-подсети) │
└────────┬─────────┘
│ Да
▼
┌──────────────────┐
│ Движок DPI │
│ (анализ и │
│ решение) │
└────────┬─────────┘
│
┌────┴────┐
▼ ▼
Пропустить Заблокировать
(drop)
-
Проверка: IP-пакет или нет. Если пакет не является IP-пакетом (например, служебный keep-alive от балансировщика), он прозрачно пропускается через парный порт обратно в сеть оператора.
-
Проверка по ACL. На фильтре настроены списки контроля доступа (ACL), привязанные к пулам. Если пакет не попадает ни в один ACL — он прозрачно пропускается.
-
Проверка по DPI-листу. В DPI-листе указаны IP-подсети и адреса, подлежащие проверке. Если IP-адреса пакета не попадают в обработку DPI-листа — пакет прозрачно пропускается.
-
Обработка движком DPI. Только пакеты, прошедшие все предыдущие проверки, попадают на анализ DPI-движком. По результатам анализа принимается решение: пропустить пакет или заблокировать (drop).
Фильтр работает на уровне L2 — он не изменяет Ethernet-кадр и не участвует в маршрутизации. С точки зрения сети оператора, фильтр представляет собой «прозрачный провод»: все заголовки инкапсуляции (VLAN-теги, MPLS-метки и т.д.) проходят через фильтр без изменений. Фильтр разбирает стек заголовков только для того, чтобы добраться до IP-пакета и выполнить анализ, после чего пакет (в случае пропуска) передаётся дальше в неизменном виде.
Особенность: HTTP-редирект и TCP Reset при наличии MPLS
Особый случай возникает, когда фильтру нужно отправить абоненту HTTP-редирект (код 302, перенаправление на страницу-заглушку) или TCP Reset при блокировке HTTPS-ресурса.
Фильтр не может просто сгенерировать ответный пакет, поскольку канал между балансировщиком и фильтром однонаправленный с точки зрения сессии — пакет от абонента приходит через LAN-порт, и ответ должен уйти абоненту с корректными заголовками инкапсуляции (в том числе MPLS-метками), которые фильтр сам сгенерировать не может.
Поэтому используется следующая логика:
- Пакет от абонента в сторону интернет-ресурса пропускается как есть;
- Фильтр ожидает обратный пакет от интернет-ресурса в рамках той же сессии;
- Когда обратный пакет приходит (уже с корректными заголовками, включая нужные MPLS-метки), фильтр подменяет содержимое этого пакета на HTTP-редирект или TCP Reset;
- Модифицированный пакет отправляется абоненту с сохранением всей инкапсуляции.
Таким образом, пакет доставляется абоненту с корректными сетевыми заголовками, и HTTP-редирект или разрыв соединения срабатывает штатно.
← Оглавление · ← Раздел 1: Введение и общая архитектура АСБИ · Раздел 3: Байпас →