# Шаг 4 — оценка: публичная балансировка без conntrack

**Дата:** 2026-08-18
**Статус:** оценка осуществимости (не план внедрения и не реализация)
**Область:** только публичный листенер `192.168.5.21:80`
**Источник:** [PUBLIC_LB_DATAFLOW.md](PUBLIC_LB_DATAFLOW.md), `lb/pipeline.sh`
(таблицы 12, 15, 16)
**Смежные документы:** [PRIVATE_LB_DATAFLOW.md](PRIVATE_LB_DATAFLOW.md),
[MAGLEV_SLOT_TABLE.md](MAGLEV_SLOT_TABLE.md)

## Задача

Оценить переход публичного пути с текущей stateful-схемы (`ct(commit,nat)` на
прямом пути, `ct(nat)` на обратном) на схему без conntrack. Главное условие,
заданное на входе: **бэкенд обязан видеть реальный IP клиента** — адрес, с
которым клиент обратился на балансировщик, до всех преобразований.

Уточнение по ходу обсуждения: клиент **всегда** обращается на адрес
балансировщика (VIP), не на бэкенд напрямую. Он должен получить ответ, который
его TCP-стек и приложение примут как продолжение своего же соединения — то есть
`src` ответа обязан остаться `VIP:80`.

## Вывод

Технически осуществимо для нового трафика через публичный листенер, при двух
явных условиях периметра и одном принимаемом изменении поведения:

1. бэкенды не должны быть достижимы клиентами напрямую, в обход VIP (условие
   периметра, не техническое ограничение датапаса);
2. правило обратной трансляции обязано быть сужено по адресу назначения,
   иначе оно ломает трафик между бэкендами;
3. установленные сессии перестают быть защищены от смены состава пула — это
   принимаемый компромисс, а не дефект.

## 1. Что меняется в датапасе

| Таблица | Сейчас | Предлагается |
|---|---|---|
| 12 (прямой DNAT) | `ct(commit, zone=1, nat(dst=member:8080))` | `mod_nw_dst:<member_ip>, mod_tp_dst:<member_port>` — без `ct` вообще |
| 15 (обратный путь) | одно правило `tcp actions=ct(table=16,zone=1,nat)` на весь трафик | по одному правилу на каждого члена: `tcp,nw_src=<member_ip>,tp_src=<member_port>,nw_dst=$PUB_NET actions=mod_nw_src:$VIP,mod_tp_src:$VIP_PORT,goto_table:16` |
| 16 | пост-`ct` — счётчики | не нужна для этого пути; сохраняется для транзита, где `ct` ещё используется |

`src` клиента в т.12 не трогается ни сейчас, ни в новой схеме — сохранение IP
клиента никогда не зависело от `ct`, поэтому по этой части поведение не
меняется вообще.

Обоснование замены в т.15 — §2.2 дизайна v1: DNAT переписывает адрес назначения
в фиксированный `member_ip:member_port`, а не в случайный порт, как SNAT.
Поэтому пара `(member_ip, member_port, proto)` однозначно определяет
`(VIP, listener_port)`, и обратную трансляцию можно сделать статическим
правилом без какого-либо состояния.

## 2. Условие периметра: прямой доступ к бэкенду должен быть закрыт

Таблица 1 отправляет в т.15 весь трафик с `dl_dst = MAC шлюза сегмента`, не
различая, был ли пакет частью балансируемой сессии. Сегодняшний стенд умеет и
поддерживает прямой доступ клиента к бэкенду в обход VIP (`table=10,
priority=100,ip actions=goto_table:20`, проверяется в `verify.sh` секция 5 и
`MANUAL_TEST_PLAN` блок C.2) — ответ на такое обращение и ответ на сессию через
VIP дают на выходе бэкенда идентичные заголовки (`src=member_ip:8080,
dst=client_ip:client_port`), различить их без состояния невозможно.

При заданном требовании — клиент всегда обращается на VIP — эта коллизия не
относится к реальному клиентскому трафику. Она становится значимой только если
прямой доступ к порту бэкенда остаётся разрешён одновременно со stateless-схемой.
Вывод: **предпосылка корректности схемы — бэкенды недостижимы клиентами
напрямую**, что и так является типовой практикой для облачных LB (изоляция
периметра, security groups), а не новым ограничением, придуманным ради этого
перехода.

## 3. Связность между бэкендами

Уточняющий вопрос по ходу оценки: не потеряют ли бэкенды способность общаться
друг с другом. Ответ разделяется по топологии.

