From 71843bce8a984ddb50360492ec29e83a2c5d70c6 Mon Sep 17 00:00:00 2001 From: Daniel Lavrushin Date: Wed, 23 Sep 2026 21:42:26 +0200 Subject: [PATCH] update section 3 --- README.md | 4 +- docs/balancer.md | 2 +- docs/echelon.md | 2 +- docs/placement.md | 161 ++++++++++++++++++++++------------------ docs/traffic-flow.md | 2 +- docs/troubleshooting.md | 19 ++--- 6 files changed, 102 insertions(+), 88 deletions(-) diff --git a/README.md b/README.md index 02c0c26..4b87090 100644 --- a/README.md +++ b/README.md @@ -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) diff --git a/docs/balancer.md b/docs/balancer.md index 03c0615..51307a6 100644 --- a/docs/balancer.md +++ b/docs/balancer.md @@ -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. Отправка трафика на группу балансировки diff --git a/docs/echelon.md b/docs/echelon.md index 4fcfe61..5144215 100644 --- a/docs/echelon.md +++ b/docs/echelon.md @@ -210,7 +210,7 @@ Eco Highway должен уметь **различать** трафик, уже Трафик, который **уже прошёл** через ТСПУ тип А (на нижнем уровне, на уровне доступа), **не должен обрабатываться повторно** на втором эшелоне. Для этого на Eco Highway предусмотрена возможность **прозрачного пропуска** такого трафика — он просто «пролетает насквозь» без фильтрации. -Это позволяет избежать двойной обработки и связанных с ней проблем (удвоение сессий, ложные срабатывания, избыточная нагрузка), аналогичных проблемам двойного прохождения при on-a-stick подключении (подробнее — в [разделе 3.4.3](placement.md)). +Это позволяет избежать двойной обработки и связанных с ней проблем (удвоение сессий, путаница при диагностике, избыточная нагрузка), аналогичных проблемам двойного прохождения при on-a-stick подключении (подробнее — в [разделе 3.4.3](placement.md)). --- diff --git a/docs/placement.md b/docs/placement.md index 6bc329d..115b8d1 100644 --- a/docs/placement.md +++ b/docs/placement.md @@ -4,141 +4,154 @@ --- -ТСПУ устанавливается **в разрыв каналов связи** оператора и может располагаться в нескольких различных точках его сети. Выбор точки установки влияет на тип трафика, который проходит через ТСПУ, на возможности диагностики и на общую нагрузку на оборудование. +ТСПУ устанавливается **в разрыв каналов связи** оператора и может располагаться в нескольких точках его сети. От точки установки зависят инкапсуляция трафика, которую придётся разбирать ([разделы 2.1](traffic-flow.md) и [10.1.1](filter.md)), возможности диагностики, нагрузка на оборудование и охват: трафик, который разворачивается ниже точки установки, — между абонентами оператора, к кэш-серверам и узлам CDN, подключённым ниже неё, — через ТСПУ не проходит. Мест для установки много: одни предпочтительнее, другие менее удобны, но тоже допустимы. + +Если рассматривать сеть оператора от абонентов в сторону выхода в интернет, выделяются три точки установки — до BRAS, между BRAS и CGNAT и после CGNAT, — а также особый случай, когда сервисное оборудование оператора подключено в режиме on-a-stick. image -Если рассматривать сеть оператора связи от абонентов в сторону выхода в интернет, можно выделить три основных места установки, а также особый режим подключения — on-a-stick. +_Точки установки ТСПУ: 1 — до BRAS и CGNAT, 2 — после BRAS, но до CGNAT, 3 — после BRAS и CGNAT. Справа — BRAS и CGNAT совмещены в одном устройстве, и точки 2 нет._ -image +В любой из этих точек ТСПУ тип А должно видеть оба направления трафика: если ответный трафик возвращается в обход ТСПУ, сессия на фильтре не соберётся ([раздел 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** (петлёй). +image -В режиме 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. --- diff --git a/docs/traffic-flow.md b/docs/traffic-flow.md index 58719e6..06f8787 100644 --- a/docs/traffic-flow.md +++ b/docs/traffic-flow.md @@ -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-пакета в стеке заголовков не обнаружено, такой трафик пропускается прозрачно и на фильтры не отправляется. diff --git a/docs/troubleshooting.md b/docs/troubleshooting.md index 3c38e77..e8d2572 100644 --- a/docs/troubleshooting.md +++ b/docs/troubleshooting.md @@ -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. Проверить конфигурацию линков на балансировщике.