|
> > 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.
I agree that once the director sits in between the performance will be a
issue. But that cost is already in NAT. So the change won't introduce any
more overhead.
> Direct routing and/or tunneling make more sense.
>
> Or did I miss something?
But direct routing requires the director being on the same network with
all servers. The goal of my project is to distribute servers and
directors. Tunneling requires change of servers and routers between the
server and the client may refuse to forward reply packets to client once
it detects that the server fakes the IP.
> 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.
I raise this question because this scheme is more fit for my research
project than the existing NAT scheme (not that it's better), while the
issues above are not a problem in my project. Therefore, before I begin I
want to make sure it's feasible and can be done without many difficulties.
Thanks,
-Tao
|
