|
On 2002-05-01T19:34:20,
Tao Zhao <taozhao@xxxxxxxxxx> said:
> The way LVS uses NAT is that it assumes that all servers are behind the
> director so the director only need to change the destination IP when a
> request comes in and forward that to the scheduled real server. When the
> reply packets go through the director it will change the source IP. This
> limits the deployment of LVS using NAT: the director must be the outgoing
> gateway for all servers.
Please look up the description of the "direct routing" forwarding technique.
> I am wondering if I can change the code so that both source and
> destinamtion IPs are changed in both ways. For example,
> CIP: client IP;
> DIP: director IP;
> SIP: server IP (public IPs);
>
> Client->Director->Server: address pair (CIP, DIP) is changed to (DIP, SIP)
> Server->Director->Client: address pair (SIP, DIP) is changed to (DIP, CIP).
Not very efficient; but this can actually already be done by using the
port-forwarding feature AFAIK, or by a userspace application level gateway. I
doubt its efficiency, since the director would _still_ need to be in between
all servers and the client both ways.
Direct routing and/or tunneling make more sense.
Or did I miss something?
> This way, there will be no limitation where the servers are (the tunneling
> solution needs the change of server: setup tunneling)
>
> Now the question is: Is it feasible to implement this? Or there are flaws
> of it?
The most annoying flaw in addition to the above is that the clients do not
know where the connection originally came from; making the logs on them nearly
useless, also filtering by client IP and establishing a session back to the
client (ie, ftp or some multimedia protocols) is also very difficult.
Sincerely,
Lars Marowsky-Brée <lmb@xxxxxxx>
--
Immortality is an adequate definition of high availability for me.
--- Gregory F. Pfister
|
