# Настройка Transparent Proxy для TCP- и UDP-трафика Angie ADC работает как обратный прокси для TCP- и UDP-трафика. Апстрим-серверы видят, что весь трафик приходит с IP-адреса самого прокси Angie ADC:  Рис. 1: красным цветом обозначен поток трафика от клиента к сервису, синим — обратный трафик. Для определения и передачи настоящего IP-адреса клиента апстрим-серверу доступны следующие два метода: - [IP Transparency](#adc-ip-transparency) — апстрим-серверы видят соединение как исходящее от реального клиента (для TCP- и UDP-трафика). - [Direct Server Return (DSR)](#adc-dsr) — дополнительно позволяет отправлять ответы от апстрим-серверов напрямую клиентам, минуя промежуточный балансировщик (только для UDP-трафика). Метод может быть реализован через NAT. ## IP Transparency При использовании IP Transparency апстрим-серверы будут видеть настоящий IP-адрес клиента, с которого приходят пакеты. IP Transparency может использоваться как с TCP-, так и с UDP-протоколами.  Рис. 2: пример сети, в которой на системе балансировки Angie ADC включена опция IP Transparency. ### Предусловия Должно выполняться одно из следующих условий: - Балансировщик и апстрим-серверы находятся в одной подсети, балансировщик является маршрутизатором по умолчанию (default gateway) для апстрим-серверов. - Балансировщик находится на пути передачи трафика между клиентом и апстрим-серверами (трафик проходит через балансировщик в обоих направлениях). ### Пример настройки балансировщика ```none # in the 'http' context upstream http_upstreams { server 192.168.0.2; server 192.168.0.3; server 192.168.0.4; } server { listen 80; location / { proxy_bind $remote_addr transparent; proxy_pass http://http_upstreams; } } ``` В этом примере: - Настроен простой виртуальный HTTP-сервер, распределяющий трафик между группой апстрим-серверов. - Исходный адрес для трафика, направляемого на апстрим-серверы, подменяется с помощью параметра `transparent` в директиве [proxy_bind](https://angie.software//adc/docs/configuration_lb/reference/http/http_proxy.md#adc-proxy-bind). Чаще всего в качестве исходного адреса указывается адрес удаленного клиента. ### Настройка маршрутизации При использовании IP Transparency трафик должен проходить через Angie ADC и обрабатываться им. Для этого необходимо настроить корректную маршрутизацию.  Рис. 3: движение трафика через Angie ADC с настроенным IP Transparency. Маршрутизация настраивается на основе политик PBR (Policy-Based Routing): 1. Подключитесь к [интерфейсу командной строки](https://angie.software//adc/docs/management/cli-commands.md#adc-starting-cli) на порту 2222. 2. Добавьте маршрутизацию всего трафика в локальный интерфейс `lo` в таблице `100`: ```none ip route add local 0.0.0.0/0 dev lo table 100 ``` 3. Добавьте правила: весь трафик с апстрим-серверов необходимо обрабатывать с помощью таблицы маршрутизации `100`: ```none ip rule add from 192.168.0.2 table 100 ip rule add from 192.168.0.3 table 100 ip rule add from 192.168.0.4 table 100 ``` Вместо добавления отдельных серверов можно добавить правило для подсети, если это необходимо (например, `ip rule add from 10.21.20.0/24 table 100`). 4. Проверьте, что весь трафик обрабатывается в таблице `100` и что есть только один маршрут — весь трафик уходит в локальный интерфейс `lo`: ```none # ip rule 0: from all lookup local 32764: from 192.168.0.2 lookup 100 32765: from 192.168.0.3 lookup 100 32766: from 192.168.0.4 lookup 100 32767: from all lookup main 32768: from all lookup default # ip route show table 100 local default dev lo scope host ``` ## Direct Server Return (DSR) #### IMPORTANT Применение DSR возможно только для UDP-трафика. При использовании Direct Server Return (DSR) апстрим-серверы будут видеть настоящий IP-адрес клиента, с которого приходят пакеты, и будут отправлять ответ непосредственно удаленному клиенту (т. е. пакеты с ответом полностью обходят балансировщик нагрузки). DSR может дать небольшой прирост производительности: - Позволяет не удерживать открытыми UDP-сокеты в ожидании пакета ответа (повышает масштабируемость). - Пакеты с ответами могут полностью обходить L7-обработку (снижает задержку).  Рис. 4: движение трафика через Angie ADC с DSR. Ограничения при использовании DSR: - Балансировщик нагрузки не видит пакетов с ответами, поэтому не может определить, отвечает ли апстрим-сервер или вышел из строя. - Балансировщик не может анализировать запрос глубже первого пакета, чтобы выбрать апстрим-сервер, поэтому его возможности по принятию решений о балансировке (например, маршрутизация на основе содержимого) ограничены. - Балансировщик не может участвовать в процессах согласования или обработке состояний, таких как SSL/TLS. - Такие функции, как кэширование и логирование, недоступны при использовании DSR. Кроме того при использовании DSR необходимо: - переписывать исходный адрес ответа, чтобы он соответствовал публичному адресу балансировщика нагрузки; - настроить активные проверки для апстрим-серверов. ### Пример настройки балансировщика ```none # in the 'stream' context server { listen 53 udp; proxy_bind $remote_addr:$remote_port transparent; proxy_responses 0; #proxy_timeout 1s; } upstream dns_upstreams { server 192.168.0.2:53; server 192.168.0.3:53; server 192.168.0.4:53; } ``` В этом примере: - Создан кластер из трех DNS-серверов с балансировкой нагрузки. Каждый из DNS-серверов должен возвращать разные IP-адреса при запросах `www.example.com`. - Настроена простая конфигурация обратного прокси, которая распределяет нагрузку между этими DNS-серверами. - Параметр `transparent` в директиве `proxy_bind` позволяет апстрим-серверу видеть исходный IP-адрес и порт (переменные `$remote_addr` и `$remote_port`). - Балансировщик не ожидает ответ от апстрим-серверов (директива `proxy_responses=0`). Ответ будет отправлен клиенту напрямую. ### Переписывание IP-адреса и порта при ответе Апстрим-сервер генерирует ответные пакеты, в которых в качестве исходного адреса используется его локальный IP-адрес. Этот исходный адрес необходимо переписать на IP-адрес и порт балансировщика нагрузки, к которому изначально подключался клиент. Есть два способа для переписывания исходящих пакетов: - Router NAT – переписывание на промежуточном маршрутизаторе. - Origin NAT – переписывание при отправке пакетов с каждого апстрим-DNS-сервера. #### Router NAT Вы можете изменять (переписывать) исходящие пакеты на промежуточном маршрутизаторе, который является маршрутом по умолчанию для апстрим-серверов.  Рис. 5: движение трафика с Router NAT Для этого настройте на маршрутизаторе stateless NAT-переписывание: Например: ```none # tc qdisc add dev eth0 root handle 10: htb # tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 192.168.0.2 match ip sport 53 action nat egress 192.168.0.2 198.51.100.1 # tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 192.168.0.3 match ip sport 53 action nat egress 192.168.0.3 198.51.100.1 # tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 192.168.0.4 match ip sport 53 action nat egress 192.168.0.4 198.51.100.1 ``` Убедитесь, что вы указали корректный исходящий интерфейс (например, `eth0`) и правильные IP-адреса для каждого апстрим-сервера. В зависимости от конфигурации можно сократить количество команд `tc filter`, объединив их с помощью CIDR-масок для параметров `src` и `egress old`. Чтобы вывести текущую конфигурацию `tc filter`, выполните: ```none # tc filter show dev eth0 ``` #### Origin NAT Вариант с переписыванием исходящих пакетов при их отправке с каждого апстрим-DNS-сервера применим, если у вас есть возможность настраивать сеть на апстрим-серверах, особенно если они напрямую подключены к интернету.  Рис. 6: движение трафика с Origin NAT Необходимо настроить stateless NAT-переписывание на каждом апстрим-сервере. Пример: ```none # tc qdisc add dev eth0 root handle 10: htb # tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 192.168.0.2 match ip sport 53 action nat egress 192.168.0.2 198.51.100.1 ``` Такую конфигурацию необходимо применить на каждом апстрим-сервере, убедившись, что выбран корректный интерфейс и корректные IP-адреса.