苹果测试工程师的日常今天有个需求是在防火墙上屏蔽一个指定地理范围的 IP，因为归属一个地区的 IP 列表总是在变化的，所以需要能在防火墙上实时更新规则 #ipset #iptables 虽然是已经该弃用的技术，但为了实现尽可能最大的兼容性还是尝试用它们实现了上面的需求 出乎意料的是，好像从来没有人提出过下面这些问题（至少我怎么都没搜索到）。干脆就自己动手测试出了答案，这里分享给大家： Q1: 使用 ipset 维护需要匹配的 IP 地址片段，当更新 ipset 时，真的需要重新加载 iptables 规则吗？ (Refer…
先来说下为什么会有这么扭曲的配置：
1. 为什么要把容器配置成主机网络，再去在 DOCKER-USER CHAIN 上添加防火墙规则？
因为以默认的网桥模式运行的话，容器就看不到传入连接的真实 IP 了。为了尽可能保证安全，容器实际上是通过 ports 的「长语法」模式，只在监听的端口上配置的主机网络模式。而且针对 sysctl/capabilities/user 都做了限制
---
然后说下我觉得还挺得意的设计：
iptables 的规则是通过一个脚本配置的，脚本实现了幂等性所以可以随时中断、重新执行
而脚本是通过 drop-in 配置写进了 docker.service 的 ExecStartPre 参数的，完全避免了进一步依赖 iptables-save 这样的工具去实现规则持久化；并且这也确保了在 docker 容器启动时防火墙规则一定已经就绪了
实现上面这套巧思几乎穷尽了我对 systemd 等工具的全部了解，我觉得把这些平时很少用到但其实很使用的参数和技巧分享出来会很有意思，希望有帮助到你 ;-)
1. 为什么要把容器配置成主机网络，再去在 DOCKER-USER CHAIN 上添加防火墙规则？
因为以默认的网桥模式运行的话，容器就看不到传入连接的真实 IP 了。为了尽可能保证安全，容器实际上是通过 ports 的「长语法」模式，只在监听的端口上配置的主机网络模式。而且针对 sysctl/capabilities/user 都做了限制
---
然后说下我觉得还挺得意的设计：
iptables 的规则是通过一个脚本配置的，脚本实现了幂等性所以可以随时中断、重新执行
而脚本是通过 drop-in 配置写进了 docker.service 的 ExecStartPre 参数的，完全避免了进一步依赖 iptables-save 这样的工具去实现规则持久化；并且这也确保了在 docker 容器启动时防火墙规则一定已经就绪了
实现上面这套巧思几乎穷尽了我对 systemd 等工具的全部了解，我觉得把这些平时很少用到但其实很使用的参数和技巧分享出来会很有意思，希望有帮助到你 ;-)
