服务器closures后需要重新启动iptables

我有一个服务器作为主机（KVM），代理和防火墙。为了访问这台主机上的虚拟机提供的服务， iptables必须工作以便正确地将数据包redirect到guest虚拟机。

服务器closures时会出现问题（即：重新启动或断电）。当服务器再次启动时，端口redirect似乎不起作用（即：不能SSH到客户机或使用主机的redirect端口访问他们的服务）。

那时候，我可以通过SSH连接主机并validationiptables是否正在运行。但是，我需要service iptables restart一切按预期工作。

为什么发生这种情况？它与使用KVM有关吗？我怎么能避免每次服务器closures时手动重新启动iptables ？

请注意，我不需要更改iptablesconfiguration以使所有内容都按预期工作，我只需要重新启动服务（就好像configuration没有正确应用或在某些时候被覆盖一样）。

UPDATE

在主机上：

 # chkconfig --list iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off

比较重新启动服务前后的iptables规则：

PREROUTING链看起来完全一样。
INPUT链看起来非常相似。唯一的区别是在重新启动之前，有一些重复的条目，但条目的顺序也是相似的。
POSTROUTING链看起来非常相似。唯一的区别是在重新启动之前，有一些重复的条目，但条目的顺序也是相似的。
FORWARD链条看起来更加不同。在重新启动服务之前，有一些重复的条目，但条目的顺序在更改前后发生更改。

以下是不同之处（ PREROUTING链已被排除，因为在重新启动iptables之前和之后它看起来完全一样）：

之前

 Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE tcp -- 10.0.0.0/24 !10.0.0.0/24 masq ports: 1024-65535 MASQUERADE udp -- 10.0.0.0/24 !10.0.0.0/24 masq ports: 1024-65535 MASQUERADE all -- 10.0.0.0/24 !10.0.0.0/24 MASQUERADE tcp -- 10.0.0.0/24 !10.0.0.0/24 masq ports: 1024-65535 MASQUERADE udp -- 10.0.0.0/24 !10.0.0.0/24 masq ports: 1024-65535 MASQUERADE all -- 10.0.0.0/24 !10.0.0.0/24 Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:3300 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:4333 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- 0.0.0.0/0 10.0.0.0/24 state RELATED,ESTABLISHED ACCEPT all -- 10.0.0.0/24 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable ACCEPT all -- 0.0.0.0/0 10.0.0.0/24 state NEW,RELATED,ESTABLISHED ACCEPT all -- 0.0.0.0/0 10.0.0.0/24 state RELATED,ESTABLISHED ACCEPT all -- 10.0.0.0/24 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT) target prot opt source destination

后

 Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE tcp -- 10.0.0.0/24 !10.0.0.0/24 masq ports: 1024-65535 MASQUERADE udp -- 10.0.0.0/24 !10.0.0.0/24 masq ports: 1024-65535 MASQUERADE all -- 10.0.0.0/24 !10.0.0.0/24 Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:3300 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:4333 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- 0.0.0.0/0 10.0.0.0/24 state NEW,RELATED,ESTABLISHED ACCEPT all -- 0.0.0.0/0 10.0.0.0/24 state RELATED,ESTABLISHED ACCEPT all -- 10.0.0.0/24 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT) target prot opt source destination

是否有机会在文件“/ etc / network / interfaces”中使用其他脚本“post-up iptables-restore </etc/iptables.up.rules”

我的虚拟机使用NATnetworking和由libvirt控制的虚拟networking，因此libvirt会尝试更改iptables规则，将正确的stream量发送到正确的虚拟机，但显然它不能正常工作。

基本上，libvirt在iptables已经加载它的configuration之后向iptables添加规则。

快速，肮脏的黑客

简单而实用：

 echo "service iptables restart" >> /etc/rc.d/rc.local

/etc/rc.d/rc.local将在所有其他init脚本之后执行。

其他选项（只是想法）

一个解决scheme可能是使用libvirt“钩子”脚本，可以用来做一个稍微好一点的工作（参见使用nat – iptables覆盖的libvirt和networking过滤）。
重做networking，所以它不使用NAT（这不是一个真正的解决scheme，它只是意味着改变服务器体系结构）。
更新服务器到CentOS 7（现在它使用CentOS 6）可能也有帮助（使用firewalld）。

任何帮助扩大这个答案更详细的解决scheme（步骤）或新的select将仍然赞赏。

感谢TrevorH和#centos（freenode）的人们的热心帮助。