Настройка IP Transparency

Введение

В обычном режиме работы балансировщик открывает соединение к бэкенду от своего имени: бэкенд видит IP‑адрес балансировщика, а не реального клиента. Это может быть проблемой, если бэкенду необходима информация об источнике запроса – для аутентификации, geo‑фильтрации, логирования, аналитики, A/B-тестирования или whitelist/blacklist по IP.

IP Transparency (прозрачный режим) решает эту задачу: балансировщик подменяет исходный IP‑адрес (source IP) в пакетах, идущих к бэкенду, на адрес реального клиента. С точки зрения прикладного ПО на бэкенде соединение выглядит как прямое – становятся доступны реальные IP клиентов.

Как это работает

Технически балансировщик системы 5А выполняет три задачи:

1. Подмена source IP – в IP-заголовке исходящего пакета, направляемого на бэкенд, вместо своего адреса подставляется IP-адрес реального клиента. Для этого в конфигурацию NGINX автоматически добавляется директива proxy_bind $remote_addr transparent.

2. Обеспечение возврата трафика – бэкенд отвечает на IP клиента. Чтобы ответные пакеты попали обратно на балансировщик, на каждом бэкенде администратор инфраструктуры должен вручную настроить default gateway, указывающий на балансировщик (или на VIP кластера). Балансировщик не может автоматизировать эту настройку, так как бэкенды находятся вне его зоны управления.

3. Приём «чужих» пакетов на балансировщике – по умолчанию ядро ОС отбрасывает пакеты, адрес получателя которых не принадлежит самому балансировщику. Для корректной обработки возвратного трафика на каждом сетевом агенте автоматически создаются:

   • таблица nftables с именем transparency, содержащая наборы адресов бэкендов и правила маркировки;
   • правило маршрутизации (ip rule) для пакетов с меткой fwmark 1, направляющее их в таблицу маршрутизации 100;
   • маршрут в таблице 100: local default dev lo.

Всё это создаётся при старте агента и существует постоянно; при включении/выключении IP Transparency для конкретного сервиса обновляются только наборы transparent_endpoints в nftables.

Включение IP Transparency

Включение прозрачного режима выполняется в настройках конфигурации балансировки:

1. Откройте нужный кластер балансировки.
2. Перейдите в раздел Конфигурации балансировки.
3. Создайте новую или отредактируйте существующую конфигурацию.
4. На вкладке Сервисы найдите блок Исходящий трафик.
5. В поле Режим трансляции адресов выберите значение Прозрачный IP.

• Прозрачный IP (IP Transparency) – при выборе этого режима балансировщик автоматически настраивает подмену source IP на адрес реального клиента.

Настройка на бэкендах

Обязательное действие, выполняемое вне продукта – обеспечить, чтобы ответный трафик от бэкендов достигал балансировщика.

• Default gateway – на каждом бэкенде, обслуживающем трафик с включённой IP Transparency, пропишите default gateway, указывающий на IP‑адрес балансировщика (или на VIP кластера).

# Пример для одного бэкенда:
ip route del default
ip route add default via 10.0.0.10   # IP балансировщика или VIP

Особенности при отказоустойчивости

VRRP (Active-Passive) – Рекомендуемая схема

При использовании VRRP для отказоустойчивости GSLB-кластера схема работы IP Transparency надёжна и проста:

• Клиенты обращаются на общий VIP (виртуальный IP).
• Бэкенды используют этот же VIP как default gateway.
• Весь трафик – и входящий от клиентов, и ответный с бэкендов – проходит через один и тот же физический узел, который в данный момент является MASTER.
• Балансировщик видит оба направления сессии, таблица соединений (conntrack) работает корректно, IP клиента сохраняется.

BGP (Active-Active) – Не рекомендуется

При использовании BGP в режиме Active-Active возникает проблема асимметричного роутинга:

1. Входящий трафик от клиента распределяется между балансировщиками (LB-A и LB-B) на основе хеша от параметров соединения (например, по src IP, dst IP, src port, dst port).
2. Запрос попадает на LB-A. Балансировщик фиксирует сессию у себя и передаёт пакет на бэкенд.
3. Бэкенд формирует ответ и отправляет его в сеть. Маршрутизатор вычисляет хеш для обратного пакета – но src и dst поменялись местами, поэтому хеш может получиться другим.
4. Ответный пакет уходит на LB-B, у которого нет информации об этой сессии, и пакет отбрасывается. Соединение разрывается непредсказуемо.

Мониторинг и проверка

После включения опции и настройки маршрутизации на бэкендах выполните проверки.

На балансировщике

1. Убедитесь, что таблица nftables transparency существует и содержит правила:

   sudo nft list table ip transparency

   Должны быть видны цепочки output, prerouting и набор transparent_endpoints.

2. Проверьте, что набор transparent_endpoints не пуст (в нём перечислены IP и порты бэкендов, для которых включён прозрачный режим):

   sudo nft list set ip transparency transparent_endpoints

3. Проверьте наличие правила маршрутизации fwmark 1:

   ip rule show | grep "fwmark 0x1"

   Ожидаемый вывод: 999: from all fwmark 0x1 lookup 100

