253 lines
23 KiB
Markdown
253 lines
23 KiB
Markdown
# 2. Прохождение трафика через ТСПУ
|
||
|
||
[← Оглавление](../README.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md)
|
||
|
||
---
|
||
|
||
<img width="1024" alt="image" src="https://github.com/user-attachments/assets/2aa75f41-b661-4d74-b949-a46b78aa620a" />
|
||
|
||
## 2.1. Стык оператора связи: типы инкапсуляции
|
||
|
||
ТСПУ устанавливается в разрыв канала связи внутри сети оператора. На стыке, в который врезается ТСПУ, трафик представляет собой поток пакетов между оборудованием оператора — с одной стороны абоненты, с другой стороны интернет.
|
||
|
||
Рассмотрим прохождение пакета с точки зрения абонента. У абонента есть **локальный IP-адрес** и **локальный порт** (local IP, local port). У интернет-ресурса, к которому обращается абонент, есть **удалённый IP-адрес** и **удалённый порт** (remote IP, remote port).
|
||
|
||
```text
|
||
Абонент → Интернет:
|
||
┌─────────────────────────────────────────────┐
|
||
│ Source: local IP : local port │
|
||
│ Destination: remote IP : remote port │
|
||
└─────────────────────────────────────────────┘
|
||
|
||
Интернет → Абонент:
|
||
┌─────────────────────────────────────────────┐
|
||
│ Source: remote IP : remote port │
|
||
│ Destination: local IP : local port │
|
||
└─────────────────────────────────────────────┘
|
||
```
|
||
|
||
При обратном пакете (от ресурса к абоненту) source и destination меняются местами.
|
||
|
||
<img width="1024" height="1225" alt="image" src="https://github.com/user-attachments/assets/d4b641db-783f-41de-b94b-3211ec2767a3" />
|
||
|
||
### Инкапсуляция на стыке оператора
|
||
|
||
На стыке оператора связи пакет может иметь различную дополнительную инкапсуляцию. Это зависит от технологий, применяемых конкретным оператором, и от места в сети, куда устанавливается ТСПУ.
|
||
|
||
Общая структура кадра Ethernet с учётом возможных дополнительных заголовков:
|
||
|
||
```text
|
||
┌──────────┬─────────────────┬──────────────┬─────────┬──────┐
|
||
│ 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-порты** — порты, смотрящие в сторону **интернета** (внешняя сторона).
|
||
|
||
```text
|
||
Абоненты Интернет
|
||
│ │
|
||
▼ ▼
|
||
┌──────────┐ ┌──────────┐
|
||
│ LAN-порт │ ◄── ТСПУ ──► │ WAN-порт │
|
||
└──────────┘ └──────────┘
|
||
```
|
||
|
||
Эта идеология **прослеживается через всё оборудование ТСПУ** — от байпасов до балансировщиков и фильтров. Все порты на любом устройстве ТСПУ можно разделить на две группы: порты в сторону абонентов (LAN) и порты в сторону интернета (WAN).
|
||
|
||
На **фильтрах** разделение реализовано жёстко: все **чётные** порты — LAN, все **нечётные** — WAN. На **балансировщиках** аналогичное разделение принято по договорённости при проектировании схем: чётные порты назначаются LAN-портами, нечётные — WAN-портами.
|
||
|
||
Этот принцип является основой для корректной обработки трафика: пакет, вошедший через определённый LAN-порт, после обработки обязательно выходит через парный ему WAN-порт (и наоборот), что обеспечивает прозрачность ТСПУ для сети оператора.
|
||
|
||
## 2.3. Простейший вариант ТСПУ (один байпас, один фильтр)
|
||
|
||
В минимальной конфигурации ТСПУ может состоять всего из трёх компонентов:
|
||
|
||
- **один байпас** — для одного-двух каналов связи оператора;
|
||
- **один фильтр** — для обработки всего проходящего трафика;
|
||
- **сегмент управления** — SPFS, СПХД, коммутатор, VPN-шлюз.
|
||
|
||
```text
|
||
Оборудование Оборудование
|
||
оператора оператора
|
||
(LAN) (WAN)
|
||
│ │
|
||
│ ┌───────────┐ │
|
||
└────┤ Байпас ├────┘
|
||
└─────┬─────┘
|
||
│
|
||
┌─────┴─────┐
|
||
│ Фильтр │
|
||
└───────────┘
|
||
|
||
─────────────────────────────
|
||
Сегмент управления
|
||
(SPFS, СПХД, VPN)
|
||
```
|
||
|
||
В таком варианте **балансировщик не нужен**, поскольку весь трафик обрабатывается одним фильтром и распределение по нескольким фильтрам не требуется. Каналы от байпаса подключаются непосредственно к портам фильтра.
|
||
|
||
Ограничение: могут быть подключены только каналы **1 Гбит/с** или **10 Гбит/с** Ethernet, поскольку фильтры текущего проекта не поддерживают интерфейсы 100 Гбит/с — только 1G и 10G в зависимости от конкретной модели.
|
||
|
||
## 2.4. Типовая схема ТСПУ
|
||
|
||
В типовой конфигурации присутствуют все компоненты системы: байпасы, балансировщики и фильтры. Рассмотрим полный путь пакета через ТСПУ.
|
||
|
||
### Общая схема прохождения трафика
|
||
|
||
```text
|
||
Оборудование оператора Оборудование оператора
|
||
(сторона абонентов, 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](03.md).
|
||
|
||
### Этап 2: Балансировщик — фильтрация служебного трафика
|
||
|
||
На входе в балансировщик порты объединяются в **линки** — логические пары LAN + WAN. Трафик, пришедший через конкретный LAN-порт, **обязательно возвращается** через парный ему WAN-порт (и наоборот). Это гарантирует, что ТСПУ не нарушает маршрутизацию оператора.
|
||
|
||
Первым делом трафик проходит через **правила фильтрации** (flow rules) балансировщика. Здесь определяется, какой трафик следует отправить на анализ фильтрами, а какой — сразу вернуть обратно оператору (забайпасить). Байпасятся, как правило:
|
||
|
||
- служебные протоколы (например, BGP — TCP-порт 179);
|
||
- мультикаст-трафик;
|
||
- протоколы маршрутизации;
|
||
- прочий трафик, который не нужно и нежелательно анализировать.
|
||
|
||
В принципе, с таким трафиком на фильтрах ничего плохого не произойдёт, но лучше его не трогать — это снижает нагрузку и исключает потенциальное влияние на служебные протоколы оператора.
|
||
|
||
### Этап 3: Балансировщик — распределение по фильтрам
|
||
|
||
Трафик, не попавший под правила байпаса, отправляется в **группу балансировки**. В этой группе подключены все фильтры площадки. Балансировщик распределяет пакеты по фильтрам на основе **хэш-суммы**, вычисляемой по трём параметрам:
|
||
|
||
1. **Source IP** (адрес источника)
|
||
2. **Destination IP** (адрес назначения)
|
||
3. **IP-протокол** (TCP, UDP и т.д.)
|
||
|
||
К хэшу также добавляется **количество ядер фильтров**, чтобы пакет не просто попал на конкретный фильтр, но и был распределён на конкретное ядро для обработки.
|
||
|
||
Для передачи информации о балансировке к пакету добавляется **дополнительный 4-байтовый заголовок** (по структуре похож на VLAN-тег, но таковым не является). Этот заголовок сообщает фильтру, на какое ядро направить пакет. После обработки фильтр возвращает пакет с тем же 4-байтовым заголовком, по которому балансировщик определяет, в какой именно операторский линк нужно вернуть пакет.
|
||
|
||
**Симметричность хэша** — ключевое свойство балансировки. При вычислении хэша для обратного пакета (от интернета к абоненту) source и destination меняются местами, но итоговая хэш-сумма совпадает. Благодаря этому:
|
||
|
||
- оба направления одной сессии **всегда попадают на один и тот же фильтр**;
|
||
- более того — на одно и то же **ядро** этого фильтра;
|
||
- сессия никогда не распределяется по разным фильтрам, что позволяет корректно собирать и анализировать её на одном устройстве.
|
||
|
||
### Этап 4: Обработка на фильтре
|
||
|
||
Пакет, попавший на фильтр, проходит через цепочку проверок:
|
||
|
||
```text
|
||
Пакет
|
||
│
|
||
▼
|
||
┌──────────────────┐ Нет
|
||
│ IP-пакет? │──────────► Прозрачный пропуск
|
||
└────────┬─────────┘
|
||
│ Да
|
||
▼
|
||
┌──────────────────┐ Нет
|
||
│ Попал в ACL? │──────────► Прозрачный пропуск
|
||
│ (привязка к │
|
||
│ пулу) │
|
||
└────────┬─────────┘
|
||
│ Да
|
||
▼
|
||
┌──────────────────┐ Нет
|
||
│ Попал в │──────────► Прозрачный пропуск
|
||
│ DPI-лист? │
|
||
│ (IP-подсети) │
|
||
└────────┬─────────┘
|
||
│ Да
|
||
▼
|
||
┌──────────────────┐
|
||
│ Движок DPI │
|
||
│ (анализ и │
|
||
│ решение) │
|
||
└────────┬─────────┘
|
||
│
|
||
┌────┴────┐
|
||
▼ ▼
|
||
Пропустить Заблокировать
|
||
(drop)
|
||
```
|
||
|
||
1. **Проверка: IP-пакет или нет.** Если пакет не является IP-пакетом (например, служебный keep-alive от балансировщика), он прозрачно пропускается через парный порт обратно в сеть оператора.
|
||
|
||
2. **Проверка по ACL.** На фильтре настроены списки контроля доступа (ACL), привязанные к пулам. Если пакет не попадает ни в один ACL — он прозрачно пропускается.
|
||
|
||
3. **Проверка по DPI-листу.** В DPI-листе указаны IP-подсети и адреса, подлежащие проверке. Если IP-адреса пакета не попадают в обработку DPI-листа — пакет прозрачно пропускается.
|
||
|
||
4. **Обработка движком DPI.** Только пакеты, прошедшие все предыдущие проверки, попадают на анализ DPI-движком. По результатам анализа принимается решение: пропустить пакет или заблокировать (drop).
|
||
|
||
Фильтр работает на уровне **L2** — он не изменяет Ethernet-кадр и не участвует в маршрутизации. С точки зрения сети оператора, фильтр представляет собой **«прозрачный провод»**: все заголовки инкапсуляции (VLAN-теги, MPLS-метки и т.д.) проходят через фильтр без изменений. Фильтр разбирает стек заголовков только для того, чтобы добраться до IP-пакета и выполнить анализ, после чего пакет (в случае пропуска) передаётся дальше в неизменном виде.
|
||
|
||
### Особенность: HTTP-редирект и TCP Reset при наличии MPLS
|
||
|
||
Особый случай возникает, когда фильтру нужно отправить абоненту **HTTP-редирект** (код 302, перенаправление на страницу-заглушку) или **TCP Reset** при блокировке HTTPS-ресурса.
|
||
|
||
Фильтр не может просто сгенерировать ответный пакет, поскольку канал между балансировщиком и фильтром **однонаправленный** с точки зрения сессии — пакет от абонента приходит через LAN-порт, и ответ должен уйти абоненту с корректными заголовками инкапсуляции (в том числе MPLS-метками), которые фильтр сам сгенерировать не может.
|
||
|
||
Поэтому используется следующая логика:
|
||
|
||
1. Пакет от абонента в сторону интернет-ресурса **пропускается** как есть;
|
||
2. Фильтр **ожидает обратный пакет** от интернет-ресурса в рамках той же сессии;
|
||
3. Когда обратный пакет приходит (уже с корректными заголовками, включая нужные MPLS-метки), фильтр **подменяет** содержимое этого пакета на HTTP-редирект или TCP Reset;
|
||
4. Модифицированный пакет отправляется абоненту с сохранением всей инкапсуляции.
|
||
|
||
Таким образом, пакет доставляется абоненту с корректными сетевыми заголовками, и HTTP-редирект или разрыв соединения срабатывает штатно.
|
||
|
||
---
|
||
|
||
[← Оглавление](../README.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md) · [Раздел 3: Байпас →](03.md)
|