这些防火墙命令都爱说大实话，让排障少走弯路 |运维实战家
本文作者：阿昌
小锐常常接到客户的反馈是，防火墙部署好了但是业务还是不通，往往束手无策。今天小锐，不藏着掖着了，把收藏多年的佳酿，故障小窍门拿出来让喜欢小锐的大家细品细品。
防火墙的安全检查特性
网络源于生活却又高于生活，作为网络世界大门的鼎鼎大名的“安全检查官“下一代防火墙，有他自己特有的“安全属性”，遵守网络世界的“安全规则”，我们就能更好的在防火墙的故障排查过程中游刃有余。这些“安全属性”倒成了我们在实施防火墙过程中的“绊脚石”，虽然排查故障过程是痛苦的，解决问题后的快乐是永远铭记值得回味的。
防火墙为了相信数据包是可信的，在收到数据包的时候设置了两个“安全检查点”：
1
反向路径检查Reverse Path Forwarding (RPF)
2
异步检查（asymroute，也就是大家常说的连接完整性检查）
两项检查只有都符合，才会继续其他模块检查，否则直接丢弃数据包，那针对这两个检查特性我们展开聊聊：
反向路径检查
所谓反向路径检查，简单举例，就是如果从内网口port31收到一个数据包，反向的回包必须从内网口port31回去，也就是要确保源进源出，反之认为此数据包为欺骗包执行丢弃动作。假设，防火墙收到数据包是src_addr_ip->dst_addr_ip为172.16.1.16->219.222.191.72，防火墙不会执行其他模块检查（这些模块会涉及到源目的地址转换、UTM等），而是先执行反向路径检查，根据反向流量219.222.191.72->172.16.1.16，在查找路由表后如果也是从port31出去的，说明流量是正常的，继续处理其他模块检查；如果存在另一个路由通路比如从port32出去或者甚至没有查找到相应路由，这个将导致反向路径检查失败防火墙执行丢弃动作。
使用debug flow抓包命令，会发现有个提示为：reverse path check fail, drop，特别显眼，这个提示就是因反向路径检查失败直接执行了丢弃动作了，这种情况建议是查一下防火墙上的路由配置问题。
异步路由检查
所谓异步路由检查，就是要确保来回路径要一致，保证数据连接的完整性。如：tcp的三次握手的数据包都要过防火墙，正常的tcp三次握手交互过程如下：
如果出现来回路径不一致的情况，防火墙认为报文有问题直接丢弃。
小锐现在就说说这流量转发哪里出现问题了，从流量转发来看PC1访问服务器的流量tcp syn报文转发路径是
PC1->RouterA->NGFW->RouterB->internet->Server，回包syn+ack的转发路径是Internet>RouterB>RouterA->PC1，未经过防火墙，ack报文PC1->RouterA->NGFW(丢弃报文不转发)，防火墙发现会话状态不完整（我没有看到syn+ack,我不信任你），执行丢弃动作。
使用debug flow命令对数据流分析一般会提示为：“org dir, ack in state syn_sent, drop”
当然这里还有更为奇葩的数据转发路径，如果是syn包转发路径不过防火墙，syn+ack的回复报文经过防火墙，这种情况下防火墙是无法找到对应的会话（我没有看到syn，我压根就没有你的会话），直接丢弃，这种也属于异步路由的一种特殊场景。使用debug flow抓包命令，会发现有个提示为：“no session matched”。
还有一种就是来回的二层mac不一致问题也是异步路由检查的一种特例了，一般这种场景常见于防火墙透明模式部署的时候。也就是如果过防火墙的数据包是mac1->mac2[pc1->pc2]，回包的时候是mac3->mac1[pc2->pc1]，这种数据包也是有问题的防火墙不会允许过的。
那可能大家会问小锐，异步路由检查可以关闭吗，实际业务场景不建议关闭的，最好的做法是找到导致来回路径不一致的原因，将异步问题终结掉，因为防火墙关闭异步检查后，多链路出口的场景源进源出功能将不生效，代理防护类utm功能将无法正常工作。
方法是：
#config system settings
#set asymroute enable
#end
此命令就是允许防火墙存在异步，这样防火墙可以不检查数据包的连接完整性了。
#config system settings
#set tcp-session-without-syn enable (默认disable)
#end
此命令是告诉防火墙如果不是syn的报文一样也可以创建会话。
数据包穿越防火墙处理过程详解
正常的数据包穿越防火墙，需要经过哪些过程呢？可以通过debug flow命令查看整个完整过程。
#diagnose debug enable //开启debug
#diagnose debug flow show console enable //启用debug flow显示打印，有些版本不需要敲
#diagnose debug flow show function-name enable //显示debug flow 功能名称，便于打印信息输出，有些版本可以不用敲
#diagnose debug flow filter addr 192.168.1.110 //过滤条件，避免抓包无用信息过多，这里过滤地址，filter ？可以查看过滤哪些条件
#diagnose debug flow trace start 100 //开始抓100条数据流
下面是数据包穿越防火墙的全部过程，我们一起来看看
id=36871 trace_id=1 msg="vd-root received a packet(proto=6, 192.168.
1.110:51661->119.253.62.131:80) from internal. "id=36871 trace_id=1 msg="allocate a new session-00016920" //internal口收到数据，建立新会话
id=36871 trace_id=1 msg="find a route: gw-192.168.118.1 via wan1" //查找到路由表
id=36871 trace_id=1 msg="find SNAT: IP-192.168.118.28, port-43333" //检测存在NAT配置
id=36871 trace_id=1 msg="Allowed by Policy-1: SNAT" //匹配策略,ID1
id=36871 trace_id=1 msg="SNAT 192.168.1.110->192.168.118.28:43333"//做NAT
id=36871 trace_id=3 msg="vd-root received a packet(proto=6,
119.253.62.131:80->192.168.118.28:43333) from wan1." // Wan1口收到返回数据包
id=36871 trace_id=3 msg="Find an existing session, id-00016920, reply direction" //数据包匹配会话id-0001692
id=36871 trace_id=3 msg="DNAT 192.168.118.28:43333->192.168.1.110:51661" //做反向的DNAT
id=36871 trace_id=3 msg="find a route: gw-192.168.1.110 via internal" //查找路由，发送到internal口
id=36871 trace_id=5 msg="vd-root received a
packet(proto=6,192.168.1.110:51661->119.253.62.131:80) frominternal." //internal口收到后续数据包
id=36871 trace_id=5 msg="Find an existing session, id-00016920, original direction" //匹配会话id-0001692
id=36871 trace_id=5 msg="enter fast path" //直接转发
id=36871 trace_id=5 msg="SNAT 192.168.1.110->192.168.118.28:43333" //NAT
抓完数据流后可以通过以下命令关闭。
#diagnose debug flow trace stop //停止
#diagnose debug disable //关闭
#diagnose debug reset //重置
#diagnose debug flow filter clear //可以清空debug的过滤条件设置
通过debug flow命令我们可以看到一个数据包流入防火墙后，各个模块的详细处理情况，整理成数据包处理流程图如下：
下面也一并介绍一些小锐常常遇到的debug flow关键信息提示，现总结如下：
如果是策略拒绝了数据包访问，会看到“Denied by forward policy check”，需要重点确认是否是安全策略拦截所致。
如果无法正常管理防火墙的时候，debug flow往往会出现提示，msg="iprope_in_check() check failed, drop"，一般会有下列三种可能原因所致：
1、当访问NGFW进行远程管理（ping, telnet, ssh ...）时，正在访问的服务未在接口上启用。
2、当访问NGFW进行远程管理时（ping, telnet, ssh ...），正在访问的服务在接口上启用，但是配置了受信任的主机，这些主机与入站数据包的源IP不匹配；
3、当通过同一NGFW的另一个接口访问用于远程管理的NGFW接口（ping，telnet，ssh ...）时，不存在防火墙策略。
策略动作拒绝,或命中隐含策略, 数据包被拒绝，一般会提示：msg="Denied by forward policy check"
如果涉及ALG相关会话（这类流量一般是动态多通道协议如ftp、sip等，此类协议较复杂，小锐下次再跟大家分享，嘻嘻）将送至 session-helper 模块处理，一般会提示：msg="run helper-ftp(dir=original)"
看到这里，小锐相信您也和小锐一样get 了不少防火墙的抓包命令了吧？那么接下来我们继续深入看下进阶版案例分析吧。
进阶案例展示一下命令有多么神奇^-^
现场反馈的拓扑简单描述如下：
全新下一代防火墙做端口映射，部分ISP专网IP访问端口映射的业务不通。基础的配置检查也没有看出问题所在，那接下来使用强大的debug flow对其数据流进行捕获，在信息输出中发现防火墙本地回复了RST报文（也就是图中的...from local. flag [R]），这点甚是可疑，说明问题还是出在防火墙的哪个模块处理环节上。
那我们一起开动脑筋思考一下什么情况下防火墙会主动发送RST包？
从数据包转发上我们注意到tcp syn将通过防火墙，但是当接收到tcp syn / ack时，NGFW会将tcp rst发送回tcp syn / ack的始发者。
即使存在允许流量通过NGFW的策略，配置错误的IPpool或VIP[l7] 也会为TCP连接造成连接问题。（名词解释：这里的ippool一般是用在上网做源地址转换的时候，一个地址不够用，可以把内网的源地址转换成一个地址段范围内的地址，VIP是防火墙的端口映射，也就是大家常说的目的地址转换关系）
一般这种问题的可能性是：本地有相应的IP地址（比如是源地址）了，因为没有对应的服务在监听，会去响应RST报文，按照这种排查思路去检查配置。
那我们把问题点锁定在IPPool或VIP上重点排查，通过配置查看找到了这个始作俑者。将对应错误的策略配置删除问题解决。
经确认现场源地址10.85.40.3也加到了虚拟ip映射里了。对于防火墙配置不太熟悉的往往可能会出现这种奇怪的配置，有时候策略一多真的用肉眼很不好看出问题出在哪儿。
一般出现防火墙回复...from local. flag [R]的情况有如下三种:
1、将服务器地址配置到了IPpool里；
2、将客户端IP地址配置到了IPpool里；
3、将客户端IP地址配置到了VIP里。
总结
Debug flow命令是防火墙实施部署过程中使用频率极高，而且故障诊断问题定位率可达80%左右，真的是算上是爱说大实话的命令了，提示什么原因一般故障就定位出来 了，是小锐力荐需掌握的命令，学会了就是掌握了上乘武功了哦，一起修炼起来吧。
相关阅读