Docker 快速验证保存 iptables 的转发策略

故事和事故

这里的故事都是来源于事故。当然处理好了是传说中的故事，处理不好就是惨痛的事故。

前言

接上回(Docker 快速验证 tomcat 单机多实例方案)，解决非 root 账号不能绑定80端口，采用的是iptables转发的解决办法.这只能是个临时方案：

root@SuSE11:/etc/sysconfig$ iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8081

这个方法有以下局限：

1. 重启服务器失效；
2. 重启防火墙失效： [root@tomcat7conf]# rcSuEfirewall2 restart
3. 每次都的申请 root 权限手工执行转发命令

背后的故事

当时投产时间紧任务重，直接就投了。终于在第三次投产前，生产迁移扩容，重启后，趴了。因为部署在异地，电话支持后异地没了下文。晚一点儿客户直接电话过来，要求彻底解决。

后来才知道这个命令失效了（为什么失效这里有故事，当然对运维来说就是事故：推测异地也是发现了这个结果，没辙了就给本地客户反馈，压力就到项目组来了）。

第二天，客户建议在开发环境验证：先把防火墙关了看看行不行得通。虽然知道关了也不可能突然80就能被非root用户绑定了，但是还是安排工程师做了。一验证，出事了。防火墙关了之后，再也起不起来了（重启后，转发命令失效了）。咦~，有好戏了。

反复查证之后，推测是客户运营部门在这个时间段内，出于某种考虑，逐个排查，“彻底”关闭了所有服务器的防火墙：因为是规定。我们开发环境一直没重启，所以，转发规则一直生效。现在被循循善诱主动关闭防火墙验证时，新的策略生效，防火墙趴了，转发命令当仁不让失效了。

查证和推测过程以及解决方案如下，请各位参考。为什么推测，因为有些事情拿不到台面上，知道就好了，不必好为人师。尤其面对客户语焉不详时，给出解决方案就是了。大家心知肚明：乙方么，就是解决问题的。不管这个问题源头在哪儿，反正你的项目你碰上了，自己解决就是。

理论指导实践

SuSE 11 Linux 中，使用 /etc/sysconfig/SuSEfirewall2 脚本来“简化” iptables 策略的构建。系统启动时，通过加载此脚本，来生成 iptables 策略。

还原和推测现场

工程师的验证

大致也就这几个命令，最终结果就是，关闭了，验证80端口仍旧不能访问。再启动ÿ