Настройка Transparent Proxy для TCP- и UDP-трафика#
Angie ADC работает как обратный прокси для TCP- и UDP-трафика. Апстрим-серверы видят, что весь трафик исходит с IP-адреса самого прокси Angie ADC.
Если апстрим-серверу необходимо определить настоящий IP-адрес клиента (например, для аутентификации или ведения логов), то для TCP- и UDP-трафика доступны следующие два метода:
IP Transparency — апстрим-серверы видят соединение как исходящее от реального клиента.
Direct Server Return (DSR) — дополнительно позволяет отправлять ответы от апстрим-серверов напрямую клиентам, минуя промежуточный балансировщик. Метод применим только для UDP-трафика и может быть реализован через NAT (Network Address Translation) на исходном сервере.
IP Transparency#
При использовании IP Transparency апстрим-серверы будут видеть настоящий IP-адрес клиента,
с которого приходят пакеты. IP Transparency может использоваться как с TCP-, так и с UDP-протоколами. Балансировщик и апстрим-серверы должны находится в одной подсети. Балансировщик должен быть маршрутизатором по умолчанию (default gateway) для апстрим-серверов. В этом примере: Настроен простой виртуальный HTTP-сервер, распределяющий трафик между группой апстрим-серверов. Исходный адрес для трафика, направляемого на апстрим-серверы,
подменяется с помощью параметра Маршрутизация настраивается на основе политик PBR (Policy-Based Routing): Подключитесь к интерфейсу командной строки на порту 2222. Добавьте маршрутизацию всего трафика в локальный интерфейс Добавьте правила: весь трафик с апстрим-серверов
необходимо обрабатывать с помощью таблицы маршрутизации Вместо добавления отдельных серверов можно добавить правило для подсети, если это необходимо
(например, Проверьте, что весь трафик обрабатывается в таблице Предусловия#
Пример настройки балансировщика#
# in the 'http' context
upstream http_upstreams {
server server1;
server server2;
}
server {
listen 80;
location / {
proxy_bind $remote_addr transparent;
proxy_pass http://http_upstreams;
}
}
transparent в директиве proxy_bind.
Чаще всего в качестве исходного адреса указывается адрес удаленного клиента.Настройка маршрутизации#
lo в таблице 100:ip route add local 0.0.0.0/0 dev lo table 100
100:ip rule add from server1 table 100
ip rule add from server2 table 100
ip rule add from 10.21.20.0/24 table 100).100
и что есть только один маршрут — весь трафик уходит в локальный интерфейс lo:# ip rule
0: from all lookup local
32764: from server1 lookup 100
32765: from server2 lookup 100
32766: from all lookup main
32767: from all lookup default
# ip route show table 100
local default dev lo scope host
Direct Server Return (DSR)#
При использовании Direct Server Return (DSR) апстрим-серверы будут видеть настоящий IP-адрес клиента, с которого приходят пакеты, и будут отправлять ответ непосредственно удаленному клиенту (т. е. пакеты с ответом полностью обходят балансировщик нагрузки). Применяется для UDP-трафика.
DSR может дать небольшой прирост производительности:
Позволяет не удерживать открытыми UDP-сокеты в ожидании пакета ответа (повышает масштабируемость).
Пакеты с ответами могут полностью обходить L7-обработку (снижает задержку).
Также есть ограничения:
Балансировщик нагрузки не видит пакетов с ответами, поэтому не может определить, отвечает ли апстрим-сервер или вышел из строя.
Балансировщик не может анализировать запрос глубже первого пакета, чтобы выбрать апстрим-сервер, поэтому его возможности по принятию решений о балансировке (например, маршрутизация на основе содержимого) сильно ограничены.
Балансировщик не может участвовать в процессах согласования или обработке состояний, таких как SSL/TLS.
Такие функции, как кэширование и логирование, недоступны при использовании DSR.
Кроме того при использовании DSR необходимо:
переписывать исходный адрес ответа, чтобы он соответствовал публичному адресу балансировщика нагрузки;
настроить активные проверки для апстрим-серверов.
Предусловия#
Балансировщик и апстрим-серверы должны находится в одной подсети.
Балансировщик должен быть маршрутизатором по умолчанию (default gateway) для апстрим-серверов.
Пример настройки балансировщика#
# 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 172.16.0.11:53;
server 172.16.0.12:53;
server 172.16.0.13:53;
server 172.16.0.14:53;
}
В этом примере:
Создан кластер из четырех DNS-серверов с балансировкой нагрузки. Каждый из DNS-серверов должен возвращать разные IP-адреса при запросах
www.example.com.Настроена простая конфигурация обратного прокси, которая распределяет нагрузку между этими DNS-серверами.
Параметр
transparentв директивеproxy_bindпозволяет апстрим-серверу видеть исходный IP-адрес и порт (переменные$remote_addrи$remote_port).Балансировщик не ожидает ответ от апстрим-серверов (директива
proxy_responses=0). Ответ будет отправлен клиенту напрямую.
Переписывание IP-адреса и порта при ответе#
Апстрим-сервер генерирует ответные пакеты, в которых в качестве исходного адреса используется его локальный IP-адрес. Этот исходный адрес необходимо переписать на IP-адрес и порт балансировщика нагрузки, к которому изначально подключался клиент. Существует два метода:
Router NAT – переписывание исходящих пакетов на промежуточном маршрутизаторе.
Важно
Этот метод пока не поддерживается в Angie ADC.
Origin NAT – переписывание исходящих пакетов при их отправке с каждого апстрим-DNS-сервера.
Этот вариант применим, если у вас есть возможность настраивать сеть на апстрим-серверах, особенно если они напрямую подключены к интернету. Вы можете настроить stateless NAT-переписывание на каждом апстрим-сервере. Пример конфигурации см. ниже; ее необходимо применить на каждом апстрим-сервере.
Пример:
# tc qdisc add dev eth0 root handle 10: htb # tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.11 match ip sport 53 action nat egress 172.16.0.11 192.168.99.10
Убедитесь, что на каждом апстрим-сервере выбран корректный интерфейс и корректные IP-адреса.
Содержание