Open Stack

Hi Elena,

On Thu, Oct 23, 2014 at 4:22 AM, Elena Ezhova <eezhova at mirantis.com> wrote:
> Kill the connection using conntrack
>
>           The problem here is that it is sometimes impossible to tell which
> connection should be killed. For example there may be two instances running
> in different namespaces that have the same ip addresses. As a compute
> doesn't know anything about namespaces, it cannot distinguish between the
> two seemingly identical connections:

If it really were different namespaces -- Linux network namespaces --
then it wouldn't matter.  The conntrack context is isolated between
namespaces.  A similar fix for floating IPs takes advantage of this
fact [1].  However, I don't think you meant "Linux network namespaces"
when you said "different namespaces" above.  I think you probably just
meant to use "different namespaces" as a more generic term for
different network traffic domains that are isolated from each other.
So, moving on...

In the case of security groups on compute nodes isolation is
accomplished using VLANs, linux bridges, etc.  So, yes, the conntrack
context is shared.  I can't think of a way to use conntrack to solve
this problem.

I'm not advocating the following approach at the moment, just
brainstorming here...  I wonder if we could just ignore the potential
IP address overlap and kill the connections anyway.  What would
happen?  Some connections that were supposed to survive will actually
recover if nf_conntrack_tcp_loose is enabled.  But, some may not
recover.  So, maybe this isn't a brilliant idea.

> I wonder whether there is any way to search for a connection by destination
> MAC?

Well, for one thing, the mac is not guaranteed unique either.  For
another, I don't even know if conntrack is aware of or cares about any
L2 details about the connection since it is kind of an L3/L4 sort of
thing.

> Delete iptables rule that directs packets associated with a known session to
> the RETURN chain
>
>            It will force all packets to go through the full chain each time
> and this will definitely make the connection close. But this will strongly
> affect the performance. Probably there may be created a timeout after which
> this rule will be restored, but it is uncertain how long should it be.

I don't think this is just about performance, this will cause other
connections to stop working.  If I'm not mistaken, removing these
rules makes it behave more like a stateless firewall.  In stateless
firewalls, rules must be spelled out independently for ingress and
egress packets whereas in a stateful firewall, one typically thinks of
the whole connection as ingress or egress (after adding those
RELATED/ESTABLISHED rules to allow the other direction through based
on conntrack state).

Here's another brainstorming idea...  I wonder if something could be
done with the NOTRACK target in the raw table.  Could such a rule be
added to squash active connections by hiding them from conntrack?
Rules could be added with a timeout so that they don't stay in the
table forever.  The rule would have to be written to match security
group rules that were just deleted.  This could be tricky.  But, once
added, they could be  removed on the next iptables update after a
given period of time or on agent restart.

Carl

[1] https://review.openstack.org/#/c/103475/