# sysctl -p net.bridge.bridge-nf-call-ip6tables" is an unknown key 问题的解决。。

1. # sysctl -p
2. net.ipv4.ip_forward = 0
3. net.ipv4.conf.default.rp_filter = 1
4. net.ipv4.conf.default.accept_source_route = 0
5. kernel.sysrq = 0
6. kernel.core_uses_pid = 1
8. error: "net.bridge.bridge-nf-call-ip6tables" is an unknown key
9. error: "net.bridge.bridge-nf-call-iptables" is an unknown key
10. error: "net.bridge.bridge-nf-call-arptables" is an unknown key
11. kernel.msgmnb = 65536
12. kernel.msgmax = 65536
13. kernel.shmmax = 68719476736
14. kernel.shmall = 4294967296

1. error: "net.bridge.bridge-nf-call-ip6tables" is an unknown key
2. error: "net.bridge.bridge-nf-call-iptables" is an unknown key
3. error: "net.bridge.bridge-nf-call-arptables" is an unknown key

1. # modprobe bridge
2. # sysctl -p
3. net.ipv4.ip_forward = 0
4. net.ipv4.conf.default.rp_filter = 1
5. net.ipv4.conf.default.accept_source_route = 0
6. kernel.sysrq = 0
7. kernel.core_uses_pid = 1
9. net.bridge.bridge-nf-call-ip6tables = 0
10. net.bridge.bridge-nf-call-iptables = 0
11. net.bridge.bridge-nf-call-arptables = 0
12. kernel.msgmnb = 65536
13. kernel.msgmax = 65536
14. kernel.shmmax = 68719476736
15. kernel.shmall = 4294967296

netfilter is currently enabled on bridges by default. This means, for example, that IP packets that are forwarded across the bridge are filtered by the iptables FORWARD rules.

In practice, this can lead to serious confusion where someone creates a bridge and finds that some traffic isn't being forwarded across the bridge. Because it's so unexpected that IP firewall rules apply to frames on a bridge, it can take quite some time to figure out what's going on.

The libvirt wiki has this advice:

<a target=_blank href="http://wiki.libvirt.org/page/Networking#Fedora.2FRHEL_Bridging">http://wiki.libvirt.org/page/Networking#Fedora.2FRHEL_Bridging</a>

The final step is to configure iptables to allow all traffic to be forwarded
across the bridge

# echo "-I FORWARD -m physdev --physdev-is-bridged -j ACCEPT" > \
/etc/sysconfig/iptables-forward-bridged
# lokkit --custom-rules=ipv4:filter:/etc/sysconfig/iptables-forward-bridged

Alternatively, you can prevent bridged traffic getting pushed through the
host's iptables rules. In /etc/sysctl.conf add

# cat >> /etc/sysctl.conf <<EOF
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
EOF
# sysctl -p /etc/sysctl.conf

It sucks that people have to do this, especially since it's a very rare user who would be using iptables on a bridge for something useful.

I posted a patch to netdev which would have allowed us to disable it by default in our kernel builds:

<a target=_blank href="http://patchwork.ozlabs.org/patch/29319/">http://patchwork.ozlabs.org/patch/29319/</a>

The conclusion seems to be an agreement that distros should disable this, but using sysctl.conf instead

In the thread Herbert describes a security issue with the current default:

I still think the risk with bridging is higher, especially
in the presence of virtualisation.  Consider the scenario where you
have to VMs on the one host, each with a dedicated bridge with the
intention that neither should know anything about the other's
traffic.

With conntrack running as part of bridging, the traffic can now
cross over which is a serious security hole.

and goes on to say:

FWIW I don't really care what we have as the default for bridge
netfilter.  I just want to make sure that people who do have
bridge netfilter (and in particular, conntrack + bridge) active
on their machines are aware of the security implications.  Otherwise
we'd be negligent.

As you said distros can change the default regardless of what
the kernel does.

In summary, I think we should add the following to sysctl.conf:

net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
02-19 1万+
11-05 3万+
05-29 3036
02-19 2313
04-17 495
05-26 3165
09-17 6180
08-07 1206
08-31 6520
12-09 1133
05-23 604
05-13 2360
12-31 14万+
08-30 248
07-01 513
10-28 543
11-05 1063
08-21 87
06-28 216
05-15 223

• 非常没帮助
• 没帮助
• 一般
• 有帮助
• 非常有帮助