将 LXC 容器桥接到主机 eth0，以便它们可以拥有公共 IP

Question 1

使更改永久生效的更好方法是使用 sysctl 而不是直接写入 /proc，因为这是在运行时配置内核参数的标准方法，以便它们在下次启动时正确设置：

# cat >> /etc/sysctl.d/99-bridge-nf-dont-pass.conf <<EOF
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0
EOF
# service procps start

至于您更新中问题的答案......

bridge-netfilter (或 bridge-nf)是 IPv4/IPv6/ARP 数据包（甚至在 802.1Q VLAN 或 PPPoE 报头中）的一个非常简单的桥梁，它提供了状态透明防火墙的功能，但更高级的功能，如透明 IP NAT，是通过将这些数据包传递给 arptables/iptables 进行进一步处理来提供的——然而，即使不需要 arptables/iptables 的更高级功能，在内核模块中仍然默认打开将数据包传递给这些程序，并且必须使用 sysctl 明确关闭。

他们来这里干什么？这些内核配置选项用于将数据包传递（1）或不传递（0）到 arptables/iptables，如bridge-nf 常见问题解答：

As of kernel version 2.6.1, there are three sysctl entries for bridge-nf behavioral control (they can be found under /proc/sys/net/bridge/):
bridge-nf-call-arptables - pass (1) or don't pass (0) bridged ARP traffic to arptables' FORWARD chain.
bridge-nf-call-iptables - pass (1) or don't pass (0) bridged IPv4 traffic to iptables' chains.
bridge-nf-call-ip6tables - pass (1) or don't pass (0) bridged IPv6 traffic to ip6tables' chains.
bridge-nf-filter-vlan-tagged - pass (1) or don't pass (0) bridged vlan-tagged ARP/IP traffic to arptables/iptables.

禁用所有 bridge-nf-* 是否安全？是的，这样做不仅安全，而且建议发行版默认关闭该功能帮助人们避免混淆对于您遇到的问题类型：

实际上，这可能会导致严重的混乱，有人创建了网桥，却发现有些流量没有通过网桥转发。由于 IP 防火墙规则应用于网桥上的帧是意料之外的事情，因此可能需要相当长的时间才能弄清楚发生了什么。

并提高安全性：

我仍然认为桥接的风险更高，尤其是在虚拟化的情况下。考虑一下这样的场景：一台主机上有两个虚拟机，每个虚拟机都有一个专用的桥接器，目的是让它们都不知道对方的流量。

由于 conntrack 作为桥接的一部分运行，流量现在可以跨越，这是一个严重的安全漏洞。

更新：2015 年 5 月

如果您运行的内核版本早于 3.18，那么您可能会受到默认启用桥接过滤这一旧行为的影响；如果您的内核版本高于 3.18，那么如果您已加载桥接模块且未禁用桥接过滤，您仍会受到此行为的影响。请参阅：

https://bugzilla.redhat.com/show_bug.cgi?id=634736#c44

经过这么多年一直要求将桥接过滤的默认设置“禁用”，但这一改变遭到了内核维护人员的拒绝，现在过滤已被移至一个单独的模块，该模块在桥接模块加载时不会（默认情况下）加载，从而有效地将默认设置“禁用”。耶！

我思考这是从 3.17 版开始的内核（它肯定在内核 3.18.7-200.fc21 中，并且似乎在 git 中标签“v3.17-rc4”之前）

Answer