|
Matthias Weidle wrote:
>
> for the lvs config that means that we have to configure one VIP on each lvs
> director: the first VIP for the fw cluster seen from the outside and one
> VIP for the cluster as seen from the inside. (to be exactly: the internal
> fw VIP is the default GW address for the internal hosts)
the default gw for the fw you mean?
> the main reason that i need persistant connections in both ways is the vpn
> software installed on the fw boxes:
> if A wants to talk to B it first has to establish a secure tunnel to one of
> the fw boxes. then the secure traffic can be passed through that very
> tunnel to the internal host B.
> since the fw boxes don't share any keys i have to go sure that the backward
> traffic from B to A goes through that box too!
got it.
> here are my thoughts how this could be done by the lvs code:
>
> if a packet arrives on DR2 the lvs code has to inspect if the src MAC
> address of this packet is one of the known fw boxes. if that is the case it
> doesn't have to do any load balancing decision, it only has to remember the
> src and dst ip of that packet together with the MAC address of the fw box
> in some internal table.
hmm, might be possible. there are lots of tools which fiddle with packets, eg
fwmarks, the new routing stuff.
(This isn't neccessarily a good solution, but it's a first step).
Howabout: each fw box also does NAT. Packets coming out of each fw box
have the IP on the inside of the fw box as the source addr.
(These fw boxes are going to be fairly busy CPU wise).
You could then use a regular (non martian) VS-DR director for DR-2 and the
real-servers
for LVS-2 (eg host B) would only have 3 host routes (to the 3 fws, which are
the only machines they know about, since they are only getting packets with
src_addr of the fw machines).
I assume changing the IP's on the packets is going to mess up the key exchange a
bit. ;-\
> 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)
> PS: since i am subscribed in digest mode to this mailing list ... could you
> please do a CC to my mail address when answering? would be easier to make
> replies :))
OK this time, for your next posting, get yourself on the list. I have
a RFC non-compliant mail client (netscape) and when I "reply to all", I only
send to the list.
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
|
