|
Hello,
On Thu, 14 Feb 2002, Roberto Nibali wrote:
> 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. :)
Yes, we can try it soon with a dirty patch to the latest
0.9.X patches and then to add it to the next LVS devel vers if
everything is looking good.
> > 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.
OK, at least the schedulers are modular (mostly). We
can do the same for the protocols (may be not in separate file
but at least with distinct methods).
> > 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.)
Oh, well.
> > > 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?
No, we need better structured code in the next versions
and may be to work at prerouting. We will discuss some ideas
on this issue.
> > 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?
It is one of the variants (masquerade). May be there is
another way, I can't see it now.
> > > 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.
Good idea, RTFM first. As for the netfilter AH/ESP support, it is
only a match.
> 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.
I think (before any coding) that there should not be
big problems.
> > 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.
In fact, we don't care what we reroute, tunnel, transport.
> > > 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
>
> ???
sorry, always the outer header
> 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
We don't care about the method, we are not terminator.
> that there is a router in between. Maybe I have a look at the Cisco
> IOS source code, but it is so big ... :)
No need to look :)
> > 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.
daddr is always a local IP in the LVS box (VIP). We
call the routing with daddr=selected_RS
> > > 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.
No :) SNET->FWMARK template uniquely identifies a client
IP (and all clients behind it) accessing a virtual service. An
entry SNET->VIP, ESP is a ESP entry. If we include the SPI we
can differentiate all SAs from client to this VIP but I'm not sure
how we can include this info in conn template. The persistence
covers all "connections" from one client IP. And we need persistence
because we have proto 50, 51 and UDP:500
> > 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.
Yes, most of the things are clear now, we simply should
try it one day. I have env to test it, so no problem.
> Cheers,
> Roberto Nibali, ratz
Regards
--
Julian Anastasov <ja@xxxxxx>
|
