|
> I just re-read the entire thread and I'm now more confused
> than I was at the start.
>
> Nicklas, what you seem to be saying is that regardless of the
> VIP the client connects to, they get a response from a
> different IP which never varies, right?
>
> Forgive me for stating the obvious - that's just broken.
> Every time (bar one, which got fixed by fixing the FTP
> helper) I have setup LVS-NAT with multiple VIPs, I haven't
> needed any conntrack stuff for LVS at all. The very fact that
> there are multiple VIPs means that (as long as the IPVS
> framework is working correctly) the responses from
> realserver->client have been caught and un-NATted by LVS. No
> need for netfilter at all.
>
> In the "raw", unpatched state, do you have LVS debugging
> enabled? It might be worth you unpicking the nfct patch and
> turning on plain ole'
> LVS debugging.
>
> Graeme
Thanks for your comments Graeme! You led me in the right direction tracing
down this problem, and bring my focus off the LVS part of our setup.
In my latest tests I found out that everything was working the way it should
with https, which further led me into debugging our apache setup. It shows
that apache didn't have the appropiate virtual hosts configured for all the
vip's. This is why I always saw the same ip address as source. The ip of the
_default_ (first configured) apache virtual host.
I want to give a big thanks to everyone on the list who have spent their
time on this and given me very valuable information about LVS and the way
it's working with netfilter. Thank you!
Nicklas
|
