|
Hello,
On Fri, 2 Feb 2001, Joseph Mack wrote:
> Julian Anastasov wrote:
> >
> > Hello,
> >
> > On Fri, 2 Feb 2001, Joseph Mack wrote:
> >
> > > > So, we need a way to nat the outgoing packets in the real
> > > > server but only when we access the client's authd.
> > >
> > > The packets from the real-server to the client's authd
> > > come from the VIP on the real-server and not the RIP.
> >
> > But we need they to leave from the real server with saddr=RIP2.
> > RIP2 will be used only to connect to remote authd through the director.
> > We need one RIP2 for each VIP - this will be used in the director
> > to select the right VIP as maddr for the different RIP2 saddr.
>
> hmm, diagram for clarification of what I'm thinking
> (I only have one VIP, not sure why you have several).
We have several RIPs:
RIP: the main RIP
RIP1 is used to translate packets VIP1:1024 -> client1:113 to
RIP1:1024 -> client1:113
RIP2 is used to translate packets VIP2:1024 -> client2:113 to
RIP2:1024 -> client2:113
and so on. This is the case where we must select the right VIP
in the director when talking to client*:113. For each VIP* in the real
server we need one unused RIP* for these cases. If we map all VIPs
to one RIP before forwarding this packet through the director we always
will select one VIP as maddr there and this breaks the ident protocol.
We need one unused RIP for each VIP that can use ident.
Then in the patched director we will use:
ip rule ... from RIP1 table 100
ip route add table 100 ... src VIP1
ip rule ... from RIP2 table 101
ip route add table 101 ... src VIP2
and will hope the patched masquerading to select the right
maddr (oh, all these troubles for such protocol).
> (There is no LVS installed, just showing NAT parts,
> but IPs are for a VS-DR LVS)
>
> client
> (eth0 192.168.2.254)
> |
> (eth0 192.168.2.1 = DIP)
> (eth0:1 192.168.2.110 = VIP)
> director
> (eth1:192.168.1.9)
> |
> (eth0 192.168.1.12 = RIP)
> (lo:0 192.168.2.110 = VIP)
> real-server
>
> the authd client on the real-server makes its call
>
> VIP:high_port -> client:authd
>
> the replies don't get back to the real-server.
>
> my scheme to get it to work
>
> on real-server
>
> VIP:high_port -> client:authd (high_port is say 1025)
>
> have NAT running on real-server, the
> packet emerges from the real-server
>
> RIP:higher_port -> client:authd (higher_port is say 60001)
No, higher_port is still equal to high_port. At least if
dumb nat is used (you can't change the port with dumb nat).
> this packet arrives at director where it is NAT'ed
> again and emerges from the LVS as
>
> VIP:even_higher_port -> client:authd (even_higher_port is ?)
Right. I was talking about the same case. So, may be we can do
it with dumb nat in Linux 2.4 but not in 2.2. We need to distinguish
the both cases:
VIP:25 -> client:1024
VIP:1024 -> client:authd
Only in 2.4 we can use fwmark in the LOCAL_OUT chain to
mark the packets when they are locally generated. So, we have to check
whether dumb nat can do the desired translation when the packet leaves
the real server and then when the replies from client:authd are received.
> Something I hadn't thought of... Can NAT accept a packet
> with a port number that's already been NAT'ed?
Yes, but we can't NAT the port for locally generated packets
in the real server.
> Joe
>
>
> --
> Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
> contractor to the National Environmental Supercomputer Center,
> mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA
Regards
--
Julian Anastasov <ja@xxxxxx>
|
