Оценить переход публичного пути с текущей 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-схемой.
| 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 таблицы выше как условий приёмки, и отдельной оценкой
