Transparent reverse HAProxy в 3-Legs схеме
-
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.
-
Я, честно говоря, не знаю как там haproxy встраивается в поток, но попробуйте обратиться из LAN к публичному адресу веб-сервера и посмотрите, что будет. По идее, запрос должен попасть в прозрачный haproxy и далее по назначению, т. к. слушаюший socket привязывается к IP, а не к интерфейсу. pfSense пофиг к какому из его собственных IP вы обратились - все попадет в local process, т. е. в haproxy.
Если не поможет, можно (если можно) попробовать повесить листенер на loopback и делать port forward на 127.0.0.1 как с WAN, так и с LAN
-
…но попробуйте обратиться из LAN к публичному адресу веб-сервера и посмотрите, что будет. По идее, запрос должен попасть в прозрачный haproxy и далее по назначению, т. к. слушаюший socket привязывается к IP, а не к интерфейсу. pfSense пофиг к какому из его собственных IP вы обратились - все попадет в local process, т. е. в haproxy.
Если не поможет, можно (если можно) попробовать повесить листенер на loopback и делать port forward на 127.0.0.1 как с WAN, так и с LAN
Навскидку обращение из LAN на WAN-адрес не проходит - браузер шлет запрос на внешний адрес, а ответ получает с внутреннего.
Насчет заворота на loopback с листенером на нем - попробую позже, отпишусь. По идее должно сработать. Но гемора с настройками будет…
-
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 ;)
-
Да, с транспарент могут быть проблемы, о чем и предупреждает 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/
-
Если не поможет, можно (если можно) попробовать повесить листенер на loopback и делать port forward на 127.0.0.1 как с WAN, так и с LAN
Таки работает! Достаточно с LAN занатить на loopback, и к листенеру, сидящему на внешних адресах, добавить слушание на loopback-е (чтобы не плодить миллион лишних правил NAT).
Спасибо за идею!
-
Не очень элегантное решение конечно. Больше удивляет почему обращение к внешнему адресу из LAN не работает. Хотя… если, как вы говорите, ответы приходят с адресом источника из DMZ, то в качестве альтернативы можно было сделать Outbound NAT на LAN интерфейсе, который бы транслировал адреса серверов в DMZ в адрес WAN.
-
Не очень элегантное решение конечно. Больше удивляет почему обращение к внешнему адресу из LAN не работает. Хотя… если, как вы говорите, ответы приходят с адресом источника из DMZ, то в качестве альтернативы можно было сделать Outbound NAT на LAN интерфейсе, который бы транслировал адреса серверов в DMZ в адрес WAN.
Почему-то мне кажется, что это будет более громоздким решением.
-
Так кажется потому, что у вас уже все настроено по-своему и не охота что-то менять. А для человека, настраивающего с нуля, сплошные плюсы:
- не нужен split horizon DNS - доступ к DMZ осуществляется единообразно как из WAN так и из LAN.
- не нужен дополнительный listener на loopback - меньше настроек haproxy
- не нужен Port Forward из LAN на loopbaсk, хотя нужен Outbound NAN на LAN - ну, будем считать 1:1
-
Так кажется потому, что у вас уже все настроено по-своему и не охота что-то менять. А для человека, настраивающего с нуля, сплошные плюсы:
- не нужен split horizon DNS - доступ к DMZ осуществляется единообразно как из WAN так и из LAN.
- не нужен дополнительный listener на loopback - меньше настроек haproxy
- не нужен Port Forward из LAN на loopbaсk, хотя нужен Outbound NAN на LAN - ну, будем считать 1:1
А вы проверяли, само-то решение работает? Я не проверял. ;)