背景
最近公司有一个项目进入了上线前的漏洞扫描阶段，大家本来是自信满满，结果安全测试团队提交的报告，整个项目有120多个安全漏洞，中高危的几乎到了2/3，自然要进行漏洞修复，拿到扫描报告，对所有的漏洞进行统计，发现WEB端端漏洞居多，主要是这个项目的建设团队来自于公司的各个部门，好多功能都做了微服务开发，功能之间以接口进行数据交互，所以，一个项目扫出8个nginx的漏洞，50多个Python的安全漏洞（基于flask的服务居多），项目工期紧，如果一个一个修复这些bug可能赶不上，所以有大佬提出：既然这些接口有bug，那么我们通过防火墙做限制，限制只能对应的业务服务器可以访问不久可以了吗？......”所以，作为项目组中的双（职）花（业）红（地）棍（层），自然进行操作。
选定了服务器A，B为了测试效果，编写了socket服务（python开发这样的小功能贼六），然后在A上面添加iptables规则，限制只有b可以访问这个端口:
iptables -A INPUT -s 192.168.1.1 -p tcp --dport 9999 -j ACCEPT
公司的业务，ip就自己拟定了，然后，使用其他服务器访问A上的soccet服务，没有任何问题，使用B服务器访问也没有问题，揉了揉眼，命令没有问题啊，这个时候隔壁的老哥瞟了我一眼：“要不重启一下iptables？”，我恍然大悟，马上动手。然后，背后工位的老哥一声惨叫：“等等，我去........”，背后工位的老哥正在测试服务器上使用docker部署一个服务，结果，docker容器间马上断掉，尝试重启docker，由于网络原因已经彻底起不来了........。
原因
发生了这样的事情，背后的老哥第一个就找到了我，我自然要和他说明（甩）白（锅），但是，老哥毫不客气，甩过一个博客链接：“你看看，就是重启iptables导致的，重启docker服务就可以了，但是这台服务器上有很多运行的docker容器，重启docker就交给你了”。打开老哥发过来的博客看了一遍，也不好意思说啥了，坦（灰）荡（溜）荡（溜）的找台账去拉起各个docker容器去了，但是，还是想把这里的原因分享给大家：
首先说，这是一个重大的问题，因为重启iptables导致整个服务器上所有的容器的网络都不通了，原因也很简单，iptables处于内核上，一直是运行的状态，当执行systemctl restart iptables的时候，并没有真正的重启iptables，而是再从新加载iptbles的规则，要知道docker容器本身是没有系统内核的，使用的是宿主机的内核，所以docker引擎也会把防火墙规则写到宿主机的iptables规则当中，当systemctl restart iptables重载的时候，会清除iptables链，也就是把docker引擎创建的规则清除掉了，自然，所有的容器也就不通了。
解决的方案也很简单，从起docker服务，docker引擎会从新添加iptables规则到iptables链上。也就好了，但是，如果是公司服务器或者线上环境，重启docker带来的风险很大（这次感谢各位大佬的台账写的比较牛皮，要不然........）
反思
服务确实是恢复了，但经此一事，也又了一些思考：
1、终于又体会到了一个云服务器安全组策略的优势，如果这个项目起初，对项目所有服务器的防火墙进入启动状态，进行申请管理，类似云服务器的安全组策略，那个服务需要开启端口，申请那个端口，那么今天的事情就不会发生了。
2、下午请教一个老大哥，好像firewall没有这个问题，可以琢磨琢磨使用firewall，当然这个思路还没有测试，欢迎有经验的大佬多多指点。
3、在重启像是防火墙一类的全局服务的时候，一定，一定，一定（重要的事情说三次）要和所有人沟通，要不然......
关于iptables导致的docker容器问题先总结道这里，希望可以帮到大家，也请各位大佬多多指点。
