first commit
This commit is contained in:
Daniel Lavrushin
248
02.md
Normal file
248
02.md
Normal file
@@ -0,0 +1,248 @@
|
||||
# 2. Прохождение трафика через ТСПУ
|
||||
|
||||
[← Оглавление](index.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md)
|
||||
|
||||
---
|
||||
|
||||
## 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 меняются местами.
|
||||
|
||||
### Инкапсуляция на стыке оператора
|
||||
|
||||
На стыке оператора связи пакет может иметь различную дополнительную инкапсуляцию. Это зависит от технологий, применяемых конкретным оператором, и от места в сети, куда устанавливается ТСПУ.
|
||||
|
||||
Общая структура кадра 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-редирект или разрыв соединения срабатывает штатно.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](index.md) · [← Раздел 1: Введение и общая архитектура АСБИ](01.md) · [Раздел 3: Байпас →](03.md)
|
||||
Reference in New Issue
Block a user