Linux 内网与公网安全边界划分_网络技术_宿州市腾雀网络科技有限公司

不能按IP段粗暴划分内网/公网边界，因同一IP段混跑多类服务，仅靠地址无法判断流量合法性；必须基于业务角色分区，结合nftables链级隔离、cgroup标记、TLS双向认证、SELinux等实现细粒度控制，并通过Git审计、实时监控确保策略闭环。

直接用 192.168.0.0/16 当“内网”、0.0.0.0/0 当“公网”，是企业防火墙配置中最常见的逻辑漏洞。真实业务中，同一IP段可能混跑Web前端、管理后台、数据库代理，甚至容器化服

务；仅靠地址无法区分“该流量是否合法”。比如：DMZ区某台Nginx服务器若被攻陷，它用源IP伪装成应用区IP（如192.168.20.5）直连数据区，传统IP规则完全失效。

现代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跳转到其他链绕过该策略

容器环境里，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命令，而是让每条规则背后都有明确的业务归属、责任人和失效时间——否则再严密的分区设计，也会在一次临时调试中被绕过。