Настройка Transparent Proxy для TCP- и UDP-трафика#

Angie ADC работает как обратный прокси для TCP- и UDP-трафика. Апстрим-серверы видят, что весь трафик приходит с IP-адреса самого прокси Angie ADC:

Рис. 1: красным цветом обозначен поток трафика от клиента к сервису, синим — обратный трафик.

Для определения и передачи настоящего IP-адреса клиента апстрим-серверу доступны следующие два метода:

IP Transparency — апстрим-серверы видят соединение как исходящее от реального клиента (для TCP- и UDP-трафика).
Direct Server Return (DSR) — дополнительно позволяет отправлять ответы от апстрим-серверов напрямую клиентам, минуя промежуточный балансировщик (только для UDP-трафика). Метод может быть реализован через NAT.

IP Transparency#

При использовании IP Transparency апстрим-серверы будут видеть настоящий IP-адрес клиента, с которого приходят пакеты. IP Transparency может использоваться как с TCP-, так и с UDP-протоколами.

Рис. 2: пример сети, в которой на системе балансировки Angie ADC включена опция IP Transparency.

Предусловия#

Должно выполняться одно из следующих условий:

Балансировщик и апстрим-серверы находятся в одной подсети, балансировщик является маршрутизатором по умолчанию (default gateway) для апстрим-серверов.
Балансировщик находится на пути передачи трафика между клиентом и апстрим-серверами (трафик проходит через балансировщик в обоих направлениях).

Пример настройки балансировщика#

# 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. Чаще всего в качестве исходного адреса указывается адрес удаленного клиента.

Настройка маршрутизации#

При использовании IP Transparency трафик должен проходить через Angie ADC и обрабатываться им. Для этого необходимо настроить корректную маршрутизацию.

Рис. 3: движение трафика через Angie ADC с настроенным IP Transparency.

Маршрутизация настраивается на основе политик PBR (Policy-Based Routing):

Подключитесь к интерфейсу командной строки на порту 2222.
Добавьте маршрутизацию всего трафика в локальный интерфейс lo в таблице 100:
```
ip route add local 0.0.0.0/0 dev lo table 100
```
Добавьте правила: весь трафик с апстрим-серверов необходимо обрабатывать с помощью таблицы маршрутизации 100:
```
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).
Проверьте, что весь трафик обрабатывается в таблице 100 и что есть только один маршрут — весь трафик уходит в локальный интерфейс lo:

# 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)#

Важно

Применение DSR возможно только для UDP-трафика.

При использовании Direct Server Return (DSR) апстрим-серверы будут видеть настоящий IP-адрес клиента, с которого приходят пакеты, и будут отправлять ответ непосредственно удаленному клиенту (т. е. пакеты с ответом полностью обходят балансировщик нагрузки). DSR может дать небольшой прирост производительности:

Позволяет не удерживать открытыми UDP-сокеты в ожидании пакета ответа (повышает масштабируемость).
Пакеты с ответами могут полностью обходить L7-обработку (снижает задержку).

Рис. 4: движение трафика через Angie ADC с DSR.

Ограничения при использовании DSR:

Балансировщик нагрузки не видит пакетов с ответами, поэтому не может определить, отвечает ли апстрим-сервер или вышел из строя.
Балансировщик не может анализировать запрос глубже первого пакета, чтобы выбрать апстрим-сервер, поэтому его возможности по принятию решений о балансировке (например, маршрутизация на основе содержимого) ограничены.
Балансировщик не может участвовать в процессах согласования или обработке состояний, таких как SSL/TLS.
Такие функции, как кэширование и логирование, недоступны при использовании DSR.

Кроме того при использовании DSR необходимо:

переписывать исходный адрес ответа, чтобы он соответствовал публичному адресу балансировщика нагрузки;
настроить активные проверки для апстрим-серверов.

Пример настройки балансировщика#

# 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-переписывание:

Например:

# 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, выполните:

# tc filter show dev eth0

Origin NAT#

Вариант с переписыванием исходящих пакетов при их отправке с каждого апстрим-DNS-сервера применим, если у вас есть возможность настраивать сеть на апстрим-серверах, особенно если они напрямую подключены к интернету.

Рис. 6: движение трафика с Origin NAT

Необходимо настроить 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 192.168.0.2 match ip sport 53 action nat egress 192.168.0.2 198.51.100.1

Такую конфигурацию необходимо применить на каждом апстрим-сервере, убедившись, что выбран корректный интерфейс и корректные IP-адреса.