|
Good evening,
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.
As you wish ...
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).
How about a generic scheduler where you can register schedulers that
feed that generic scheduler with input. For example let's assume the
scheduler just does weighted round robin but also has an interface to
get new scheduling input from others. Like this a lot of schedulers
could be tested an all we need is an API for user space calls into the
kernel. Alexandre Cassen is indirectly going into that direction. In
principle you only supply the new weight to the scheduler and it takes
care of the rest.
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.
Ok, let me know it.
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.
All ways with NAT disable some functionality of IPsec.
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.
Well, I informed myself a bit on the timeout issue and in principle it
is dead simple, the impact on LVS routing is a general PITA. A
"established", authenticated IPsec connection between two endpoints
basically stays up forever. If however the setup is done in a different
way, the user can specify the timeout. This is transfered via the UDP
packets first which initiate the whole connection setup. After that the
IKE SA setup does some magic key handshaking and generates on each side
an SA for the connection. All those things have to be persistent. Now
the SPI stays for the session until the timeout expires and that is
where we have to pay attention. If a SA pool creates a new SPI we need
to figure that out and to some kind of RELATED entry and put that into
the persistence template of the old session.
I think (before any coding) that there should not be
big problems.
I'm not so optimistic.
Exactly, so basically transport mode should be quite easy.
In fact, we don't care what we reroute, tunnel, transport
Well, for selecting the routing key you certainly to, or do you only
want to take saddr->fwmark as a key? SPI works if we can keep track of
rekeying events of related sessions.
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.
Actually the RFC strangely mentiones that one doesn't need to know such
things for routing. So I'm convinced now.
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
Ok.
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
Well, tonight while cooking for Valentine's Day dinner this idea popped
into my head too. SNET->FWMARK template is the smallest possible working
subset for IPsec tunnels. I agree.
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.
Oh, good. Well, I kinda know now how this works. But since the template
will be saddr only, a timeout or rekeying is not an issue anymore. The
only problem we could face is that if we would allow infinit timeouts
that this would potentially open a small risk of overflowing the kernel
memory by time. So I suggest one implements the persistency template
timeout to the code too.
Good night,
Roberto Nibali, ratz
|
