Hi Anthony,
On Wed, Aug 06, 2008 at 12:26:34PM -0600, Caleb Anthony wrote:
> ip rule add fwmark 1 lookup 100
> ip route add local 0.0.0.0/0 dev lo table 100
> iptables -t mangle -N DIVERT
> iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
> iptables -t mangle -A DIVERT -j MARK --set-mark 1
> iptables -t mangle -A DIVERT -j ACCEPT
>
> Added:
> source 0.0.0.0 usesrc client
> to my haproxy.cfg
>
> Thats all that needs to be done on the HAProxy side to allow non-local
> binding.
Cool, now thanks to your tests, we know the code works with tproxyv4! Once you get everything working fine, would you please submit an example for the doc "architecture.txt" ? That would be very kind.
> > I'd bet it's the backend server which doesn't have its default gateway
> > set to route through haproxy. I'm almost 99% sure! It absolutely needs
> > to route the return traffic through haproxy so that the traffic is
> > transformed again.
>
>
> I tried configuring the default gateway on the backend web server to point
> to the HAProxy server, but that didn't help. So I ran Wireshark on the
> backend web server and found out that the backed web server is getting the
> request ok, but it's still sending the replies directly to the client and
> not the HAProxy server. I noticed this because of the destination MAC
> address it was trying to send to. So I added a static ARP entry on the
> backend web server using the client's IP address and the HAProxy servers MAC
> address, and that got it to work.
So that means that the client and the backend server are on the same subnet ! If so, this cannot work without routing changes on the backend servers. This is a well-known trap for people using NAT-based load-balancers.
In fact, you don't have to manually enter the ARP addresses, you just have to add a static route on all backends to reach each other through your haproxy box. But this is still dirty, in fact you should really have clients and servers on distinct LANs. Well, anyway if it works for you with static routes, maybe you will not want to bother with multiple LANs.
> It's almost as if the HAProxy would have to be inline with all traffic on
> the network (essentially a router), which isn't possible where I work.
Yes, as soon as you have an equipment which modifies the traffic (NAT-based load-balancer, proxy, etc...) it is mandatory that it gets both sides of the traffic. So if your client and servers are on the same LAN, you have no other choice than one of those :
Beware that you still cannot connect from one server to itself through the LB if you want to keep the source address, because it will respond "internally" and will not understand what it receives.
> I do have one additional question though. If HAProxy supported HTTP
> Keep-Alive I would be able to accomplish logging the correct client IP
> address by using the X-Forwarded-For header.
X-Forwarded-For has nothing to do with keep-alive. You just have to add "option forwardfor" in your config.
> I've seen in other postings
> that this is in the road map. Do you have any idea when that might be?
"forwardfor" is already there. Keep-alive is getting closer (at least on the frontend side) but is still a few versions ahead.
> Also,
> I'm open to any testing that you need done with it. Even if it means testing
> pre-alpha code. ;-)
Thanks, that's sometimes very useful !
Regards,
Willy
Received on 2008/08/11 09:19
This archive was generated by hypermail 2.2.0 : 2008/08/11 09:30 CEST