Настройка 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) для апстрим-серверов.

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

# 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;
    }
}

В этом примере:

  • Настроен простой виртуальный HTTP-сервер, распределяющий трафик между группой апстрим-серверов.

  • Исходный адрес для трафика, направляемого на апстрим-серверы, подменяется с помощью параметра transparent в директиве proxy_bind. Чаще всего в качестве исходного адреса указывается адрес удаленного клиента.

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

Настройка маршрутизации будет выполняться на основе политик PBR (Policy-Based Routing).

  1. Подключитесь к интерфейсу командной строки на порту 2222.

  2. Добавьте маршрутизацию всего трафика в локальный интерфейс lo в таблице 100:

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

  4. Проверьте, что весь трафик обрабатывается в таблице 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-адреса.