我们有一对作为虚拟路由器运行的虚拟机，两台虚拟路由器（通过QEMU / KVM运行）之间的BGP / TCP对等。 每个虚拟机都有一个连接到只有两个水龙头作为成员的Linux网桥的tap接口。
除了我们看到conntrack似乎在报告这两个虚拟机之间的TCP会话之外，所有的工作都很好。 最初我们认为TCP会话正在泄漏，这是一个安全漏洞，但是netstat没有任何报告。 所以我们似乎没有在主机操作系统上分配一个TCB（这是正确的）。 唷。 来宾操作系统stream量应该是透明的主机操作系统，它似乎是; 大多。
这种conntrack行为是一个问题的原因是，如果两个VM同时被重置，那么没有人留下来运行在来宾TCP会话上发送任何stream量导致TCP重置; 所以我们在主机操作系统上出现一个“泄漏”的情况。 随着时间的推移，这会形成并最终主机操作系统耗尽资源。 在这个testing中我们有很多的BGP会话。 似乎这是一个客户操作系统到主机操作系统上的DoS的方式…
这是conntrack有效的行为？ 这是通过L2桥的私有VM到VM通信。 为什么Linux要窥探和logging这样的TCP会话？ 这是一个错误还是一个function？
大多数的方法似乎都涉及到iptables来阻止这个; 我们真的不想要客户这样做。 还有其他build议吗？
是的， 这种行为是预期的 ，但我不知道这是你预期的问题。 conntrack表上的TCP和UDP连接都会自行失效。 您可以在/proc/sys/net/netfilter/*timeout*看到超时值，并通过/proc或sysctl来调整这些值。 请注意，这可能会在旧的内核上有所不同，可能是/proc/sys/net/ipv4/netfilter/ 。
如果这不会削减它，你不满意iptables -t raw -j NOTRACK解决scheme，你可以通过设置closuresiptables处理桥接连接
sysctl -w net.bridge.bridge-nf-call-arptables=0 sysctl -w net.bridge.bridge-nf-call-ip6tables=0 sysctl -w net.bridge.bridge-nf-call-iptables=0 sysctl -w net.bridge.bridge-nf-filter-vlan-tagged=0
或者在/etc/sysctl.conf设置相同的参数。 这两种方法都将禁止将桥接stream量传递给iptables，这应该会绕过conntrack。
或者，如果您没有通过将模块列入黑名单或在内核中禁用它，则可以完全禁用ip_conntrack。