iptables 无法处理容器中的 macvlan 流量答案

【问题标题】：iptables not working on macvlan traffic in containeriptables 无法处理容器中的 macvlan 流量
【发布时间】：2023-04-04 00:57:02
【问题描述】：

我有一台主机，它有一个接口 eth0，IP 10.0.10.10/24。我启动docker，添加一个容器，没有网络。然后我在eth0上创建一个macvlan设备，给它IP10.0.10.20/24，然后放到容器里。

主机和容器现在都具有完整的网络访问权限。

然后我在主机上创建一个 iptables 规则，以丢弃所有进出容器 IP 10.0.10.20 的流量。规则不起作用，交通通过。

当然，如果我在容器内执行此操作（ip netns exec $PID iptables ... 或通过为容器提供 NET_ADMIN 功能），它可以工作。

底层主机的iptables规则是否应该不过滤流量？

【问题讨论】：

【解决方案1】：

答案是：你不能这样做。使用网桥时，流量会进出主机，因此会到达主机的 IP 堆栈。使用 macvlan 时，唯一的 ip stack 是容器中的那个，所以永远不会调用主机上的 iptables 规则。

唯一的方法是更改容器内部的 iptables 规则。

如果您不想授予容器访问权限，例如如果你想控制容器，那么在主机本身使用ip netns exec ...，它会控制容器中的iptables规则，而不会给容器本身控制。

我写了一个脚本来做到这一点。它可在https://github.com/deitch/ctables 和获得许可的麻省理工学院获得。

【讨论】：

谢谢。这也是我得出的结论 - 我遇到的问题是我不想使用网桥（它们比 macvlan 更能影响网络测量结果），而是对容器内使用的流量进行帐户/设置配额 和赋予容器 NET_ADMIN 权限。因此，我唯一的选择是定期检查容器内的 iptables 规则是否仍然有效。
@relet 为什么要给容器NET_ADMIN？为什么不使用我上面概述的ctables 解决方案，您可以从主机控制它？
而且，是的，桥接性能影响。对于大多数部署来说这并不重要，但对于某些部署来说却非常重要。我首先在一家金融机构流媒体价格上做了 macvlan。每一微秒都很重要。我对 docker bridge、bare metal、SR-IOV、macvlan 和其他一些在吞吐量和延迟方面进行了详细分析。我在今年的 dockercon 和 containercon 上提出了它作为一个演讲，我们将看看他们怎么说。我也想用 Calico 重做。
实际上两者 - 容器都需要 NET_ADMIN，因为它们是由第三方编写的一系列网络实验。我必须在包含它们和让它们完成它们的工作之间找到平衡，但我仍然可以用有意义的规则来初始化它们。分析后你选择了 macvlan 吗？
哦，所以他们无论如何都需要它，而您想控制来自外部的访问？啊，那你不能为此使用 iptables。 macvlan 只是不通过主机的 iptables。您必须在网络级别执行此操作。