On 10/04/07 09:59, Pascal Hambourg wrote:
Do you mean that they are in different subnets ?
I doubt that the OPs systems are on different subnets, nor do I think
that it really matters for what s/he is wanting to do.
Private/public addressing does not matter here. You can have public
addresses behind a NAT box, although it may sound unusual (NAT is mostly
used to hide private addressing when you don't have enough public
addresses). The important word is "behind", meaning that traffic in both
directions flows through the NAT box. This is important because the NAT
box changed the source and/or destination address on the original
traffic, so it must put it back on the reply traffic in order for the
client to accept it as a reply. It's not the SNAT rule which puts the
original address back, it only makes the server see the NAT box as the
client and send the reply traffic back to it. But the drawback is that
the server does not see the real client source address.
Without SNAT, the mail server could use the NAT box as a gateway at
least for SMTP reply traffic (this could be done with advanced routing
if the mail server runs Linux) if they are in the same subnet or if a
tunnel can be established directly between them.
Ah yes, the old triangle of systems is being avoided. System A talks to
system B who talks to system C who talks back to system A. System A
knows that it talked to system B who for some strange reason is not
replying while there is this other character system C that is striking
up a conversation very improperly and as such being told where to RST to!
Sorry, I do not know how LVS works. I just know how Netfilter NAT works.
As I understand it there are basically three different modes of
operation for Linux Virtual Server (a.k.a. LVS) load balancers /
directors: NATing, Direct Routing, and Tunnel (a variant of DR).
I think DR and or Tunnel would be the better of the modes for this
situation, seeing as how NAT will not work because the reverse traffic
does not flow back through the LVS Director.
As I understand it (which could very well be flawed) in DR and Tunnel
mode, your upstream router says that the virtual server is available via
the next hop of the LVS director. The LVS director in turn load
balances and forwards (routes) the traffic on to the real servers which
have the target IP bound to an interface. Thus when the traffic does
come in to the real server it comes in and goes directly in to the bound
IP and associated services. Thus when the services reply to the traffic
they use the targeted IP as the source IP for reply traffic. Thus we
end up with system A talking to system C by way of system B with system
C replying directly through routing.
I think DR and Tunneling are more of a switching / bridging technology
in such as they alter the target ethernet mac addresses between the
various systems to spread the load.
I'm not quite sure how you could emulate this with out using LVS, except
possibly with bridging and EBTables rules to alter the target MAC of the
inbound frames so that they are re-forwarded on to the real server.
However for this to work your systems will have to be in the same
broadcast domain. If you want help with this, drop me a line and I'll
see what I can 'switch' up. ;)
Grant. . . .
-
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
