# 3. Места установки ТСПУ в сети оператора
[← Оглавление](../README.md) · [← Раздел 2: Прохождение трафика через ТСПУ](traffic-flow.md)
---
ТСПУ устанавливается **в разрыв каналов связи** оператора и может располагаться в нескольких точках его сети. От точки установки зависят инкапсуляция трафика, которую придётся разбирать ([разделы 2.1](traffic-flow.md) и [10.1.1](filter.md)), возможности диагностики, нагрузка на оборудование и охват: трафик, который разворачивается ниже точки установки, — между абонентами оператора, к кэш-серверам и узлам CDN, подключённым ниже неё, — через ТСПУ не проходит. Мест для установки много: одни предпочтительнее, другие менее удобны, но тоже допустимы.
Если рассматривать сеть оператора от абонентов в сторону выхода в интернет, выделяются три точки установки — до BRAS, между BRAS и CGNAT и после CGNAT, — а также особый случай, когда сервисное оборудование оператора подключено в режиме on-a-stick.
_Точки установки ТСПУ: 1 — до BRAS и CGNAT, 2 — после BRAS, но до CGNAT, 3 — после BRAS и CGNAT. Справа — BRAS и CGNAT совмещены в одном устройстве, и точки 2 нет._
В любой из этих точек ТСПУ тип А должно видеть оба направления трафика: если ответный трафик возвращается в обход ТСПУ, сессия на фильтре не соберётся ([раздел 6.3.3](balancer.md)). Такой асимметричный трафик характерен для уровня ядра и пиринга крупных операторов — для подключений других операторов и корпоративных клиентов с несколькими выходами в интернет; для него предназначена эшелонированная система ([раздел 4.2](echelon.md)).
## 3.1. До BRAS/BNG (между абонентами и терминацией сессий)
Первая точка — между абонентами и устройствами, которые терминируют абонентские сессии:
| Тип сети | Устройства терминации сессий |
| ------------------------- | ------------------------------- |
| **Широкополосный доступ** | BRAS, BNG |
| **Мобильные сети** | GGSN, PGW (в сетях 5G SA — UPF) |
Далее все они для краткости называются BRAS («условный BRAS»). В этой точке ТСПУ стоит ближе всего к абонентам — до терминации абонентских сессий и трансляции адресов.
> **Примечание.** В мобильных сетях на участке до шлюза пакетной сети (GGSN, PGW, в 5G SA — UPF) пользовательский трафик идёт внутри туннелей GTP-U (UDP, порт 2152) — например, на интерфейсах Gn/Gp, S1-U, S5/S8, в 5G — N3 и N9. Среди инкапсуляций, которые по документации производителя разбирают балансировщик и фильтр ([разделы 6.7](balancer.md) и [10.1.1](filter.md)), GTP не упоминается. Без разбора GTP ТСПУ видит только внешние заголовки туннелей — адреса базовых станций и шлюзов: трафик абонентов не анализируется, а балансировка по паре адресов сводит трафик между двумя узлами на одно ядро фильтра. Поэтому, пока поддержка GTP в используемой версии ПО не подтверждена, в мобильной сети ТСПУ имеет смысл ставить после шлюза — на интерфейсе Gi/SGi (в 5G — N6).
### 3.1.1. Особенность: PPPoE-трафик
Если широкополосные абоненты подключаются по PPPoE, на участке до BRAS через ТСПУ идёт **PPPoE-трафик** — ещё один уровень инкапсуляции, который нужно разбирать. Выше BRAS PPPoE в нормально работающей сети не бывает: BRAS терминирует PPPoE-сессии и дальше передаёт обычные IP-пакеты. При подключении абонентов по IPoE этой особенности нет.
Наличие PPPoE — не проблема, а особенность, которую нужно учесть при настройке. PPPoE на участке доступа часто идёт поверх VLAN или QinQ, поэтому фильтр должен разбирать и VLAN-теги (`vlan_mode`), и сам PPPoE (`pppoe_analyzer`) — [раздел 10.1.1](filter.md); балансировщик PPPoE разбирает ([раздел 6.7](balancer.md)).
Исключение — схемы с L2TP: BRAS в роли LAC не терминирует PPP, а передаёт PPP-сессии в туннелях L2TP (UDP, порт 1701) на LNS; так же устроено подключение абонентов по L2TP напрямую к LNS. До LNS трафик абонентов идёт внутри L2TP, разбор которого в документации производителя не описан, — на таком участке ТСПУ увидит только туннели.
## 3.2. До CGNAT (после BRAS) — наиболее удобная точка
Вторая точка — **между BRAS и CGNAT**: абонентские сессии уже терминированы на BRAS, но адреса ещё не прошли трансляцию (NAT).
Это, вероятно, **наиболее удобная точка** для установки ТСПУ по двум причинам:
1. **PPPoE-трафика здесь уже нет** — заголовков инкапсуляции для разбора меньше;
2. **видны абонентские адреса** — серые адреса абонентов (частные или из диапазона 100.64.0.0/10) ещё не прошли трансляцию.
> **Примечание.** BRAS и CGNAT могут быть **совмещены в одном устройстве**. Тогда участка между ними, а значит и этой точки установки, просто нет — ТСПУ ставится либо до этого устройства, либо после него.
### 3.2.1. Видимость серых абонентских IP-адресов
На участке до CGNAT фильтры видят **серые** адреса — те, что назначены абонентским устройствам. Это упрощает диагностику:
- сессию **конкретного абонента** можно найти на фильтрах по его IP-адресу ([раздел 23.2](troubleshooting.md));
- видно, что именно происходит с трафиком этого абонента;
- абонента можно исключить из обработки DPI-листом (параметр `no_ip`), чтобы проверить, влияет ли лист на его трафик ([разделы 17.4.8](filter-dpi.md) и [23.5](troubleshooting.md)).
Прямая связь между физическим абонентом и его сессиями на ТСПУ ускоряет поиск и устранение проблем.
Серые адресные пространства в разных VLAN (например, за разными BRAS) при этом не должны пересекаться: VLAN-тег абонентов на фильтре не разделяет, и одинаковые адреса в разных VLAN фильтр считает одним абонентом ([раздел 10.1.1](filter.md)).
## 3.3. После CGNAT (ближе к выходу в интернет)
Третья точка — **после CGNAT**, ближе к выходу в интернет. Трафик здесь уже прошёл трансляцию адресов.
### 3.3.1. Только белые адреса, сложности траблшутинга
После CGNAT серых абонентских адресов **уже не видно**: IPv4-трафик абонентов, выходящих в интернет через NAT, виден на фильтрах с **белыми** адресами из NAT-пула оператора. Со своими адресами остаются видны лишь абоненты с выделенными белыми IPv4-адресами, которых CGNAT не транслирует, и IPv6-трафик (NAT44 его не затрагивает). Это неудобно для траблшутинга:
- **нельзя напрямую связать** физического абонента с его сессией на ТСПУ — абонентский адрес в сессии уже транслированный, а не исходный;
- чтобы найти абонента, нужно **обращаться к оператору** и выяснять по журналам трансляций CGNAT, в какой адрес и какие порты этот абонент транслировался в нужный момент времени ([разделы 23.2](troubleshooting.md) и [23.7](troubleshooting.md));
- исключить из обработки DPI-листом одного абонента нельзя: `no_ip` исключит адрес NAT-пула, а вместе с ним — всех абонентов, транслированных в этот адрес.
Диагностика становится дольше и требует координации между командой ТСПУ и оператором связи.
На логику фильтрации (блокировку, распознавание протоколов) размещение после CGNAT не влияет — основное неудобство касается диагностики. Стоит учитывать и распределение нагрузки: за одним адресом NAT-пула стоит много абонентов, а балансировщик распределяет трафик по парам адресов, поэтому трафик многих абонентов к одному ресурсу попадает на одно ядро фильтра ([раздел 6.5.1](balancer.md)).
## 3.4. Сервисное оборудование в режиме on-a-stick
Особый случай — когда сервисное оборудование оператора (BRAS, CGNAT или совмещённое устройство BRAS + CGNAT) подключено к маршрутизатору **в режиме on-a-stick**: одним каналом, физическим или агрегированным, по которому трафик приходит на устройство и уходит с него обратно — как правило, в разных VLAN. Если ТСПУ установлено на этом канале, трафик проходит через него **дважды**. Если канал агрегированный, все его каналы заводятся на один балансировщик ([раздел 6.3.3](balancer.md)).
_ТСПУ на канале on-a-stick. Слева BRAS и CGNAT подключены каждый к своему маршрутизатору, и на каждом таком канале стоит своё ТСПУ: участки 1 + 2 (BRAS) и 2 + 3 (CGNAT). Справа — совмещённое устройство BRAS + CGNAT, участки 1 + 3. Номера — точки установки из схемы выше._
```text
Абоненты Интернет
│ ▲
▼ │
┌─────────────────────────────────────────────────┐
│ Маршрутизатор оператора │
└────────────────────────┬────────────────────────┘
│
LAN │ ↓ 1-й проход (участок «до»): входит через LAN
┌─────┴─────┐
│ ТСПУ │
└─────┬─────┘
WAN │ ↑ 2-й проход (участок «после»): входит через WAN
│
┌────────┴────────┐
│ BRAS / CGNAT │
└─────────────────┘
```
_Оба прохода пересекают ТСПУ целиком, в противоположных направлениях. Ориентация LAN/WAN показана для случая, когда обрабатывается участок «до»._
На канале on-a-stick встречаются два участка — «до» сервисного устройства и «после» него:
| Вариант | Участок «до» | Участок «после» |
| --------------------------------------- | ------------------------- | ----------------------------- |
| **BRAS on-a-stick** | 1 — абоненты ↔ BRAS | 2 — BRAS ↔ CGNAT или интернет |
| **CGNAT on-a-stick** | 2 — BRAS ↔ CGNAT | 3 — CGNAT ↔ интернет |
| **Совмещённые BRAS и CGNAT on-a-stick** | 1 — абоненты ↔ BRAS/CGNAT | 3 — BRAS/CGNAT ↔ интернет |
### 3.4.1. Двойное прохождение трафика через ТСПУ
При подключении on-a-stick трафик проходит через ТСПУ дважды:
1. **Первый проход** — трафик абонентов идёт от маршрутизатора через ТСПУ к BRAS/CGNAT;
2. **Второй проход** — обработанный трафик возвращается через ТСПУ к маршрутизатору и дальше в интернет.
Ответный трафик проходит те же два участка в обратном порядке.
Поэтому, если участки не разделены ([раздел 3.4.2](#342-обработка-только-одного-участка)), каждая абонентская сессия попадает на фильтры дважды: после CGNAT — уже с другими, транслированными адресами, после BRAS — с другой инкапсуляцией (например, без PPPoE).
Кроме того, два прохода пересекают ТСПУ в противоположных направлениях, а ориентация LAN/WAN задаётся подключением. LAN-сторона ТСПУ должна смотреть в сторону абонентов обрабатываемого участка: для участка «до» — к маршрутизатору, для участка «после» — к BRAS/CGNAT. Другой участок при этом неизбежно проходит через ТСПУ в обратной ориентации: фильтр принимает адреса интернет-ресурсов за локальные, а абонентские (или NAT-) адреса — за удалённые ([разделы 12.5](filter-sessions.md) и [23.6](troubleshooting.md)).
### 3.4.2. Обработка только одного участка
**Удобнее всего**, когда трафик двух участков можно чётко различить — например, оператор разделяет их по VLAN:
- в одних VLAN идёт трафик участка «до» — между абонентами и BRAS/CGNAT, в обоих направлениях;
- в других — трафик участка «после», между BRAS/CGNAT и интернетом.
Тогда ТСПУ обрабатывает только нужный участок, а трафик другого балансировщик **пропускает прозрачно**, даже не отправляя его на фильтры. Это настраивается правилами (flow rules) балансировщика: правило с условием по VLAN-тегу и действием балансировки отправляет нужные VLAN на фильтры, а правило с действием bypass возвращает оператору остальной трафик (имена действий и параметров — в [разделах 6.4](balancer.md) и [8.7](balancer-config.md)).
Какой участок обрабатывать, выбирают по тем же соображениям, что и точку установки (разделы 3.1–3.3): например, при CGNAT on-a-stick — участок до CGNAT с серыми адресами абонентов, а при BRAS on-a-stick участок после BRAS избавляет от разбора PPPoE. LAN-сторону ТСПУ подключают под выбранный участок ([раздел 3.4.1](#341-двойное-прохождение-трафика-через-тспу)).
В результате фильтры обрабатывают трафик **один раз**: каждого абонента видно единожды, путаницы с сессиями нет. Разделение снимает двойную нагрузку только с фильтров: канал on-a-stick, байпас и порты балансировщика по-прежнему пропускают оба прохода, и их ёмкость рассчитывают на полный объём.
Если участки не разделены по VLAN или оператор не может сказать, какие VLAN к какому участку относятся, стоит проверить, нельзя ли отделить их другими условиями правил балансировщика: по документации производителя правила умеют отбирать трафик и по подсетям, числу VLAN-тегов, типу кадра (EtherType) ([раздел 6.4.2](balancer.md)). При CGNAT on-a-stick участок «до» узнаётся по адресам: на фильтры отправляют трафик, у которого адрес источника или назначения входит в серые диапазоны абонентов, а трафик с адресами NAT-пула пропускают (абонентов с белыми адресами, которых CGNAT не транслирует, придётся учесть отдельно). При BRAS on-a-stick адреса на обоих участках одинаковы, и отделить участки можно разве что по признакам кадра — числу тегов или типу кадра (PPPoE).
Возможен и обратный подход: не перечислять обрабатываемые VLAN, а исключить из обработки ненужные и отправлять на фильтры всё остальное. Подходы по-разному реагируют на изменения на стыке: при перечислении новый VLAN оператора молча останется без фильтрации, при исключении новый VLAN участка «после» вернёт двойную обработку. Поэтому оператор должен сообщать об изменениях VLAN на стыке, а выбор подхода — вопрос удобства настройки для конкретной площадки.
### 3.4.3. Проблемы двойной обработки и best practice
Если участки не удаётся разделить ни по VLAN, ни другими условиями (например, оператор не может однозначно указать, какие VLAN относятся к какому участку), ТСПУ обрабатывает трафик дважды:
- **сессий вдвое больше** — одна и та же абонентская сессия проходит через фильтры два раза, в том числе с разными адресами (до и после трансляции);
- **путаница при траблшутинге** — у одной сессии две записи, причём на втором проходе с перевёрнутой ориентацией: адрес абонента там записан как удалённый, поэтому исключение параметром `no_ip` на этот проход не действует, и проверка по [разделу 23.5](troubleshooting.md) может дать ложный результат;
- **двойная нагрузка** — запас производительности фильтров приходится рассчитывать исходя из удвоенного объёма трафика.
Такой ситуации следует всячески **избегать** при проектировании: лучший вариант — получить от оператора информацию о разделении трафика и обрабатывать только нужный участок.
> **Пример из практики:** на пилотном проекте на Урале у одного из операторов CGNAT подключён в режиме on-a-stick (участки 2 + 3). Оператор сообщил, какие VLAN несут трафик до CGNAT, а какие — после, и на балансировщике на фильтры направили только VLAN участка до CGNAT. Фильтры видят обычные абонентские сессии с серыми адресами и не обрабатывают трафик после трансляции. Это и есть **best practice** подключения on-a-stick.
---
[← Оглавление](../README.md) · [← Раздел 2: Прохождение трафика через ТСПУ](traffic-flow.md) · [Раздел 4: Эшелонированная система →](echelon.md)