Hi, Elena Ezhova, thanks for your work to this problem!
I agree with your analysis, this why I commit this bug but don't submit patch
for it.
I have want to use conntrack to solve this bug, but I also thought the
problem you have said:
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:
$ sudo conntrack -L | grep "10.0.0.5"
tcp 6 431954 ESTABLISHED src=10.0.0.3 dst=10.0.0.5
sport=60723 dport=22 src=10.0.0.5 dst=10.0.0.3 sport=22 dport=60723 [ASSURED]
mark=0 use=1
tcp 6 431976 ESTABLISHED src=10.0.0.3 dst=10.0.0.5
sport=60729 dport=22 src=10.0.0.5 dst=10.0.0.3 sport=22 dport=60729 [ASSURED]
mark=0 use=1
1. I think this problem is due to that in compute node, all tenants instances
(if use ovs agent, it use vlan to isolate different tenant instance) are in
same namespace, so it can't distinguish the connection as above use case.
2. the ip_conntrack works above L3, so it can't search for a connection by
destination MAC
I am not clear as ajo said:
I'm not sure if removing all the conntrack rules that match the certain
filter would be OK enough, as it may only lead to full reevaluation of rules
for the next packet of the cleared connections (may be I'm missing some corner
detail, which could be).
在 2014-10-23 18:22:46，"Elena Ezhova" <eezh...@mirantis.com> 写道：
Hi!
I am working on a bug "ping still working once connected even after related
security group rule is deleted"
(https://bugs.launchpad.net/neutron/+bug/1335375). The gist of the problem is
the following: when we delete a security group rule the corresponding rule in
iptables is also deleted, but the connection, that was allowed by that rule, is
not being destroyed.
The reason for such behavior is that in iptables we have the following
structure of a chain that filters input packets for an interface of an istance:
Chain neutron-openvswi-i830fa99f-3 (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
state INVALID /* Drop packets that are not associated with a state. */
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
state RELATED,ESTABLISHED /* Direct packets associated with a known
session to the RETURN chain. */
0 0 RETURN udp -- * * 10.0.0.3 0.0.0.0/0
udp spt:67 dpt:68
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
match-set IPv43a0d3610-8b38-43f2-8 src
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:22 <---- rule that allows ssh on port 22
1 84 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0
0 0 neutron-openvswi-sg-fallback all -- * * 0.0.0.0/0
0.0.0.0/0 /* Send unmatched traffic to the fallback chain. */
So, if we delete rule that allows tcp on port 22, then all connections that are
already established won't be closed, because all packets would satisfy the
rule:
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
state RELATED,ESTABLISHED /* Direct packets associated with a known
session to the RETURN chain. */
I seek advice on the way how to deal with the problem. There are a couple of
ideas how to do it (more or less realistic):
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:
$ sudo conntrack -L | grep "10.0.0.5"
tcp 6 431954 ESTABLISHED src=10.0.0.3 dst=10.0.0.5 sport=60723
dport=22 src=10.0.0.5 dst=10.0.0.3 sport=22 dport=60723 [ASSURED] mark=0 use=1
tcp 6 431976 ESTABLISHED src=10.0.0.3 dst=10.0.0.5 sport=60729
dport=22 src=10.0.0.5 dst=10.0.0.3 sport=22 dport=60729 [ASSURED] mark=0 use=1
I wonder whether there is any way to search for a connection by destination MAC?
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.
Please share your thoughts on how it would be better to handle it.
Thanks in advance,
Elena
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
