L4 vs L7 балансировка и сохранение IP клиента

Логи сервиса показывают, что все запросы приходят с одного IP — IP балансировщика. Нельзя применить rate limiting по клиенту, geo-блокировку, нельзя провести аудит. Это цена невнимательного выбора уровня, на котором работает балансировщик.

Layer 4: маршрутизация по IP и порту

L4 балансировщик видит только TCP или UDP заголовок. Маршрутизирует по 4-tuple: IP источника, порт источника, IP назначения, порт назначения. HTTP-payload он никогда не читает.

Механика:

• Видит TCP SYN от клиента.
• Выбирает backend по настроенному алгоритму.
• Либо перезаписывает IP назначения (режим NAT), либо открывает новое TCP-соединение к backend (режим прокси).
• Передаёт сырые TCP-сегменты в обоих направлениях.

Стоимость: ~1–5 мкс на пакет, <1% CPU. Пропускная способность: 10–40 Гбит/с на сервер.

Что L4 умеет:

• Маршрутизировать любой TCP/UDP-протокол (PostgreSQL, Redis, MQTT, кастомный бинарный).
• Обрабатывать миллионы соединений в секунду.
• Завершать TCP независимо от HTTP.

Что L4 не умеет:

• Инспектировать или модифицировать HTTP-заголовки, путь или host.
• Делать retry на HTTP 5xx (он не понимает HTTP).
• Завершать TLS без понимания формата TLS-записей.
• Маршрутизировать /api/v1/ и /api/v2/ на разные backends.

Layer 7: маршрутизация по содержимому HTTP

L7 балансировщик завершает HTTP (и TLS) соединение, парсит запрос и применяет правила маршрутизации перед пересылкой на backend.

Механика:

1. Завершает TLS клиента — видит открытый текст.
2. Читает HTTP-метод, путь, заголовок Host, кастомные заголовки.
3. Применяет правила маршрутизации (например, /api/ → пул A, /static/ → пул B).
4. Открывает новое соединение (или переиспользует пул) к выбранному backend.
5. Пересылает запрос (добавляя proxy-заголовки, такие как X-Forwarded-For).

Стоимость: ~100–500 мкс на запрос, 5–15% CPU. Пропускная способность: 1–10 Гбит/с на сервер.

Что L7 добавляет к L4:

• Маршрутизацию по содержимому: путь, hostname, заголовок, cookie.
• Retry на 5xx (понимает HTTP-семантику).
• Метрики на endpoint, rate limiting, проверки аутентификации.
• Завершение TLS один раз на edge LB вместо каждого backend.
• Разделение трафика (10% → canary, 90% → stable).

Сохранение IP клиента

Когда LB пересылает запрос на backend, backend видит IP LB в качестве TCP-источника — не реальный IP клиента. Существуют три стандарта для восстановления этой информации:

X-Forwarded-For (XFF)

X-Forwarded-For: 203.0.113.195

LB добавляет IP клиента в этот заголовок. Только для HTTP. Тривиально подделывается: вредоносный клиент может отправить X-Forwarded-For: 1.2.3.4, и непроверенный прокси добавит его, а не перезапишет. Надёжен только крайний правый IP, добавленный доверенным прокси.

Заголовок RFC 7239 Forwarded

Forwarded: for=203.0.113.195;proto=https;host=example.com

Стандартизированный (RFC 7239), структурированный формат, сложнее некорректно распарсить. Включает протокол и host вместе с IP. Только для HTTP, но менее подвержен случайному неверному разбору.

PROXY protocol (HAProxy)

Текстовый или бинарный заголовок, добавляемый перед TLS/HTTP-payload:

PROXY TCP4 203.0.113.195 93.184.216.34 35646 80\r\n

Работает для любого TCP/UDP-протокола — HTTP не нужен. TCP-стек backend читает заголовок до любого парсинга на прикладном уровне. Сложнее подделать, чем HTTP-заголовок, поскольку вставляется на транспортном уровне доверенным прокси. Nginx, HAProxy и Envoy поддерживают PROXY protocol.

Что выбрать: HTTP-сервисы за доверенными прокси → XFF или RFC 7239. Не-HTTP-сервисы (PostgreSQL, MQTT, кастомный бинарный) или там, где важна устойчивость к подделке → PROXY protocol.