Re: Transparent Proxy
Jason, No that option is not relevant for TPROXY (client source IP transparency) Its an old blog but take a look at: http://blog.loadbalancer.org/configure-haproxy-with-tproxy-kernel-for-full-transparent-proxy/ Ignore the kernel re-compile stuff, as its all pretty standard in modern kernels. But it should show you how to construct the haproxy.cfg file. On 23 September 2011 22:53, Jason J. W. Williams wrote: > Hello, > > My understanding has been that HAProxy can be set up in conjunction > with TPROXY support in the Linux kernel so that the backend servers > see the original client's source IP address on incoming packets? > > So is the "option transparent" > (http://code.google.com/p/haproxy-docs/wiki/transparent) not related > to that type of transparent proxying or am I mistaken and there's no > way to make HAProxy preserve the original client IP on the way to the > backend servers? > > Thank you in advance. > > -J > > -- Regards, Malcolm Turnbull. Loadbalancer.org Ltd. Phone: +44 (0)870 443 8779 http://www.loadbalancer.org/
Re: Transparent Proxy
On Fri, Sep 23, 2011 at 11:53 PM, Jason J. W. Williams wrote: > Hello, > > My understanding has been that HAProxy can be set up in conjunction > with TPROXY support in the Linux kernel so that the backend servers > see the original client's source IP address on incoming packets? > > So is the "option transparent" > (http://code.google.com/p/haproxy-docs/wiki/transparent) not related > to that type of transparent proxying or am I mistaken and there's no > way to make HAProxy preserve the original client IP on the way to the > backend servers? > > Thank you in advance. > > -J > > Hi, You have to patch your kernel with TProxy and then to use the source keyword: http://code.google.com/p/haproxy-docs/wiki/source Note that the default gateway of your servers must be the HAProxy box in that kind of architecture. cheers
Transparent Proxy
Hello, My understanding has been that HAProxy can be set up in conjunction with TPROXY support in the Linux kernel so that the backend servers see the original client's source IP address on incoming packets? So is the "option transparent" (http://code.google.com/p/haproxy-docs/wiki/transparent) not related to that type of transparent proxying or am I mistaken and there's no way to make HAProxy preserve the original client IP on the way to the backend servers? Thank you in advance. -J
Re: HAProxy 1.5-dev7 attempting to connect to real server port of twice virtual server port
Hello Willy. On 23 September 2011 09:35, Willy Tarreau wrote: > thanks to your diags and detailed reports, I found the bug and I > have the fix. Thanks - that's working for us. Nick. -- Nick Chalk. Loadbalancer.org Ltd. Phone: +44 (0)870 443 8779 http://www.loadbalancer.org/
Need help about reqrep (urgent)
Hey there, I have trouble with direct “reqrep” what I want is : My main web site is : caipiao.aaa.com My second web site is: www.bbb.com My goal is redirect URL from caipiao.aaa.com/ kaijiang ->www.bbb.com/result_aaa , but the URL in the browse still need to display caipiao.aaa.com/kaijiang what I did is: Frontend: acl acl_dom_caipiao.aaa.com hdr_dom(host) caipiao.aaa.com acl acl_url_kaijiang path_beg -i /kaijiang use_backend cs_aaa_caipiaos_1 if acl_dom_caipiao.aaa.com acl_url_kaijiang backend: backend cs_aaa_caipiaos_1 reqrep ^([^\ ]*)\ /kaijiang(/.*) \1\ /result_aaa\2 option httpchk GET / HTTP/1.1\r\nHost:\ www.bbb.com server srv_aaa_caipiaos_1_01 www.bbb.com:80 check when I access caipiao.aaa.com/kaijiang, I get a 404 error, looks like reqrep did not working~ but if make a little change as below: acl acl_url_result path_beg -i/result_aaa use_backend cs_aaa_caipiaos_1 if acl_dom_caipiao.aaa.com acl_url_result then I can access caipiao.aaa.com/result_aaa directly, So there should be a problem on reqrep Could you help to analyze the root cause of this ?
Re: HAProxy 1.5-dev7 attempting to connect to real server port of twice virtual server port
Hi Nick, thanks to your diags and detailed reports, I found the bug and I have the fix. We were using the port from the wrong side's address when mapping was used. This explains why the resulting port was twice the incoming one. Since we moved to full-ipv6, we don't need the addr.s/addr.c tricks, we have sockaddr_storage everywhere, so I'll remove that and it will be both cleaner and less error-prone. I'm attaching the patch that I have already pushed upstream. Cheers, Willy commit dd164d0240b0fc1030044d7b1bfad93401959eea Author: Willy Tarreau Date: Fri Sep 23 10:27:12 2011 +0200 BUG/MINOR: don't use a wrong port when connecting to a server with mapped ports Nick Chalk reported that a connection to a server which has no port specified used twice the port number. The reason is that the port number was taken from the wrong part of the address, the client's destination address was used as the base port instead of the server's configured address. Thanks to Nick for his helpful diagnostic. diff --git a/src/backend.c b/src/backend.c index d850ebf..0fa28f0 100644 --- a/src/backend.c +++ b/src/backend.c @@ -703,7 +703,7 @@ int assign_server_address(struct session *s) base_port = get_host_port(&s->req->prod->addr.c.to); /* Second, assign the outgoing connection's port */ - base_port += get_host_port(&s->req->prod->addr.s.to); + base_port += get_host_port(&s->req->cons->addr.s.to); set_host_port(&s->req->cons->addr.s.to, base_port); } }