一切都很好,除了我们看到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=0sysctl -w net.brIDge.brIDge-nf-call-ip6tables=0sysctl -w net.brIDge.brIDge-nf-call-iptables=0sysctl -w net.brIDge.brIDge-nf-filter-vlan-tagged=0
或者在/etc/sysctl.conf中设置相同的参数.这两个都将禁止将桥接流量传递到iptables,这应该具有绕过conntrack的效果.
或者,您可以完全禁用ip_conntrack,如果您没有通过将模块列入黑名单或在内核中禁用它来使用它.
总结以上是内存溢出为你收集整理的linux – ‘conntrack’跟踪虚拟机之间的私有TCP会话全部内容,希望文章能够帮你解决linux – ‘conntrack’跟踪虚拟机之间的私有TCP会话所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)