4. Проверьте таблицу маршрутизации 100:

   ip route show table 100

   Ожидаемый вывод: local default dev lo scope host

5. При наличии активных соединений проверьте, что они помечены (mark=1):

   sudo conntrack -L -m 1 -p tcp 2>/dev/null | head

На бэкенде

• Проверьте логи доступа приложения (например, access.log NGINX): в них должен отображаться реальный IP клиента.
• Если приложение не логирует IP, используйте tcpdump:

  sudo tcpdump -i any -n 'tcp port <порт_бэкенда>' | head -5
  В выводе должны присутствовать пакеты с source IP реального клиента.

Отключение IP Transparency

Чтобы выключить прозрачный режим:

1. Откройте конфигурацию балансировки в кластере.
2. На вкладке Сервисы в блоке Исходящий трафик выберите другой режим трансляции адресов (например, «Автоматически» или «SNAT группы»).
3. Сохраните изменения.

Система удалит из набора transparent_endpoints в nftables соответствующие пары (IP бэкенда, порт). Однако сама таблица transparency, правила маршрутизации (ip rule fwmark 1) и таблица 100 останутся на агентах – они создаются при запуске агента и существуют постоянно. Это не влияет на работу других сервисов.

Параметры прозрачного трафика

Агент создаёт таблицу nftables, правило ip rule и маршрут в отдельной таблице маршрутизации при старте — до того, как прозрачный режим включён в конфигурации балансировки. Значения по умолчанию рассчитаны на хост, где эти механизмы больше никто не использует.

Если на хосте уже есть свои правила с меткой fwmark 1 или своя таблица маршрутизации 100, задайте другие значения в файле конфигурации агента /etc/5a/agent.yml, см. Файл конфигурации агента.

• net.transparency.table-name — имя таблицы nftables, по умолчанию transparency. Должно отличаться от имён таблиц, созданных другими компонентами.
• net.transparency.mark — метка fwmark, которой помечается возвращаемый трафик, по умолчанию 1. Значение 0 недопустимо.
• net.transparency.routing-table — номер таблицы маршрутизации, по умолчанию 100. Нельзя использовать номера 0, 253, 254 и 255.
• net.transparency.rule-priority — приоритет правила ip rule, по умолчанию 999. Допустимый диапазон — от 1 до 32765.

net:
  transparency:
    table-name: my-transparency
    mark: 2
    routing-table: 150
    rule-priority: 950

После перезапуска службы повторите проверки из раздела Мониторинг и проверка. В выводе ip rule show должны быть указаны новая метка и новый приоритет, а в выводе ip route show table <номер таблицы> — local default dev lo scope host. Название таблицы nftables в командах проверки замените на заданное вами.

Ограничения и рекомендации

• Требование к бэкендам – каждый бэкенд обязательно должен иметь default gateway, указывающий на балансировщик или VIP кластера. Без этого ответные пакеты не вернутся, и соединение разорвётся. Эта настройка выполняется администратором вручную.
• Альтернативные методы передачи IP – Для протокола HTTP/HTTPS существуют заголовок X-Forwarded-For. Для TCP (без HTTP) – PROXY protocol. IP Transparency применяется для случаев, когда эти методы недоступны или требуется полная прозрачность на уровне IP.
• Совместимость с Proxy Protocol – Не рекомендуется включать IP Transparency и PROXY protocol одновременно на одном сервисе.
• Отказоустойчивость – IP Transparency стабильно работает с VRRP (Active-Passive). Совместное использование с BGP (Active-Active) приводит к асимметричному роутингу и разрывам соединений.
• Сетевые требования – Бэкенды должны находиться в отдельной L2-сети/VLAN от клиентов, а балансировщик должен иметь интерфейс в этой сети. Бэкенды не должны иметь прямого L3-пути к клиентам в обход балансировщика.
• Производительность – Подмена source IP и обработка возвратных пакетов добавляет небольшую дополнительную нагрузку. При очень высоких нагрузках рекомендуется тестирование.
• Облачные среды – В облачных платформах перед включением IP Transparency проконсультируйтесь со службой поддержки, так как могут быть ограничения на приём «чужих» IP и на маршрутизацию.

Краткий чек-лист для администратора

Перед включением IP Transparency

• На всех бэкендах настроен default gateway - IP балансировщика или VIP кластера.
• На балансировщике для интерфейса в бэкенд-сети установлен rp_filter=2 (loose mode).
• Бэкенды находятся в отдельной сети/VLAN, не имеют прямого маршрута к клиентам.
• При использовании VRRP бэкенды используют в качестве шлюза тот же VIP, что и клиенты.
• При использовании BGP (не рекомендуется) – администратор сам отвечает за настройку симметричного хеширования на роутерах.

После включения

• На балансировщике: nft list table ip transparency показывает правила.
• На балансировщике: conntrack -L -m 1 показывает помеченные соединения (при активной нагрузке).
• На бэкенде: логи или tcpdump показывают реальный IP клиента.