|
Hi Nick,
> Using tcpdump, I can see the request hitting the director, and then hitting
> the real server, and the real server responding back to the client IP with
> a zero length response (ack?), that goes on for 4-5 times until timeout.
It sounds like the server's responses aren't making it through,
meaning that a TCP three-way handshake cannot be completed.
What is sitting in front of the real server, and *is it stateful*? A
router? A firewall?
Every time I've built a working LVS/TUN environment, without fail,
I've had to make configuration changes on the router or firewall
sitting in front of the real servers. Without doing so, the router or
firewall drops the return traffic.
When using a Linux router, I always disable the rp_filter. When using
a pfSense firewall, I create floating firewall rules to cover all TCP
flags and 'sloppy state keeping' on the inbound and outbound network
interfaces.
Does the virtual IP address on the real server look 'out of place' in
the context of the rest of the network? For example, if a router
expects to see addresses in 10.0.0.0/24 on eth0 and addresses in
192.168.0.0/24 on eth1 but it starts seeing traffic from 10.0.0.20
coming *in* on eth1 (e.g. from a VIP address) then the router may well
drop the return traffic. There's probably a more rigorous or 'correct'
way to describe this, but those are from my own practical notes on
setting up LVS/TUN environments.
I hope this helps.
Thanks,
Andrew
--
Andrew Howe
Loadbalancer.org Ltd.
www.loadbalancer.org
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
