☰

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

tag-icon • tag-icon linux networking virtualization
‘conntrack’ 跟踪虚拟机之间的私有 TCP 会话

我们有一对虚拟机作为虚拟路由器运行，并在两个虚拟路由器之间建立 BGP/TCP 对等连接（通过 QEMU/KVM 运行）。每个虚拟机都有一个 tap 接口，该接口连接到仅包含两个 tap 成员的 Linux 桥。

一切运行良好，只是我们发现 conntrack 似乎在报告这两个虚拟机之间的 TCP 会话。最初我们认为 TCP 会话正在泄漏，这是一个安全漏洞，但 netstat 什么也没报告。因此，似乎我们没有在主机操作系统上为此分配 TCB（这是正确的）；呼。客户操作系统流量应该对主机操作系统透明，看起来确实如此；大多数情况下。

这种 conntrack 行为之所以会成为问题，是因为如果两个虚拟机同时重置，那么就没有任何虚拟机在运行，无法在客户机 TCP 会话上发送任何流量，从而导致 TCP 重置；因此，我们在主机操作系统上得到了一个 conntrack“泄漏”。随着时间的推移，这种情况会逐渐增加，最终导致主机操作系统资源耗尽。我们在这个测试中有很多 BGP 会话。这似乎是客户机操作系统对主机操作系统进行 DoS 攻击的一种方式……

这是 conntrack 的有效行为吗？这是通过 L2 桥接器进行的私有 VM 到 VM 通信。为什么 Linux 应该监听和记录此类 TCP 会话？这是错误还是功能？

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

答案1

是的，这种行为是预料之中的，虽然我不知道这是不是您预料到的问题。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，方法是将该模块列入黑名单或在内核中禁用它。

相关内容