|
Hello Julian,
We should be working for our bosses, despite the fact that this
might be more interesting then what we need to do at work. :)
> These unique hash keys are able to identify all VPN clients behind
> CIP. We better not to try to differentiate the different masqueraded
> VPN clients behind CIP by SPI. It is a job for the web director
Maybe.
> behind the IPSec termination to play with the cookies. What is the
> drawback: all the masqueraded VPN clients will be scheduled to
> same RS - bad for load balancing? Not sure for IPSec.
Well, load balancing IPsec will anyway tend to be more kind of a
load imbalancing. But we can still try. I would already have a new
scheduler which I think could help for protocols that do not have
information for scheduling. I will tell you and Wensong when I'm
done investigating.
> Hm, use rsync :))) Push all private RSA keys or X.509
> Certificates to all real servers :) Or any other standardized
> proto for cert management :)
Shudder, rsync is broken! (And before all kinds of people on this
list tell me that rsync works for them: it simply doesn't work
for me, so don't bother convincing me.)
> > Hope that Henrik can wait that long.
>
> Yes, this will need rewriting the LVS, in the next devel
> versions. Of course, until then someone can experiment too :)
Not a plain rewriting, just some addition. Or do you plan to rewrite
it for 2.5.x?
> > Yes, I think the first approach should be LVS-DR and IPsec using
> > transport mode. After that we move to IPsec tunnel mode.
Yep.
> Yes, for the tunnel mode I'm not sure how the routing through
> the real servers will work, from the Director A. May be SNAT.
Why SNAT?
> > Ahhh, this is nasty. Netfilter has a table for AH/ESP in conntrack
> > but if we do LVS-DR we cannot use this, or can we? It would be easy
>
> It is useless for me. We can get it if it is needed.
We maybe first read the RFC or ask the AH/ESP netfilter guy what he
does with the timeouts.
> > to poll conntrack timeout entries and fill in those or we just define
> > one. Someone of us should start reading the RFC :)
>
> Yep
I started, but somehow I fell asleep at 5.00 this morning. It's
rather boring and a lot of stuff we will never need, like the
whole encryption an other things.
> > IMO ESP doesn't need a key, or what do you mean by key? And yes,
> > fwmark is excellent for this task.
>
> I mean the hash keys needed to maintain the LVS entries
:) Ahh, this makes sense now, thanks!
> The first IP header, where iph->protocol==ESP.
> No need to lookup into the internal headers, may be only for SPI.
Exactly, so basically transport mode should be quite easy.
> > +-+-+---+-------+-+---+----+-------+---------+
> > |A|B|SPI|Seq.Nr.|C|TCP|Data|Padding|Auth.Data|
> > +-+-+---+-------+-+---+----+-------+---------+
> >
> > Where:
> > A: new IP header (DGW, in our case the load balancer)
> > B: new extensions (not sure, I think hop-by-hop stuff)
> > C: original IP header (unfortunately _encrypted_)
>
> A
???
> > LVS_DR with case 1 should be ok:
> > o fwmark the service
> > o route key from IP header
> > o persistency template including <saddr:daddr:SPI>
>
> Agreed
But here we need to look into the ESP header if iph->protocol==ESP.
Another problem is that I'm not so sure how to distinguish transport
mode and tunneling mode. Because IPsec doesn't and should never know
that there is a router in between. Maybe I have a look at the Cisco
IOS source code, but it is so big ... :)
> > LVS_DR with case 2 is a little bit tricky:
> > o fwmark the service
> > o route key is not possible from encapsulated packet
>
> No, we need the saddr and daddr which are the secure
> gateway IPs
daddr in tunnel mode will always be equal to the VIP. No way of
routing based on daddr.
> > o persistency template could be some information of the new
> > extensions and maybe SPI
>
> Or SNET->FWMARK/AnyPROTO (already implemented)
This is redundant. fwmark is based on proto ESP/AH and VIP already.
We need a third argument, like SPI from the decapsulated ESP header.
> Yes, we don't know how much time to keep one ISAKMP and
> ESP session. Are there any keep-alives standardized? (A: RTFM :))
I have no idea, I don't know much about IPsec, still happy with
cipe (because I like to MASQ). I will maybe join the IPsec developer
mailinglist.
Cheers,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
|
