linux – ‘conntrack’跟踪虚拟机之间的私有TCP会话

前端之家收集整理的这篇文章主要介绍了linux – ‘conntrack’跟踪虚拟机之间的私有TCP会话前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我们有两对虚拟机作为虚拟路由器运行,两个虚拟路由器之间的BGP / TCP对等(通过QEMU / KVM运行).每个虚拟机都有一个分接接口,该接口连接到只有两个分接头作为成员的 Linux网桥.

一切都很好,除了我们看到conntrack似乎报告这两个VM之间的TCP会话.最初我们认为TCP会话正在泄漏,这是一个安全漏洞,但netstat没有报告任何内容.所以我们似乎没有在主机操作系统上为此分配TCB(这是正确的);唷.客户操作系统流量应该对主机操作系统透明;大多.

这个conntrack行为是一个问题的原因是,如果两个VM同时重置,那么没有一个运行在guest虚拟机TCP会话上发送任何流量以导致TCP重置;所以我们在主机操作系统上遇到了“漏洞”.随着时间的推移,这会逐渐增加,最终主机操作系统会耗尽资源.我们在这个测试中有很多BGP会话.似乎这是客户操作系统在主机操作系统上使用DoS的一种方式…

这是conntrack的有效行为吗?这是通过L2网桥进行的虚拟VM到VM通信.为什么Linux应该窥探并记录这样的TCP会话?这是一个错误还是一个功能

大多数方法似乎都涉及iptables来阻止这种情况;我们真的不想要求客户这样做.还有其他建议吗?

解决方法

是的,this behavior is expected,虽然我不知道这是你预期的问题. conntrack表上的TCP和UDP连接都会随着时间的推移而过期.您可以在/ proc / sys / net / netfilter / * timeout *中查看超时值,并通过/ proc或sysctl调整这些值.注意,在旧内核上可能会有所不同,可能是/ proc / sys / net / ipv4 / netfilter /.

如果这不会削减它并且您对iptables -t raw -j NOTRACK解决方案不满意,您可以通过设置关闭桥接连接的iptables处理

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中设置相同的参数.这两个都将禁止将桥接流量传递到iptables,这应该具有绕过conntrack的效果.

或者,您可以完全禁用ip_conntrack,如果您没有通过将模块列入黑名单或在内核中禁用它来使用它.

猜你在找的Linux相关文章