**Бэкенды в разных сегментах.** Ответ `be1 → be2:8080` (транзит между
сегментами) идёт через ту же таблицу 15, что и обратный трафик клиентских
сессий, потому что оба используют один и тот же MAC шлюза сегмента как
классификатор. Правило `nw_dst=$PUB_NET` в предложенном un-DNAT решает это:
адресные пространства клиентов (`192.168.5.0/24`) и бэкендов (приватные
сегменты) не пересекаются, поэтому транзитный трафик просто не попадает под
условие правила и проходит немодифицированным. **Связность между сегментами
сохраняется**, если это условие включено в правило.

**Бэкенды в одном сегменте.** Это территория приватного пути (таблица 24,
шаг 3), не публичного, и в этой оценке не менялась — она по-прежнему на `ct`.
Если в будущем этот путь тоже переводить на stateless-схему, префиксный
критерий не сработает: в шаге 3 клиент и бэкенды намеренно живут в одной
подсети, поэтому ответ `be3 → be1` и ответ `be3 → реальный клиент cli2`
неотличимы по заголовкам. Решение для этого случая другое — не диапазон
адресов, а явный список исключений (для каждого члена сегмента: «если
назначение — адрес другого известного члена этого же сегмента, не
транслировать»), которые должны иметь приоритет выше общего правила un-DNAT.
Список членов конечен и известен заранее, в отличие от адресов произвольных
клиентов, поэтому это решаемо, но требует отдельного набора правил и не входит
в объём этой оценки (она ограничена публичным путём).

## 4. Изменение поведения: установленные сессии больше не защищены

Сейчас `ct(commit)` закрепляет привязку за соединением на весь срок его жизни
независимо от таблицы слотов — это подтверждено в `STEP2_SUMMARY.md`: сессия,
обслуживаемая выведенным из пула членом, не рвётся (`verify.sh` секция 13,
`MANUAL_TEST_PLAN` блок I).

Без `ct` трансляция каждого пакета определяется исключительно текущим
состоянием таблицы слотов. При выводе члена из пула следующий пакет уже
установленной к нему сессии уйдёт на другого члена — без контекста
TCP-соединения, и сессия оборвётся. Минимальное возмущение Maglev ограничивает
**долю** пострадавших сессий (переезжают только слоты выбывшего члена, у
остальных ничего не меняется), но не защищает сами эти сессии.

Это ровно тот компромисс, который был предсказан заранее в `STEP2_SUMMARY.md`:
«ценность таблицы слотов раскроется при переходе на stateless-датапас, где
единственной защитой от переезда сессий останется минимальное возмущение
раскладки». Переход на публичном пути — первое место, где это предсказание
становится проверяемым поведением, а не наблюдением.

Практическое следствие: тест «сессия переживает дренаж» (`verify.sh` секция 13)
для публичного пути перестаёт быть верным и требует пересмотра или явного
исключения из проверок при внедрении.

## 5. Узкое остаточное ограничение (из дизайна v1)

Если сам бэкенд когда-либо инициирует исходящее TCP-соединение с src-портом,
равным его собственному порту прослушивания (8080), и адресует его в
клиентскую сеть — такой пакет попадёт под правило un-DNAT и будет неверно
переписан. Маловероятный случай (обычно исходящие соединения используют
эфемерный порт источника), уже документирован в дизайне v1 (§3.2, «остаточное
ограничение», §15.4). Переход на stateless ничего не меняет в этом отношении —
ограничение существовало бы в любой чисто заголовочной схеме un-DNAT.

## 6. Что выигрывается

- `ct` и зависимость от `CT_ZONE` уходят из публичного пути целиком — оба
  направления становятся чистым `match + rewrite`.
- Меньше recirculation в датапасе: на момент оценки в датапасе стенда
  зафиксировано 6 потоков с `ct(...)`, каждый вызывает `recirc`; на публичном
  пути они исчезают.
- Снимается ограничение, зафиксированное в `PUBLIC_LB_DATAFLOW.md` (раздел 9):
  «прямой и обратный трафик сессии обязаны проходить через один узел». Это
  предпосылка, без которой Active/Active ECMP между несколькими узлами LB не
  имеет смысла обсуждать — устраняется она именно этим шагом.

## 7. Что не меняется

Маршрутизация (таблицы 20/21), таблица слотов (таблица 11), алгоритм Maglev,
детерминизм `multipath` — не затрагиваются вообще. Ограничения по ICMP-ошибкам
и фрагментации сохраняются в прежнем виде — они не были связаны с `ct` и
раньше.

## 8. Отдельный вопрос: доставка до физического сервера в EVPN-фабрике

Поднят по ходу обсуждения, зафиксирован здесь как связанный, но не
пересекающийся с темой `ct`.

Вопрос: если нода HPNN подключена к EVPN-фабрике, и MAC сетевого порта
физического сервера-бэкенда доходит до HPNN через фабрику — будет ли трафик
доставлен до сервера?

