网络策略误配导致的连通性故障，绝大多数情况下是五元组定义不完整或策略顺序优先级搞反了，从抓包和策略命中计数入手，能在几分钟内锁定问题边界,而不是盲目重启设备或反复改地址。
故障现象：明明是通的，怎么突然就不行了
某个下午，业务部门反馈新上线的财务系统无法访问，服务器能Ping通，但应用页面始终转圈，技术同事初步排查发现，服务器本机服务正常，监听端口也在，从服务器自己访问回环地址没问题,但跨网段客户端就是连不上。
这类场景是网络策略误配导致连通性故障的典型代表，它最迷惑人的地方在于，基础连通性没有被完全切断，ICMP能通，TCP握手却卡在中间某一步，多数情况下，不是设备坏了，也不是链路断了,而是中间某一层安全策略没有按预期放行流量。
从客户端ping服务器的结果看，丢包率是0，但用telnet测试端口时直接超时，这种异常组合基本可以排除物理链路和IP路由层面的问题，把焦点转移到防火墙、ACL或者云平台安全组上。
安全策略和网络策略的边界要分清
行业内常把防火墙策略叫安全策略，把路由策略、ACL、QoS叫网络策略，但在实际故障排查中，这两类配置经常混在一起生效，尤其是防火墙的域间策略和交换机上的VLAN ACL同时存在时,问题就变得棘手。
先看一张简化对比表,了解两类策略的执行差异：
| 策略类型 | 生效位置 | 匹配粒度 | 典型误配方式 |
|---|---|---|---|
| 防火墙安全策略 | 三层网关/边界 | 五元组、应用层 | 方向搞反、服务端口写错 |
| 交换机ACL | 二层/三层接口 | IP、MAC、TCP/UDP端口 | 隐式deny未注意、顺序冲突 |
| 云安全组 | 虚拟交换机 | 源IP、目的IP、端口 | 放行规则被优先级更高的拒绝规则覆盖 |
防火墙策略是有状态的，回程流量自动放行，而ACL一般是无状态的，即使在交换机上配了入方向放行，出方向没有对应规则，包也会在回程时被丢弃，这个机制差异,几乎一半以上策略误配故障的根因。
网络策略误配导致连通性故障排查步骤
既然判断与策略相关，就别急着改配置，按下面这套流程走一遍,九成问题能定位。
第一步：明确故障方向是单向还是双向
找两台设备，分别做双向测试，比如客户端A访问服务器B不通，那就从B反向访问A试试，如果反向通、正向不通，问题基本出在防火墙入方向策略或服务器侧ACL上，如果双向都不通，有可能是中间设备策略未放行,也可能是NAT映射后回程路由异常。
在实际操作中，直接在防火墙上用display security-policy rule查看策略命中次数，来判断流量是否被该策略接收，如果命中计数没有增长，说明流量根本没走到这条策略,方向或地址匹配有问题。
第二步：抓包对比SYN和SYN-ACK
在服务器网卡上抓包，同时在客户端侧抓包，如果客户端发出了SYN，服务器收到了，但服务器回的SYN-ACK客户端没收到，问题在回程路径安全策略，如果服务器根本没收到SYN，问题在入方向策略。
抓包时重点关注一个细节：帧的源MAC和目标MAC，有次我在华为USG防火墙上排查，发现服务器回包到防火墙后，防火墙没有做MAC重写就直接转发了，导致客户端收到无法识别的二层帧，查了半天，是防火墙接口下的IP地址配置和服务器不一致,流量走了兜底路由。
第三步：检查策略顺序和隐式规则
大多数防火墙安全策略是从上到下顺序匹配，即使你在后面配置了一条完全放行的规则，前面只要有一条deny any规则,后面的规则根本不生效。
这块需要登录设备命令行核对策略列表,以华为VRP系统为例：
display security-policy rule all
列表会按顺序展示当前所有规则，重点检查全局拒绝规则的位置，以及是否插在放行规则之前，类似的，思科ASA用show run access-list看全局ACL顺序。
第四步：验证NAT与策略的联动关系
源NAT和目的NAT往往和防火墙策略分开配置，但联调时容易出问题，如果做了DNAT映射，那么安全策略里的目的地址应该填写映射后的真实服务器IP，而不是公网IP，很多工程师直接在策略里放行公网IP,导致DNAT之后的包没有匹配到对应策略而被丢弃。
验证方法是抓取防火墙内网接口的报文，确认转换后是否在内网策略的放行范围内，华为USG可以用display firewall session table查看当前会话的NAT转换前后地址对。
两个真实场景复盘：策略误配是怎么发生的
安全策略服务对象端口类型写错
一个OA系统部署在DMZ区，对内开放端口8080，防火墙策略放了从内网到DMZ的TCP 8080，但应用实际用的是UDP 8080，客户端测试时显示连接建立失败,服务端日志里完全看不到连接记录。
在防火墙上抓包后发现，客户端发送的UDP报文到达防火墙但没有命中任何策略，最终被默认拒绝规则丢弃，排查过程中，整整花了半小时逐条核对策略，才发现服务对象里只有TCP选项,UDP协议没有被勾选。
这种问题很常见，尤其是开发人员和网络运维对端口协议认知不一致时，正确做法是先用display security-policy rule配合display firewall session table,快速确认哪种协议报文被丢弃。
全局deny规则排在了放行规则前面
另一家单位做全网ACL整改，在核心交换机VLANIF接口上配了入方向ACL，最后两条规则是deny ip any any和permit ip any any，按常规思路，应该deny在前permit在后,但那次配置恰好反了。
结果新办公区所有终端无法访问财务系统，但其他业务正常，原因在于：ACL是顺序匹配的，permit规则在前，绝大多数流量先被放行，但财务系统所在VLAN被一条中间位置的deny ip规则拦截了，这条规则的本意是禁止访客访问内网，但由于顺序靠前,误伤了合法流量。
排查时查看ACL命中计数，发现财务系统访问报文被一增到deny规则上，问题一目了然，这告诉我们，ACL顺序不只是影响生效，还直接影响故障定位难度，配置时应先梳理业务分类，放行规则按业务优先级从上到下排布,拒绝规则统一放到最后。
怎么从根上避免策略误配
网络策略误配的原因，大都不是操作者不会配，而是变更流程里缺了验证环节,以下是行业共识认为最有效的三道防线。
- 配置评审机制：所有策略变更至少提前一个工作日发起评审，由另一位工程师模拟验证地址段、端口、协议的准确性，特别是内网策略配置错误修复方案,评审时要明确回退步骤。
- 策略命中日志订阅：在防火墙上开启策略命中日志，针对新上线业务订阅对应策略的日志，观察24小时内是否有deny记录，如果deny数量大于0,直接导出日志看是哪些源地址被拦截。
- 自动化校验工具
：批量设备环境下，写脚本定期拉取设备配置，对比标准基线，比如用Python的Netmiko库登录设备,匹配策略中的目的端口是否在业务端口台账内。
从故障响应的角度看，手册里必须有一份网络策略误配导致连通性故障的应急预案，里面写清楚抓包命令模板、典型日志代号、回滚操作路径，因为真正出问题时,现场工程师往往只能记住一个命令。
设备无关的排查思路
不管你是用华为、思科、H3C还是深信服防火墙，底层原理一致，下面是三款主流设备的常用排查命令,方便直接对照使用：
| 设备平台 | 相关命令 | 用途 |
|---|---|---|
| 华为VRP | display security-policy rule |
查看安全策略顺序和启用状态 |
| 思科ASA | show run access-list |
查看ACL实际配置 |
| H3C | display acl all |
查看ACL明细 |
| 深信服AF | Web控制台-策略模块-命中计数 | 图形化查看策略命中 |
Q&A：关于网络策略误配的常见疑问
网络策略误配导致连通性故障是什么原因造成的
根本原因是安全策略里的匹配条件与实际网络流量特征不符，具体表现为源地址、目的地址、协议类型、端口号中至少一项配置有误，或策略匹配顺序被更早的一条规则拦截，部分场景下，NAT转换后的地址没有同步到策略中的目的地址,造成转换后报文无策略匹配而被丢弃。
怎么快速定位防火墙策略误配位置
先用抓包确认数据包到达哪一层设备，从客户端、防火墙、服务器三层分别抓包对比，如果防火墙接口上抓到的入方向报文有数据，但出方向没有，说明策略丢弃了入方向流量，再使用display firewall session table查看会话建立请求，若会话表无记录且没有deny日志,检查策略目的地址是否与NAT后地址一致。
交换机ACL和防火墙安全策略误配修复方式有何不同
交换机ACL修改后即时生效，需谨慎操作避免影响现网流量，一般先添加permit观察命中情况，再删除旧拒绝规则，防火墙安全策略修改后在会话老化后生效（默认约90秒），修改时需关注已有会话的重建，建议在业务低峰期变更,变更后立刻下载最新策略并检查接口配置一致性。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/641925.html
