|
Hello,
On Tue, 1 May 2001, Joseph Mack wrote:
> > Question 2:
> > -----------
> > packets coming from the realservers to director need to be
> > masqueraded,
> > so that the realserver source IP is replaced with the VIP.
> > HOW does directory know that it has to use the VIP (assigned in my
> > case
> > to NIC interface eth1:0) and not the DIIP, the real outside address
> > of director (assigned in my case to NIC interface eth1)?
>
> I spent a lot of time talking to Julian about this on the mailing list
> (it will all be in the archive). In my situation, I have
> several IP's facing the outside world. I didn't understand why
> the packets emerge with the source address of the VIP,
> but Julian seems to understand. Go read the
> archives and then talk to Julian again. I don't know
> whether I wrote it up for the HOWTO or not. If you think you understand
> it, then how about you write it up for the HOWTO.
There are 3 common cases:
1. The connection is created as response to packet.
2. The connection is created as response to packet to another connection.
3. The connection is already created
Case (1) can happen in the plain masquerading case where the in->out
packets hit the masquerading rule. In this case when nobody recommends
the saddr for the packets going to the external side of the MASQ, the
masq code uses the routing to select the maddr for this new connection.
This address is not always the DIP, it can be the preferred source
address for the used route, for example, address from another device.
Case (1) happens also for LVS but in this case we know:
a) the client address/port (from the received datagram)
b) the virtual server address/port (from the received datagram)
c) the real server address/port (from the LVS scheduler)
But this is on out->in packet and we are talking about in->out packets
Case (2) happens for related connections where the new connection can
be created when all addresses and ports are known or when the protocol
requires some wildcard address/port matching, for example, ftp. In
this case we expect the first packet for the connection after some
period of time.
It seems you are interested how case (3) works. The answer is that the
NAT code remembers all these addresses and ports in a connection
structure:
- external address/port (LVS: client)
- masquerading address/port (LVS: virtual server)
- internal address/port (LVS: real server)
- protocol
- etc.
LVS and the masquerading code simply hook in the packet path
and they perform the header/data mangling. In this process they use the
information from the connection table(s). The rule is simple: when a
packet is already for established connection we must remember all
addresses and ports and always to use same values when mangling the
packet header. If we select each time different addresses or ports
we simply break the connection. After the packet is mangled the routing
is called to select the next hop. Of course, you can expect problems
if there are fatal route changes.
So, the short answer is: the LVS knows what maddr to use when
a packet from the real server is received because the connection is
already created and we know what addresses to use. Only in the
masquerading case (where LVS os not involved) connections can be
created and a masquerading address to be selected without using rule
for this. In all other cases there is a rule that recommends what
addresses to be used at creation time. After creation the same values
are used.
> Joe
Regards
--
Julian Anastasov <ja@xxxxxx>
|
