|
> On Wed, 4 Apr 2001, Robert Zwissler wrote:
>
> > The server is Linux 2.4.2/LVS 0.2.8/IPtables 1.2, running persistant NAT
> >
> > I've noticed two distinct problems. 1) When using SNAT on the LVS
server
> > ie:
> > iptables -t nat -A POSTROUTING -d <realserver_ip> -j SNAT --to
> > <lvs_server_ip>
> > the IP never gets SNAT'd. With LVS, is the POSTROUTING chain skipped?
>
> Is this command correct? I don't understand the goal. The
> POSTROUTING chain is skipped for LVS packets coming from the NAT-ed
> real servers. In all other cases the packets traverse the POSTROUTING
> chain.
I'm doing this so that I can have the realservers on the same subnet
as the clients and still use NAT. It is the right command, I know there
are other (better?) ways of doing this (ie DR); however it is nice to
have the simplicity of NAT, as well as being able to shuffle real
servers in and out without configuration on the real server end.
> > 2) When using DNAT on the realserver ie:
> > iptables -t nat -A PREROUTING -d <virtual_ip_unused_by_lvs> \
> > -j DNAT --to <real_server_ip>
> > it works as expected - you can ssh to the virtual IP and get forwarded
onto
> > the
> > realserver through the LVS server. However, when you try to access a
port
> > on the realserver which also maps to a LVS service, the response packet
> > never makes it back to the client. It gets lost on the LVS server.
>
> True, LVS assumes the connection is already expired when
> a packet comes from NAT-ed real service and there is no such connection.
> There is a code that does not allow sending the in->out packets as-is
> when there is no connection. But may be we can think on changing it
> for 2.4 because we can see any packets in the forwarding chain.
This would be a nice function so that the real servers could be accessed
and tested independantly regardless of scheduling! (ie external monitoring,
QA testing etc).
later,
Rob
|
