|
Matthias Weidle wrote:
>
> > I assume changing the IP's on the packets is going to mess up the key
> > exchange a bit. ;-\
>
> yes, absolutely. doing NAT is no option at all since it would break the VPN
> stuff.
hmm, I don't know a whole lot about vpn. which pairs of machines are exchanging
keys?
Host B and the fw machines?
> >> if the src MAC address of the incoming packet is not any of the
> >> configured fw boxes, then the packet came from the attached internal LAN
> >> and a load balancing decision has to be made if there is NOT yet an
> >> entry in the connection tracking table. if we already got a matching
> >> entry (same src and dst ips) we have to use the already associated fw
> >> box for this connection (means forwarding the packet for further
> >> processing to the MAC of the fw box).
> >
> > are you saying -
> > packets from the local LAN are processed by the LVS in the normal way
> > (ie without consideration of fw boxes etc)
>
> no, i think you got me wrong on that.
>
> 1. for the communicating hosts A and B the number of involved fw boxes is
> completely transparent. they don't know that there is a load balancing
> mechanism between them. host B on the local LAN only knows its default GW
> for sending packets to the outside: this is the VIP of the fw cluster (i.e.
> the VIP on DR2 = VIP2).
If host B is a real-server in LVS-2, then its default gw can't be VIP2. It
has to be an IP on the director (for VS-NAT) or the router on the outside
of director-2 (if VS-DR/VS-Tun).
host A on the other hand knows that there is
> something between A and B whis has to be used to establish the secure
> tunnel: this is VIP1 (the VIP of the fw cluster on DR1).
again I don't know enough about vpn here. I would assume that host A is just
sending packets to VIP1 and has no idea about vpn/fw or what happens to the
packet after it reaches director1.
> 2. since the fw boxes don't share any key information we have to go sure
> that all packets for a particular connection between A and B only travel
> over exactly _one_ fw box (this includes of course both directions A->B and
> B->A).
got that.
> 3. the only instances which know about the involved fw box for the
> communication between A and B are the two LVS directors DR1 and DR2.
they have to know about the fws to make reply packets go back along
the path that the incoming packets traversed.
for
> both DR's i would chose the persistant mode, so that a load balancing
> decision (i.e. which fw box to use) has to be made only for the very first
> packet from A to B (this happens on DR1). all the following packets will be
> just forwarded to the choosen fw box. DR2 doesn't do any load balancing for
> incoming traffic from A to B - it only has to remember which fw box the
> packet came from (i.e. which SRC MAC the packet had), so that the response
> traffic from B to A can flow over the same fw box.
> for connections initiated on host B the mechanism works the other way
> round. that means DR2 makes a load balancing decision and DR1 has to
> remember the fw box the packet arrived from.
>
> as i understand the LVS for now there is not any mechanism already included
> which can handle the response traffic the way i do need it in my specific
> application.
yes
> so what i do need to know is whether there are already similar mechanisms
> (maybe for LVS-NAT) which do inspect those return packets and how much
> effort you guys think it would take to include such behaviour for that
> special case of LVS-DR (if at all possible).
LVS is all layer-4 (at the moment). So you could make your scheme work
if the packets coming out of the fw had different IP's on them. The NAT
scheme for doing this you've already discounted.
Your suggestion was differentiating by MAC address (which I think is layer-3,
tcpip layers don't map onto the ISO-7 layers real well). I'm sure it's doable.
How much work it would be I don't know. You'd have to familiarise yourself
with the LVS code and start programming.
I had a think about this problem yesterday afternoon, and couldn't come up with
any other ideas.
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
|
