不能按IP段粗暴划分内网/公网边界，因同一IP段混跑多类服务，仅靠地址无法判断流量合法性；必须基于业务角色分区，结合nftables链级隔离、cgroup标记、TLS双向认证、SELinux等实现细粒度控制，并通过Git审计、实时监控确保策略闭环。
为什么不能按IP段粗暴划分内网/公网边界
直接用 192.168.0.0/16 当“内网”、0.0.0.0/0 当“公网”，是企业防火墙配置中最常见的逻辑漏洞。真实业务中，同一IP段可能混跑Web前端、管理后台、数据库代理，甚至容器化服务；仅靠地址无法区分“该流量是否合法”。比如：DMZ区某台Nginx服务器若被攻陷，它用源IP伪装成应用区IP（如192.168.20.5）直连数据区，传统IP规则完全失效。
- 分区必须基于业务角色，而非物理位置或子网——DMZ只放API网关，应用区只跑微服务，数据区只响应白名单IP+指定端口的
mysql或redis连接 - 默认策略必须是
drop，不是accept；漏一条规则 = 隐式放行全部 - 禁止跨区绕行：不允许DMZ主机通过
SNAT把源IP改成应用区地址再访问数据区
nftables 实现分区间单向控制（非iptables兼容写法）
现代Linux发行版（如RHEL 9+/Ubuntu 22.04+）推荐用nftables替代iptables，语法更清晰、链级隔离更强。关键不是“加允许规则”，而是“建专用链+显式拒绝”。
- 先创建链：
nft add chain inet filter dmz_to_app { type filter hook forward priority 0 \; } - 只允许可信流量：
nft add rule inet filter dmz_to_app ip saddr 192.168.10.0/24 ip daddr 192.168.20.0/24 tcp dport 8080 accept - 记录越权尝试：
nft add rule inet filter dmz_to_app log prefix "BLOCKED_CROSS_ZONE" drop - 确保无旁路：检查
nft list ruleset中没有jump或goto跳转到其他链绕过该策略
光靠IP+端口不够：如何识别“真实服务身份”
容器环境里，192.168.20.10这台宿主机上可能同时运行订单服务、风控服务、日志采集器，它们共用同一个IP和端口范围。此时必须结合进程上下文做控制。
- 用cgroup标记容器：
nft add rule inet filter app_to_data meta cgroup /order tcp dport 3306 accept - 数据库连接启用TLS双向认证后，防火墙可配合
conntrack识别已验证会话，只对ct state established且带有效证书DN字段的连接放行 - SELinux限制进程网络能力：
semanage port -a -t http_port_t -p tcp 8080，再配合allow httpd_t database_port_t:tcp_socket name_connect策略，让Web进程根本无法发起数据库连接
规则不是写完就上线：必须闭环审计
生产环境中，一条没走Git评审的nft add rule命令，可能让核心数据库暴露在公网扫描下。策略变更必须可追溯、可回滚、可验证。
- 所有规则变更提交到Git仓库，提交信息强制包含：
原因（如“开放支付回调端口”）、影响范围（app区10台Pod）、回滚命令（nft delete rule inet filter app_to_dmz handle 123） - 用
nft monitor trace实时捕获匹配路径，验证规则是否真正在FORWARD链生效，而非被更早的raw/mangle链提前处理 - 定期执行
nft list ruleset | grep -E "(drop|reject)"确认无隐式放行，尤其检查OUTPUT链是否误开了accept导致内部横向渗透
真正难的不是写几条nft命令，而是让每条规则背后都有明确的业务归属、责任人和失效时间——否则再严密的分区设计，也会在一次临时调试中被绕过。
