Transparent reverse HAProxy в 3-Legs схеме

gmn

На целевой сервер TCP-соединение приходит от адреса клиента, а не реверсного прокси.

Как мне кажется, вы многого хотите :)
И чтобы соединение было прямое, не проксированное, и чтобы хосты назначения были разные …
Тогда только прокси, который по имени будет различать к какому бакэенду направить запрос.
Средствами pf вы не сделаете проброс порта по условию ... Т.е. если имя сайта такое-то - туда иди. Такое - сюда ходи ... :)
Это только (чем я делал) - haproxy или nginx.
И логи смотреть на фронтэнде - здесь будут честные IP источников запроса.
На бакэендах будет IP прокси. Будь то или squid, или haproxy, или nginx, или ...
Выход из ситуации - это обработка заголовка "x-forwarded-for" или "x-real-ip" (какой добавите на фронтэенде) на бакэнде.

rubic

@IB:

HAProxy пропускает через себя только трафик из Интернета, то он не знает, что делать с локальным трафиком, и дропит его.

К какому адресу обращаются клиенты из LAN идущие на веб-сервер? В смысле к локальному или публичному?

IB

@rubic:

@IB:

HAProxy пропускает через себя только трафик из Интернета, то он не знает, что делать с локальным трафиком, и дропит его.

К какому адресу обращаются клиенты из LAN идущие на веб-сервер? В смысле к локальному или публичному?

К локальному, DMZ-шному.

PiBa

Sorry i dont speak Russian, but do maintain haproxy package on pfSense..

Trying to read / translate this thread im thinking some people are having a slight misunderstanding of the underlying problem presented. If you want to be able to proxy a ssh connection (which i think is one of the desired outcome's?) its not possible to insert a x-forwarded-for header. But haproxy can proxy those connections while keeping the client-ip available to the backend, i think you found that option "Transparent ClientIP" in the backend configuration right?

The desired scenario would be like described here: http://blog.haproxy.com/2011/08/03/layer-7-load-balancing-transparent-proxy-mode/ where the clientip is also used for the connection to the webserver however because pf on freebsd currently does not yet support 'diver-reply' even though it is documented, some trickery is done with ipfw is done to divert reply packets from the webserver back to the haproxy client socket with a non-local ip address.

However this ipfw rule causes trouble for direct clien to webserver traffic .. Im not aware of any other possibility to implement this currently besides waiting for the divert-reply to get implemented into FreeBSD.. ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188511 ) If someone knows a better way im open to suggestions ;) .

For http based traffic inserting the x-forwarded-for header is a good option though..

If i'm totally missing the point, sorry for this non-russian post.

rubic

Я, честно говоря, не знаю как там haproxy встраивается в поток, но попробуйте обратиться из LAN к публичному адресу веб-сервера и посмотрите, что будет. По идее, запрос должен попасть в прозрачный haproxy и далее по назначению, т. к. слушаюший socket привязывается к IP, а не к интерфейсу. pfSense пофиг к какому из его собственных IP вы обратились - все попадет в local process, т. е. в haproxy.

Если не поможет, можно (если можно) попробовать повесить листенер на loopback и делать port forward на 127.0.0.1 как с WAN, так и с LAN

IB

@rubic:

…но попробуйте обратиться из LAN к публичному адресу веб-сервера и посмотрите, что будет. По идее, запрос должен попасть в прозрачный haproxy и далее по назначению, т. к. слушаюший socket привязывается к IP, а не к интерфейсу. pfSense пофиг к какому из его собственных IP вы обратились - все попадет в local process, т. е. в haproxy.

Если не поможет, можно (если можно) попробовать повесить листенер на loopback и делать port forward на 127.0.0.1 как с WAN, так и с LAN

Навскидку обращение из LAN на WAN-адрес не проходит - браузер шлет запрос на внешний адрес, а ответ получает с внутреннего.

Насчет заворота на loopback с листенером на нем - попробую позже, отпишусь. По идее должно сработать. Но гемора с настройками будет…

IB

@PiBa:

Sorry i dont speak Russian, but do maintain haproxy package on pfSense..

I repeat my question here: https://forum.pfsense.org/index.php?topic=98017.0 Sorry my English ;)

gmn

Да, с транспарент могут быть проблемы, о чем и предупреждает pfsense:
"WARNING Activating this option will load rules in IPFW and might interfere with CaptivePortal and possibly other services due to the way server return traffic must be 'captured' with a automatically created fwd rule. This also breaks directly accessing the (web)server on the ports configured above. Also a automatic sloppy pf rule is made to allow HAProxy to server traffic."

Прочитал ваш вопрос на английском.
"Servers S1 and S2 must see real client IP" - какие там web-сервера используются?
Это я к тому, что haproxy умеет добавлять заголовок "X-Forwarded-For", а Apache и nginx (да и IIS тоже, и другие наверняка) умеют его обрабатывать.
Вот ссылка на документацию nginx - http://nginx.org/ru/docs/http/ngx_http_realip_module.html
"Модуль ngx_http_realip_module позволяет менять адрес клиента на переданный в указанном поле заголовка."
Т.е. и в логе, и в переменной _SERVER["REMOTE_ADDR"] будет адрес источника, а не прокси.

https://rtcamp.com/tutorials/nginx/forwarding-visitors-real-ip/

IB

@rubic:

Если не поможет, можно (если можно) попробовать повесить листенер на loopback и делать port forward на 127.0.0.1 как с WAN, так и с LAN

Таки работает! Достаточно с LAN занатить на loopback, и к листенеру, сидящему на внешних адресах, добавить слушание на loopback-е (чтобы не плодить миллион лишних правил NAT).

Спасибо за идею!

rubic

Не очень элегантное решение конечно. Больше удивляет почему обращение к внешнему адресу из LAN не работает. Хотя… если, как вы говорите, ответы приходят с адресом источника из DMZ, то в качестве альтернативы можно было сделать Outbound NAT на LAN интерфейсе, который бы транслировал адреса серверов в DMZ в адрес WAN.

IB

@rubic:

Не очень элегантное решение конечно. Больше удивляет почему обращение к внешнему адресу из LAN не работает. Хотя… если, как вы говорите, ответы приходят с адресом источника из DMZ, то в качестве альтернативы можно было сделать Outbound NAT на LAN интерфейсе, который бы транслировал адреса серверов в DMZ в адрес WAN.

Почему-то мне кажется, что это будет более громоздким решением.

rubic

Так кажется потому, что у вас уже все настроено по-своему и не охота что-то менять. А для человека, настраивающего с нуля, сплошные плюсы:

не нужен split horizon DNS - доступ к DMZ осуществляется единообразно как из WAN так и из LAN.
не нужен дополнительный listener на loopback - меньше настроек haproxy
не нужен Port Forward из LAN на loopbaсk, хотя нужен Outbound NAN на LAN - ну, будем считать 1:1

IB

@rubic:

Так кажется потому, что у вас уже все настроено по-своему и не охота что-то менять. А для человека, настраивающего с нуля, сплошные плюсы:

не нужен split horizon DNS - доступ к DMZ осуществляется единообразно как из WAN так и из LAN.

не нужен дополнительный listener на loopback - меньше настроек haproxy

не нужен Port Forward из LAN на loopbaсk, хотя нужен Outbound NAN на LAN - ну, будем считать 1:1

А вы проверяли, само-то решение работает? Я не проверял. ;)