**Ответ: это не зависит от наличия или отсутствия `ct`.** Трансляция адреса
(таблицы 12/15) и доставка кадра до правильного MAC (таблица 21, adjacency) —
независимые механизмы. `ct` в доставке кадра не участвует ни сейчас, ни в
предложенной схеме.

Реальная зависимость — в существующей модели adjacency: MAC членов пула сейчас
**статически** прописаны в `topology.env` и заливаются в таблицу 21 константами
(`mod_dl_dst:$BE1_MAC`). Это уже задокументированное ограничение —
`STEP1_SUMMARY.md`: «MAC бэкендов прописаны статически. ARP-резолвер next-hop
отсутствует». Дизайн v1 предполагал агента, резолвящего MAC next-hop через
packet-in/packet-out по своей neigh-таблице (§4.3, §8.2), но это не
реализовано ни в стенде, ни где-либо ещё.

То, что MAC физического порта доходит до HPNN по EVPN-фабрике, — свойство самой
фабрики (leaf-коммутаторы разучивают MAC локально, публикуют по EVPN Type-2
остальным VTEP); HPNN в этом процессе не участвует, для него это просто кадры
на порту аплинка. Вопрос не в том, дойдёт ли MAC до HPNN (дойдёт), а в том,
знает ли пайплайн HPNN, какой MAC подставить в `mod_dl_dst`, когда решает
отправить пакет этому серверу. При текущей статической модели — знает только
то, что вручную прописано заранее. Если реальный MAC карты сервера не совпадает
с прописанным (замена карты, переключение LACP/бондинга на другой физический
линк, сервер ещё не был известен на момент конфигурации) — таблица 21 либо
отправит кадр не туда, либо, если совпадения нет вовсе, попадёт под
`priority=0 actions=drop`: трафик до сервера не дойдёт, несмотря на то что
фабрика прекрасно знает его настоящий MAC.

Это существующий пробел архитектуры, не имеющий отношения к переходу на схему
без conntrack — он не блокирует и не усложняет этот шаг. Требует отдельной
оценки: динамический ARP-резолвер next-hop (как и предполагал дизайн v1) либо
интеграция с тем, как EVPN-фабрика публикует MAC-привязки, чтобы control plane
HPNN получал их не вручную, а из фабрики.

> **Обновление (шаг 5, [STEP5_SUMMARY.md](STEP5_SUMMARY.md)):** первая часть
> этого пробела закрыта — `hcd` резолвит MAC членов пула динамически через
> обычный ARP ядра, статических `BE*_MAC` в таблице 21 больше нет. Это не
> решает вопрос EVPN-фабрики целиком: `hcd` резолвит MAC в пределах L2-домена,
> видимого узлу напрямую (те же hcif-порты, что и для health-проб), а не через
> интеграцию с EVPN Type-2. Если фабрика доставляет сегмент до узла как один
> L2-домен (что и предполагает текущая архитектура), тот же ARP-путь работает
> без изменений; отдельная интеграция с control plane EVPN остаётся вне рамок.

## 9. Итоговая сводка условий и рисков

| # | Пункт | Тип | Статус |
|---|---|---|---|
| 1 | Бэкенды недостижимы клиентами напрямую, только через VIP | предпосылка периметра | требует явного решения при внедрении |
| 2 | Правило un-DNAT сужено `nw_dst=$PUB_NET` | техническое условие | зафиксировано в предложенной схеме |
| 3 | Связность между сегментами (be↔be, разные сегменты) | проверено | сохраняется при условии (2) |
| 4 | Связность внутри сегмента (be↔be, один сегмент) | вне объёма этой оценки | не тронуто (путь на `ct`); при переносе на stateless требует отдельного набора исключений |
| 5 | Установленные сессии при смене состава пула | изменение поведения | принимаемый компромисс, требует пересмотра теста `verify.sh` §13 |
| 6 | Исходящий трафик бэкенда с src-портом = 8080 в клиентскую сеть | остаточное ограничение | узкое, уже документировано в дизайне v1 |
| 7 | Доставка до физического сервера по MAC (EVPN) | отдельный вопрос | не связан с `ct`; существующий пробел модели adjacency |

## 10. Что дальше

Это оценка осуществимости, не план внедрения. Следующий шаг, если решение
принято, — оформить отдельный план и итоги по конвенции репозитория
(`STEP4_IMPLEMENTATION_PLAN.md` / `STEP4_SUMMARY.md`), с явной фиксацией
решений по пунктам 1 и 5 таблицы выше как условий приёмки, и отдельной оценкой
пункта 7 при планировании физического окружения.