update section 3

This commit is contained in:
Daniel Lavrushin
2026-09-23 21:42:26 +02:00
parent f53aed1ef6
commit 71843bce8a
6 changed files with 102 additions and 88 deletions
+2 -2
View File
@@ -30,10 +30,10 @@
#### [3. Места установки ТСПУ в сети оператора](docs/placement.md)
- 3.1. До BRAS/BPE/BNG (между абонентами и терминацией сессий)
- 3.1. До BRAS/BNG (между абонентами и терминацией сессий)
- 3.2. До CGNAT (после BRAS) — наиболее удобная точка
- 3.3. После CGNAT (ближе к выходу в интернет)
- 3.4. Режим On-a-stick (BRAS/CGNAT подключены петлёй)
- 3.4. Сервисное оборудование в режиме on-a-stick
#### [4. Эшелонированная система (ТСПУ тип Б)](docs/echelon.md)
+1 -1
View File
@@ -123,7 +123,7 @@
Если правила построены по второму способу, набор завершается правилом с самым низким приоритетом, пустым условием (совпадает всё) и действием bypass: весь трафик, не попавший под предыдущие правила, возвращается оператору без обработки. Тогда на фильтры попадает только трафик, явно отобранный правилами, а всё, что правилами не перечислено, остаётся без фильтрации.
Отбором по VLAN пользуются и при подключении BRAS или CGNAT по схеме on-a-stick: на фильтры отправляют только VLAN одного направления, чтобы каждая сессия обрабатывалась один раз ([раздел 3.4.2](placement.md)).
Отбором по VLAN пользуются и при подключении BRAS или CGNAT по схеме on-a-stick: на фильтры отправляют только VLAN одного участка — до или после BRAS/CGNAT, в обоих направлениях, — чтобы каждая сессия обрабатывалась один раз ([раздел 3.4.2](placement.md)).
### 6.4.2. Отправка трафика на группу балансировки
+1 -1
View File
@@ -210,7 +210,7 @@ Eco Highway должен уметь **различать** трафик, уже
Трафик, который **уже прошёл** через ТСПУ тип А (на нижнем уровне, на уровне доступа), **не должен обрабатываться повторно** на втором эшелоне. Для этого на Eco Highway предусмотрена возможность **прозрачного пропуска** такого трафика — он просто «пролетает насквозь» без фильтрации.
Это позволяет избежать двойной обработки и связанных с ней проблем (удвоение сессий, ложные срабатывания, избыточная нагрузка), аналогичных проблемам двойного прохождения при on-a-stick подключении (подробнее — в [разделе 3.4.3](placement.md)).
Это позволяет избежать двойной обработки и связанных с ней проблем (удвоение сессий, путаница при диагностике, избыточная нагрузка), аналогичных проблемам двойного прохождения при on-a-stick подключении (подробнее — в [разделе 3.4.3](placement.md)).
---
+87 -74
View File
@@ -4,141 +4,154 @@
---
ТСПУ устанавливается **в разрыв каналов связи** оператора и может располагаться в нескольких различных точках его сети. Выбор точки установки влияет на тип трафика, который проходит через ТСПУ, на возможности диагностики и на общую нагрузку на оборудование.
ТСПУ устанавливается **в разрыв каналов связи** оператора и может располагаться в нескольких точках его сети. От точки установки зависят инкапсуляция трафика, которую придётся разбирать ([разделы 2.1](traffic-flow.md) и [10.1.1](filter.md)), возможности диагностики, нагрузка на оборудование и охват: трафик, который разворачивается ниже точки установки, — между абонентами оператора, к кэш-серверам и узлам CDN, подключённым ниже неё, — через ТСПУ не проходит. Мест для установки много: одни предпочтительнее, другие менее удобны, но тоже допустимы.
Если рассматривать сеть оператора от абонентов в сторону выхода в интернет, выделяются три точки установки — до BRAS, между BRAS и CGNAT и после CGNAT, — а также особый случай, когда сервисное оборудование оператора подключено в режиме on-a-stick.
<img width="1024" alt="image" src="https://github.com/user-attachments/assets/e4c166dc-582b-4a20-bbb5-5066f78e8ec6" />
Если рассматривать сеть оператора связи от абонентов в сторону выхода в интернет, можно выделить три основных места установки, а также особый режим подключения — on-a-stick.
_Точки установки ТСПУ: 1 — до BRAS и CGNAT, 2 — после BRAS, но до CGNAT, 3 — после BRAS и CGNAT. Справа — BRAS и CGNAT совмещены в одном устройстве, и точки 2 нет._
<img width="1024" alt="image" src="https://github.com/user-attachments/assets/c8d805d4-ae92-42c2-8959-8adb4140b64a" />
В любой из этих точек ТСПУ тип А должно видеть оба направления трафика: если ответный трафик возвращается в обход ТСПУ, сессия на фильтре не соберётся ([раздел 6.3.3](balancer.md)). Такой асимметричный трафик характерен для уровня ядра и пиринга крупных операторов — для подключений других операторов и корпоративных клиентов с несколькими выходами в интернет; для него предназначена эшелонированная система ([раздел 4.2](echelon.md)).
Каждая точка имеет свои особенности с точки зрения инкапсуляции трафика и возможностей траблшутинга. Некоторые точки более предпочтительны, другие — менее, но все они допустимы для установки ТСПУ.
## 3.1. До BRAS/BNG (между абонентами и терминацией сессий)
Инкапсуляция на стыке оператора, в разрыв которого встаёт ТСПУ, зависит от технологий конкретного оператора и от места установки в его сети. Это могут быть чистые IP-пакеты, пакеты с VLAN-тегами (одним или двумя — QinQ), пакеты с MPLS-метками, PPPoE-пакеты и различные комбинации. ТСПУ должно уметь разбираться со всеми этими заголовками, чтобы добраться до IP-трафика и выполнить его обработку.
Первая точка — между абонентами и устройствами, которые терминируют абонентские сессии:
## 3.1. До BRAS/BPE/BNG (между абонентами и терминацией сессий)
| Тип сети | Устройства терминации сессий |
| ------------------------- | ------------------------------- |
| **Широкополосный доступ** | BRAS, BNG |
| **Мобильные сети** | GGSN, PGW (в сетях 5G SA — UPF) |
Первая возможная точка установки — **между абонентами и устройствами терминации абонентских сессий**. Такими устройствами могут быть:
Далее все они для краткости называются BRAS («условный BRAS»). В этой точке ТСПУ стоит ближе всего к абонентам — до терминации абонентских сессий и трансляции адресов.
| Тип сети | Устройства терминации сессий |
| -------------------- | ------------------------------------ |
| **Широкополосный доступ** | BRAS, BPE, BNG |
| **Мобильные сети** | GGSN, PGW |
Все эти устройства выполняют одну функцию — **терминируют абонентские сессии**. В дальнейшем они обобщённо именуются «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-трафик
Основная особенность установки **до BRAS** — наличие **PPPoE-трафика**. Широкополосные абоненты подключаются к BRAS по протоколу PPPoE, и этот трафик представляет собой дополнительный уровень инкапсуляции, который необходимо обрабатывать.
Если широкополосные абоненты подключаются по PPPoE, на участке до BRAS через ТСПУ идёт **PPPoE-трафик** — ещё один уровень инкапсуляции, который нужно разбирать. Выше BRAS PPPoE в нормально работающей сети не бывает: BRAS терминирует PPPoE-сессии и дальше передаёт обычные IP-пакеты. При подключении абонентов по IPoE этой особенности нет.
Важно: PPPoE-трафик существует **только на участке до BRAS**. Выше BRAS (то есть ближе к интернету) PPPoE-трафика в нормально функционирующих сетях не бывает — BRAS терминирует PPPoE-сессии и дальше передаёт обычные IP-пакеты.
Наличие PPPoE — не проблема, а особенность, которую нужно учесть при настройке. PPPoE на участке доступа часто идёт поверх VLAN или QinQ, поэтому фильтр должен разбирать и VLAN-теги (`vlan_mode`), и сам PPPoE (`pppoe_analyzer`) — [раздел 10.1.1](filter.md); балансировщик PPPoE разбирает ([раздел 6.7](balancer.md)).
Наличие PPPoE не является критической проблемой — это ещё один уровень инкапсуляции, который фильтру нужно разбирать. Однако его необходимо учитывать при настройке: VLAN-теги фильтр разбирает согласно параметру `vlan_mode` (в проекте — `qinq`), а для обработки самого PPPoE в документации производителя описан отдельный параметр `pppoe_analyzer` (по умолчанию выключен; подробнее — в [разделе 10.1.1](filter.md)).
Исключение — схемы с L2TP: BRAS в роли LAC не терминирует PPP, а передаёт PPP-сессии в туннелях L2TP (UDP, порт 1701) на LNS; так же устроено подключение абонентов по L2TP напрямую к LNS. До LNS трафик абонентов идёт внутри L2TP, разбор которого в документации производителя не описан, — на таком участке ТСПУ увидит только туннели.
## 3.2. До CGNAT (после BRAS) — наиболее удобная точка
Вторая точка установки — **между BRAS и CGNAT**. На этом участке BRAS уже терминировал абонентские сессии, но трафик ещё не прошёл трансляцию адресов (NAT).
Вторая точка — **между BRAS и CGNAT**: абонентские сессии уже терминированы на BRAS, но адреса ещё не прошли трансляцию (NAT).
Это, вероятно, **наиболее удобная точка** для установки ТСПУ по двум причинам:
1. **Отсутствие PPPoE** — трафик PPPoE уже терминирован на BRAS, что означает меньшее количество заголовков инкапсуляции для обработки;
2. **Видимость абонентских адресов** — серые (частные) IP-адреса абонентов ещё не прошли через NAT-трансляцию и доступны для анализа.
1. **PPPoE-трафика здесь уже нет** — заголовков инкапсуляции для разбора меньше;
2. **видны абонентские адреса** — серые адреса абонентов (частные или из диапазона 100.64.0.0/10) ещё не прошли трансляцию.
> **Примечание.** BRAS и CGNAT могут быть **совмещены в одном устройстве**. Тогда участка между ними, а значит и этой точки установки, просто нет — ТСПУ ставится либо до этого устройства, либо после него.
### 3.2.1. Видимость серых абонентских IP-адресов
На участке до CGNAT фильтры ТСПУ видят **серые** (частные) IP-адреса абонентов — те самые адреса, которые непосредственно назначены абонентским устройствам. Это даёт существенные преимущества при диагностике:
На участке до CGNAT фильтры видят **серые** адреса — те, что назначены абонентским устройствам. Это упрощает диагностику:
- Можно найти сессию **конкретного абонента** на фильтрах по его IP-адресу;
- Можно определить, что именно происходит с трафиком данного абонента;
- Можно исключить конкретного абонента из обработки DPI-листом (через параметр **No IP**) для диагностики проблем.
- сессию **конкретного абонента** можно найти на фильтрах по его 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**, ближе к выходу в общую сеть интернет. На этом участке трафик уже прошёл трансляцию адресов.
Третья точка — **после CGNAT**, ближе к выходу в интернет. Трафик здесь уже прошёл трансляцию адресов.
### 3.3.1. Только белые адреса, сложности траблшутинга
После CGNAT серых абонентских адресов **больше не видно** — на фильтрах ТСПУ будут присутствовать только **белые** (публичные) IP-адреса из NAT-пула оператора.
После CGNAT серых абонентских адресов **уже не видно**: IPv4-трафик абонентов, выходящих в интернет через NAT, виден на фильтрах с **белыми** адресами из NAT-пула оператора. Со своими адресами остаются видны лишь абоненты с выделенными белыми IPv4-адресами, которых CGNAT не транслирует, и IPv6-трафик (NAT44 его не затрагивает). Это неудобно для траблшутинга:
Это создаёт существенное неудобство при траблшутинге:
- **нельзя напрямую связать** физического абонента с его сессией на ТСПУ — абонентский адрес в сессии уже транслированный, а не исходный;
- чтобы найти абонента, нужно **обращаться к оператору** и выяснять по журналам трансляций CGNAT, в какой адрес и какие порты этот абонент транслировался в нужный момент времени ([разделы 23.2](troubleshooting.md) и [23.7](troubleshooting.md));
- исключить из обработки DPI-листом одного абонента нельзя: `no_ip` исключит адрес NAT-пула, а вместе с ним — всех абонентов, транслированных в этот адрес.
- **Невозможно напрямую связать** конкретного физического абонента с его сессией на ТСПУ — адрес источника в пакете является транслированным (белым), а не оригинальным (серым) адресом абонента;
- Для идентификации абонента необходимо **взаимодействовать с оператором** — запрашивать у него информацию о том, в какие порты и IP-адреса был транслирован конкретный абонент на CGNAT;
- Процесс диагностики становится **значительно более длительным** и требует координации между командой ТСПУ и оператором связи.
Диагностика становится дольше и требует координации между командой ТСПУ и оператором связи.
С точки зрения самой фильтрации (блокировки, распознавания протоколов) размещение после CGNAT не вносит каких-либо ограничений — функциональность ТСПУ остаётся полной. Основное неудобство касается диагностики и траблшутинга. Кроме того, за одним адресом NAT-пула стоит много абонентов, а балансировщик распределяет трафик по парам адресов, поэтому трафик многих абонентов к одному ресурсу попадает на одно ядро фильтра ([раздел 6.5.1](balancer.md)).
На логику фильтрации (блокировку, распознавание протоколов) размещение после CGNAT не влияет — основное неудобство касается диагностики. Стоит учитывать и распределение нагрузки: за одним адресом NAT-пула стоит много абонентов, а балансировщик распределяет трафик по парам адресов, поэтому трафик многих абонентов к одному ресурсу попадает на одно ядро фильтра ([раздел 6.5.1](balancer.md)).
> **Примечание:** в ряде случаев подсистемы BRAS и CGNAT могут быть **совмещены в одном устройстве**. В этом случае участок «между BRAS и CGNAT» (наиболее удобная точка установки) попросту отсутствует — ТСПУ может быть установлено либо до этого комбинированного устройства, либо после него.
## 3.4. Сервисное оборудование в режиме on-a-stick
## 3.4. Режим On-a-stick (BRAS/CGNAT подключены петлёй)
Особый случай — когда сервисное оборудование оператора (BRAS, CGNAT или совмещённое устройство BRAS + CGNAT) подключено к маршрутизатору **в режиме on-a-stick**: одним каналом, физическим или агрегированным, по которому трафик приходит на устройство и уходит с него обратно — как правило, в разных VLAN. Если ТСПУ установлено на этом канале, трафик проходит через него **дважды**. Если канал агрегированный, все его каналы заводятся на один балансировщик ([раздел 6.3.3](balancer.md)).
Помимо трёх линейных точек установки, существует особый вариант размещения ТСПУ — когда сервисное оборудование оператора (BRAS и/или CGNAT) подключено **в режиме on-a-stick** (петлёй).
<img width="1024" alt="image" src="https://github.com/user-attachments/assets/c8d805d4-ae92-42c2-8959-8adb4140b64a" />
В режиме on-a-stick BRAS или CGNAT подключается к оператору **одним агрегированным каналом**, через который трафик уходит к устройству и возвращается обратно. Если ТСПУ установлено на этом участке, трафик **проходит через него дважды**.
_ТСПУ на канале on-a-stick. Слева BRAS и CGNAT подключены каждый к своему маршрутизатору, и на каждом таком канале стоит своё ТСПУ: участки 1 + 2 (BRAS) и 2 + 3 (CGNAT). Справа — совмещённое устройство BRAS + CGNAT, участки 1 + 3. Номера — точки установки из схемы выше._
```text
Абоненты Интернет
│ │
│ ┌────────────┐ │
└─────────┤ ТСПУ ├──────────────────────┘
└──────┬─────┘
│ ↕ (трафик проходит дважды)
┌──────┴─────┐
│BRAS / CGNAT│
│(on-a-stick)│
└────────────┘
Абоненты Интернет
│ ▲
▼ │
┌─────────────────────────────────────────────────┐
│ Маршрутизатор оператора │
└────────────────────────┬────────────────────────┘
│
LAN │ ↓ 1-й проход (участок «до»): входит через LAN
┌─────┴─────┐
│ ТСПУ │
└─────┬─────┘
WAN │ ↑ 2-й проход (участок «после»): входит через WAN
│
┌────────┴────────┐
│ BRAS / CGNAT │
└─────────────────┘
```
Возможны три варианта подключения on-a-stick:
_Оба прохода пересекают ТСПУ целиком, в противоположных направлениях. Ориентация LAN/WAN показана для случая, когда обрабатывается участок «до»._
| Вариант | Что проходит через ТСПУ дважды |
| -------------------------- | ----------------------------------------------------------- |
| **BRAS on-a-stick** | Трафик до BRAS + трафик после BRAS (сегменты 1 + 2) |
| **CGNAT on-a-stick** | Трафик до CGNAT + трафик после CGNAT (сегменты 2 + 3) |
| **BRAS + CGNAT on-a-stick**| Трафик до обоих устройств + трафик после обоих (сегменты 1 + 3) |
На канале 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 трафик проходит через ТСПУ **дважды**:
При подключении on-a-stick трафик проходит через ТСПУ дважды:
1. **Первый проход** — трафик от абонентов идёт через ТСПУ к BRAS/CGNAT;
2. **Второй проход** — после обработки на BRAS/CGNAT трафик возвращается через ТСПУ в сторону интернета (или обратно к абонентам — в зависимости от направления).
1. **Первый проход** — трафик абонентов идёт от маршрутизатора через ТСПУ к BRAS/CGNAT;
2. **Второй проход** — обработанный трафик возвращается через ТСПУ к маршрутизатору и дальше в интернет.
Это означает, что каждая абонентская сессия потенциально **видна фильтрам дважды**, причём на втором проходе адреса могут быть уже другими (после NAT-трансляции на CGNAT). Без дополнительных мер это приводит к удвоению количества сессий и удвоению нагрузки на ТСПУ.
Ответный трафик проходит те же два участка в обратном порядке.
### 3.4.2. Разделение по VLAN для обработки трафика одного направления
Поэтому, если участки не разделены ([раздел 3.4.2](#342-обработка-только-одного-участка)), каждая абонентская сессия попадает на фильтры дважды: после CGNAT — уже с другими, транслированными адресами, после BRAS — с другой инкапсуляцией (например, без PPPoE).
**Наиболее удобная конфигурация** при подключении on-a-stick — когда оператор чётко разделяет трафик по VLAN:
Кроме того, два прохода пересекают ТСПУ в противоположных направлениях, а ориентация LAN/WAN задаётся подключением. LAN-сторона ТСПУ должна смотреть в сторону абонентов обрабатываемого участка: для участка «до» — к маршрутизатору, для участка «после» — к BRAS/CGNAT. Другой участок при этом неизбежно проходит через ТСПУ в обратной ориентации: фильтр принимает адреса интернет-ресурсов за локальные, а абонентские (или NAT-) адреса — за удалённые ([разделы 12.5](filter-sessions.md) и [23.6](troubleshooting.md)).
- **Один VLAN** несёт трафик **до** BRAS/CGNAT (от абонентов к сервисному оборудованию);
- **Другой VLAN** несёт трафик **после** BRAS/CGNAT (от сервисного оборудования в сторону интернета).
### 3.4.2. Обработка только одного участка
В этом случае на ТСПУ можно настроить обработку **только нужного VLAN** (например, трафика до CGNAT, где видны серые абонентские адреса), а второй VLAN — **прозрачно пропустить** на уровне балансировщика, даже не отправляя его на фильтры.
**Удобнее всего**, когда трафик двух участков можно чётко различить — например, оператор разделяет их по VLAN:
Это достигается через **flow rules** балансировщика (подробнее — в [разделе 6.4](balancer.md)):
- в одних VLAN идёт трафик участка «до» — между абонентами и BRAS/CGNAT, в обоих направлениях;
- в других — трафик участка «после», между BRAS/CGNAT и интернетом.
- Правило с действием `balancing` — для VLAN, который нужно обрабатывать (трафик отправляется на фильтры);
- Правило с действием `bypass` — для VLAN, который нужно пропустить (трафик прозрачно проходит через балансировщик).
Тогда ТСПУ обрабатывает только нужный участок, а трафик другого балансировщик **пропускает прозрачно**, даже не отправляя его на фильтры. Это настраивается правилами (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
Если оператор **не может** чётко отделить трафик до и после BRAS/CGNAT (например, оба направления идут в одном VLAN), возникает ситуация **двойной обработки**. Её последствия:
Если участки не удаётся разделить ни по VLAN, ни другими условиями (например, оператор не может однозначно указать, какие VLAN относятся к какому участку), ТСПУ обрабатывает трафик дважды:
- **Удвоение количества сессий** — одна и та же абонентская сессия видна фильтру дважды, причём с разными IP-адресами (до и после NAT-трансляции);
- **Путаница при траблшутинге** — сложно определить, какая из двух записей сессии соответствует реальному состоянию;
- **Двойная нагрузка на ТСПУ** — запас производительности должен быть рассчитан исходя из удвоенного объёма трафика.
- **сессий вдвое больше** — одна и та же абонентская сессия проходит через фильтры два раза, в том числе с разными адресами (до и после трансляции);
- **путаница при траблшутинге** — у одной сессии две записи, причём на втором проходе с перевёрнутой ориентацией: адрес абонента там записан как удалённый, поэтому исключение параметром `no_ip` на этот проход не действует, и проверка по [разделу 23.5](troubleshooting.md) может дать ложный результат;
- **двойная нагрузка** — запас производительности фильтров приходится рассчитывать исходя из удвоенного объёма трафика.
Эта ситуация **нежелательна** и её следует избегать при проектировании. В лучшем варианте необходимо добиться от оператора информации о разделении трафика по VLAN и выбрать для обработки только нужное направление.
Такой ситуации следует всячески **избегать** при проектировании: лучший вариант — получить от оператора информацию о разделении трафика и обрабатывать только нужный участок.
> **Пример из практики:** на пилотном проекте (Урал) один из операторов подключён по принципу on-a-stick к CGNAT (сегменты 2 + 3 на схеме). Оператор предоставил информацию о том, какие VLAN несут трафик до CGNAT, а какие — после. На балансировщике были отобраны только нужные VLAN и отправлены на фильтры. В результате фильтры видят нормальные абонентские сессии до CGNAT (с серыми адресами) и не обрабатывают транслированный трафик после CGNAT. Это — **best practice** подключения on-a-stick.
Возможен и **обратный подход**: вместо явного указания обрабатываемых VLAN можно исключить ненужные VLAN из обработки, а всё остальное — обрабатывать. Выбор подхода — вопрос удобства настройки для конкретной площадки.
> **Пример из практики:** на пилотном проекте на Урале у одного из операторов CGNAT подключён в режиме on-a-stick (участки 2 + 3). Оператор сообщил, какие VLAN несут трафик до CGNAT, а какие — после, и на балансировщике на фильтры направили только VLAN участка до CGNAT. Фильтры видят обычные абонентские сессии с серыми адресами и не обрабатывают трафик после трансляции. Это и есть **best practice** подключения on-a-stick.
---
+1 -1
View File
@@ -60,7 +60,7 @@ _Стык оператора: адреса и порты в прямом и об
| **MPLS** | Одна или несколько MPLS-меток |
| **VLAN + MPLS** | VLAN-тег(и), за ними стек MPLS-меток |
| **Ethernet поверх MPLS** | Внутри MPLS-меток — вложенный Ethernet-кадр со своими VLAN-тегами (псевдопровод EoMPLS, VPLS), и только затем IP |
| **PPPoE** | PPPoE-заголовок и PPP-заголовок перед IP; характерен для участка абонент → BRAS ([раздел 3.1](placement.md)) |
| **PPPoE** | PPPoE-заголовок и PPP-заголовок перед IP; характерен для участка абонент → BRAS ([раздел 3.1.1](placement.md)) |
| **PPPoE + MPLS** | PPPoE-кадр, в свою очередь упакованный в MPLS (например, перенос PPPoE до BRAS через псевдопровод) |
Вариантов инкапсуляции в операторских сетях очень много, и перечислить их исчерпывающе невозможно — на стыке может встретиться практически что угодно. Ключевой момент: **ТСПУ должен уметь разбирать все эти заголовки**, чтобы добраться до IP-пакета и выполнить его анализ и обработку. Все манипуляции выполняются только с IP-пакетом; заголовки инкапсуляции, стоящие перед ним (VLAN-теги, MPLS-метки, PPPoE), ни балансировщик, ни фильтр не снимают и не модифицируют — пакет возвращается оператору с тем же стеком заголовков, с которым пришёл. Служебный заголовок, который балансировщик добавляет для передачи пакета фильтру внутри ТСПУ, снимается до возврата пакета оператору (см. [2.4](#24-типовая-схема-тспу)). Если IP-пакета в стеке заголовков не обнаружено, такой трафик пропускается прозрачно и на фильтры не отправляется.
+10 -9
View File
@@ -92,7 +92,7 @@
### Особенности при установке после CGNAT
Если ТСПУ установлен **после CGNAT** (см. [раздел 3.3](placement.md)), на фильтре видны только белые (транслированные) адреса. Для идентификации конкретного абонента необходимо **взаимодействие с оператором** — оператор должен сообщить, в какие порты и IP-адреса абонент был транслирован.
Если ТСПУ установлен **после CGNAT** (см. [раздел 3.3.1](placement.md)), на фильтре видны только белые (транслированные) адреса. Для идентификации конкретного абонента необходимо **взаимодействие с оператором** — оператор должен по журналам трансляций CGNAT сообщить, в какой адрес и какие порты абонент был транслирован в нужный момент времени.
## 23.3. Проверка ресурса в DPI-листах: `show dpi match`
@@ -220,7 +220,7 @@
Основной признак — при просмотре сессий на фильтре в поле **local** отображаются адреса, которые **не являются абонентскими**:
- Вместо серых (приватных) абонентских адресов в local видны белые интернет-адреса;
- в local видны адреса интернет-ресурсов, а не адреса абонентов оператора (серые — или белые адреса NAT-пула, если ТСПУ стоит после CGNAT, [раздел 3.3.1](placement.md));
- Направление сессий (Egress/Ingress) не соответствует ожидаемому.
Это происходит потому, что фильтр определяет направление трафика по портам: трафик, приходящий в LAN-порт, считается абонентским, а source IP записывается как local. Если LAN и WAN перепутаны, source IP интернет-хоста ошибочно записывается как local.
@@ -229,11 +229,12 @@
### Где может произойти перепутка
| Место | Описание |
| ------------------------------ | ----------------------------------------------------------- |
| **На байпасе** | Кабели LAN и WAN подключены к неправильным портам байпаса |
| **На балансировщике** | Порты в линке назначены неверно (LAN вместо WAN и наоборот) |
| **На коммутаторе оператора** | Кабели между оператором и байпасом подключены неверно |
| Место | Описание |
| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **На байпасе** | Кабели LAN и WAN подключены к неправильным портам байпаса |
| **На балансировщике** | Порты в линке назначены неверно (LAN вместо WAN и наоборот) |
| **На коммутаторе оператора** | Кабели между оператором и байпасом подключены неверно |
| **Канал on-a-stick** | Участки до и после BRAS/CGNAT не разделены: трафик одного из них проходит через ТСПУ в обратной ориентации — это следствие схемы, а не ошибка подключения ([раздел 3.4.1](placement.md)) |
### Последствия перепутки
@@ -246,8 +247,8 @@
### Диагностика
1. Выполнить `show session` и проверить поле local — должны быть абонентские (серые) адреса;
2. Если в local видны белые адреса — вероятна перепутка;
1. Выполнить `show session` и проверить поле local — должны быть адреса абонентов оператора (серые или, после CGNAT, адреса NAT-пула);
2. Если в local видны адреса интернет-ресурсов — вероятна перепутка;
3. Проверить физическое подключение кабелей;
4. Проверить конфигурацию линков на балансировщике.