内网居然用公网IP？没有NAT和DHCP，防火墙到底怎么配？

昨天发了一篇防火墙基础配置的文章后，收到一位读者小A的私信。他说自己遇到个“奇葩”网络：

“单位内网IP全是公网地址，没有NAT，没有DHCP。边界防火墙和服务器区内部防火墙，我不知道怎么划分区域，更不知道怎么设单双向策略。”

其实，这个问题一点也不“奇葩”，很多老牌单位、科研机构或专网环境，确实会这么规划。今天，我们就专门来解决这个“特殊”需求。

一、先看清“特殊”背后的本质

小A描述的环境有三个关键点：

1. 内网使用公网IP：比如直接用8.8.8.0/24、1.1.1.0/24（别笑，真有人这么用）。

2. 没有NAT：内网主机用公网IP直接上网，无需地址转换。

3. 没有DHCP：全是静态IP。

核心影响：防火墙不再能通过“IP是公网还是私有”来判断信任关系。区域划分必须完全基于“职能”，而不是“地址类型”。

二、如何重新界定防火墙区域？

放弃“内外网”思维，采用“业务区域”+“安全等级”模型。

边界防火墙（连接互联网与内网）

· 区域1：Untrust（外网）

运营商分配的互联网段，无信任可言。

· 区域2：Trust（内网客户端区）

办公电脑、员工终端所在网段。即使IP是公网，但它们是受管理的内部设备——安全等级设为高。

· 区域3：DMZ（对外服务区）

需要对外部（互联网）开放的服务，如Web、邮件服务器。等级中。

· 区域4：管理区（可选）

网管、堡垒机所在段。等级极高。

内部防火墙（服务器区与办公区间）

· 区域A：办公区（已过边界防火墙）

来自Trust区域的流量。

· 区域B：应用服务器区

跑业务逻辑的服务器。

· 区域C：数据库区

核心数据存储——等级最高，访问最严。

关键原则：区域不取决于IP是公是私，而取决于“这个网段里的设备是做什么的”。

三、没有NAT，安全策略怎么配？

没有NAT，意味着防火墙只做包过滤和状态检测，不做源地址转换。这反而让策略更直观。

1. 边界防火墙策略（以允许上网为例）

· 源区域：Trust（内网客户端区）

· 目的区域：Untrust（外网）

· 源地址：内网的公网IP段（如1.1.1.0/24）

· 目的地址：any

· 动作：允许

· 注意：由于没有NAT，这些公网IP必须在互联网全局路由可达（否则回包无法回来）。如果这些公网IP是单位自用、未在公网宣告，那么这台防火墙其实是在当“纯路由”用——此时要警惕地址冲突。

2. 内部防火墙策略（办公区→应用服务器）

· 场景：办公网访问业务系统（如OA，端口8080）

· 源区域：办公区，目的区域：应用区

· 动作：允许

· 同时考虑反向：服务器回包属于状态化防火墙自动允许，无需额外配置。

3. 最易错场景：应用服务器→数据库

这是典型的“单双向”困惑点。

· 需求：APP服务器需要读数据库（3306），但数据库不能主动连APP服务器。

· 正确策略：

源区域：应用区 → 目的区域：数据库区，只开放3306端口。

不需要配置反向策略，因为防火墙会跟踪会话。

但如果你担心反向流量被误拦，确保防火墙开启了asymmetric-path相关处理（大部分主流防火墙默认开启状态检测）。

一句话总结：需要双向通信的业务才配双向策略，大部分“请求-响应”模型，只需配单向发起方向的策略。

四、无DHCP静态环境下的配置小贴士

1. 地址对象化：把所有公网IP段提前定义为地址对象（如Office-Subnet、APP-Server-Subnet），避免写错。

2. 明确网关：防火墙内联口必须配置正确网关指向核心交换机；服务器、PC的网关指向防火墙或三层交换机。

3. 谨慎开启“地址冲突检测”：某些防火墙默认会检查内网IP是否为公网并告警，视情况关闭此告警或加入白名单。

4. 日志与排错：配置完成后，用debug或抓包查看“单向不通”时，重点检查路由是否有回程以及防火墙是否因非对称路径丢包。

五、给那位小伙伴的最终建议

1. 不要被“公网IP”吓到——它只是个标识。防火墙关心的是谁想访问谁、访问什么服务。

2. 画出数据流图：用箭头标出访问的发起方向，策略的源/目的区域自然就出来了。

3. 先通后优：先放行业务必要的最小权限策略，确认通信正常，再收紧。

4. 考虑长远：如果未来有与互联网真实公网IP对接的可能，建议逐步内网改用私有地址+NAT，避免路由冲突。现阶段“没有NAT”可能是历史原因，但不代表最优。

最后想说：网络上90%的防火墙配置教程，都是基于“内私有、外公网+NAT”的。当你遇到非典型环境时，请回归防火墙的本质——基于策略的、状态化的访问控制。剥离掉地址类型的思维定势，一切都清晰了。