sysctl -p net.bridge.bridge-nf-call-ip6tables" is an unknown key 問題的解決。。
阿新 • • 發佈:2018-12-23
筆者在RHEL6.3中執行sysctl -p的時候發現輸出出現以下錯誤
[python] view plaincopyprint?- # sysctl -p
- net.ipv4.ip_forward = 0
- net.ipv4.conf.default.rp_filter = 1
- net.ipv4.conf.default.accept_source_route = 0
- kernel.sysrq = 0
- kernel.core_uses_pid = 1
- net.ipv4.tcp_syncookies = 1
- error: "net.bridge.bridge-nf-call-ip6tables"is an unknown key
- error: "net.bridge.bridge-nf-call-iptables"is an unknown key
- error: "net.bridge.bridge-nf-call-arptables"is an unknown key
- kernel.msgmnb = 65536
- kernel.msgmax = 65536
- kernel.shmmax = 68719476736
- kernel.shmall = 4294967296
經過Google大神點選開啟連結後來找到的了原因所在,原來以下3個引數依賴於bridge模組,該模組如果沒有載入則會現上面的輸出錯誤
- error: "net.bridge.bridge-nf-call-ip6tables"is an unknown key
- error: "net.bridge.bridge-nf-call-iptables"is an unknown key
- error: "net.bridge.bridge-nf-call-arptables"is an unknown key
載入模組測試,發現問題解決
- # modprobe bridge
- # sysctl -p
- net.ipv4.ip_forward = 0
- net.ipv4.conf.default.rp_filter = 1
- net.ipv4.conf.default.accept_source_route = 0
- kernel.sysrq = 0
- kernel.core_uses_pid = 1
- net.ipv4.tcp_syncookies = 1
- net.bridge.bridge-nf-call-ip6tables = 0
- net.bridge.bridge-nf-call-iptables = 0
- net.bridge.bridge-nf-call-arptables = 0
- kernel.msgmnb = 65536
- kernel.msgmax = 65536
- kernel.shmmax = 68719476736
- kernel.shmall = 4294967296
有人可能會好奇這三個值得意義所在,我在紅帽官網找到了相關說明點選開啟連結
以下大致的意思主要說使用以上3個選項阻止橋接流量獲得通過主機iptables規則,Netfilter是預設情況下啟用了橋樑,如果不阻止會導致嚴重的混亂
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 # service libvirtd reload 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