Я, наверное, потерялся в массе документации по этому поводу, но я пытаюсь настроить свой процесс HAProxy для отправки заголовка протокола PROXY, как описано в http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt. Это связано с тем, что мне нужно написать поддержку протокола PROXY на сервере C ++ (для того, чтобы он имел доступ к клиентскому IP / порту), и я хочу проверить, правильно ли работает мой код с анализом заголовка PROXY.
Вот мой минимальный файл конфигурации:
global
maxconn 4096
defaults
log global
mode http
retries 3
option redispatch
maxconn 2000
timeout connect 5000
timeout client 50000
timeout server 50000
frontend TestServerTest
bind 10.6.186.24:54781
mode tcp
default_backend TestServernodes
backend TestServernodes
mode tcp
# Note there is no 'check' after the below line unlike the others as we don't want to send the
# healthcheck ("OPTIONS / HTTP/1.0"...) string to the TestServer as it doesn't understand it!
server TestServer01 10.6.186.24:48080
Я обнаружил, что когда я запускаю HAProxy и подключаюсь к 54781, первые данные, которые получает TestServer на 48080, - это данные, которые отправляет мой клиент; это не шапка PROXY, описанная по размещенной мною ссылке.
Может ли кто-нибудь сказать мне, что мне не хватает в моей конфигурации, что препятствует отправке заголовка PROXY на мой внутренний сервер?
После публикации в списке рассылки HAProxy (haproxy@formilux.org) я получил ответ, который мне нужно добавить либо send-proxy или send-proxy-v2 на мой сервер server определения.
В моем обновленном файле конфигурации есть строка:
сервер TestServer01 10.6.186.24:48080 send-proxy
... который отправляет версию 1 протокола PROXY.
Чтобы отправить версию 2, измените это на
сервер TestServer01 10.6.186.24:48080 отправить прокси-v2
Согласно документу, на который вы ссылаетесь, полная конфигурация требует настройки пары компонентов.
Если у вас есть экземпляр haproxy перед вашими реальными бэкэндами, вам может потребоваться применить accept-proxy:
прослушивающие сокеты принимают протокол, когда параметр accept-proxy передается ключевому слову bind. Соединения, принятые на таких слушателях, будут вести себя так же, как если бы источник действительно был тем, который объявлен в протоколе. Это верно для ведения журнала, списков контроля доступа, фильтрации содержимого, прозрачного проксирования и т. Д.
Это часть, которую вы выяснили в своем ответе, бэкэнд-серверы необходимо настроить с помощью send-proxy:
протокол может использоваться для подключения к серверам, если в строке «server» присутствует настройка «send-proxy». Он включается для каждого сервера, поэтому его можно включить только для удаленных серверов, и при этом локальные будут вести себя иначе. Если входящее соединение было принято с помощью «accept-proxy», то ретранслируемая информация является той, которая объявляется в строке PROXY этого соединения.
И это все, что я смог найти на v2:
Haproxy 1.5 также реализует версию 2 протокола PROXY в качестве отправителя. Кроме того, был добавлен TLV с ограниченной дополнительной информацией SSL.