网络隔离策略故障排查实用指南

网络隔离为何突然失灵

前两天朋友老张打电话来抱怨，公司内部系统莫名其妙打不开了。他们明明设置了严格的网络隔离策略，只允许特定部门访问某些服务器，结果财务部的电脑却连不上报销系统。听起来像是策略没生效，其实问题往往出在细节上。

网络隔离不是设完规则就一劳永逸的事。一旦出现访问异常，就得一步步查到底层配置有没有冲突，防火墙规则是否正确应用，甚至设备本身有没有同步更新。

先看策略是否真正生效

很多人以为在管理界面点个“启用”就算完成了，但实际策略可能根本没有推送到底层设备。比如用的是基于VLAN的隔离，交换机端口划分错了，那再多的策略也只是纸上谈兵。

可以登录核心交换机或防火墙，查看当前运行配置中是否有对应的ACL（访问控制列表）。比如Cisco设备上执行：

show running-config | section access-list

如果发现策略没出现在运行配置里，说明可能是配置未保存或者推送失败。

检查子网与路由路径

有时候两台本该隔离的主机能通信，是因为它们通过另一条路由绕了过去。比如A和B在不同VLAN，按理不能互通，但如果中间有台双网卡服务器充当了“软路由器”，就可能把流量偷偷转发了。

这时候可以用traceroute看看实际路径：

tracert 192.168.10.50

如果发现数据包经过了不该出现的跳点，就得去查那台设备有没有开启IP转发功能。Linux系统可以通过以下命令确认：

sysctl net.ipv4.ip_forward

返回1就说明转发是开着的，这可能是意外打通隔离的元凶。

防火墙规则顺序很重要

防火墙读规则是从上往下匹配，一旦命中就停止。所以即使你在最后写了一条“拒绝所有”的规则，但如果前面有一条宽泛的“允许内网互访”，那隔离策略就会被提前放行。

举个例子，下面这条规则如果放在隔离策略之前：

allow from 192.168.0.0/16 to any

那么后续针对特定网段的deny规则就根本不会被执行。调整顺序，把精确控制的规则往前移，才能确保隔离有效。

日志别光看着，要会查

很多单位配了日志系统，但从没人去看。真出问题时，翻日志才发现关键时间段有大量“策略拒绝”记录。这些信息能帮你定位到底是哪个IP在尝试越界访问。

比如在FortiGate防火墙上，可以执行：

diagnose firewall packet-filter src-ip 192.168.20.30

实时抓包过滤，看这个IP发出的数据是否被正确拦截。如果发现它居然通过了，就得回过头检查策略条件有没有写错掩码或者端口。

测试环境先模拟，别直接改生产

曾经有家公司运维小李急着解决问题，直接在生产防火墙上删了条规则，结果整个研发部断网半小时。后来查清楚才发现，那条看似多余的规则其实是隔离策略的关键一环。

正确的做法是先在测试环境复现网络结构，用相同策略做验证。比如用GNS3或Packet Tracer搭个小型拓扑，模拟客户端访问过程，确认策略行为符合预期再上线。

网络隔离不是贴张封条就完事，而是一套持续维护的机制。每次变更后都要重新验证通断性，定期审计规则有效性，才能避免某天突然发现“怎么又通了”这种尴尬局面。