您订阅的产品有更新，请实时查阅
查看详情您订阅的产品有更新，请实时查阅
查看详情
颁布功夫：2020-11-02
本文作者：阿昌
幼锐时时接到客户的反馈是，防火墙部署好了但是业务还是不通，往往束手无策。今天幼锐，不藏着掖着了，把珍藏多年的佳酿，故障幼窍门拿出来让喜欢幼锐的各人细品细品。
防火墙的安全查抄个性
网络源于生涯却又高于生涯，作为网络世界大门的鼎鼎台甫的“安全查抄官“下一代防火墙，有他自己特有的“安全属性”，遵守网络世界的“安全规定”，我们就能更好的在防火墙的故障排查过程中游刃有余。这些“安全属性”倒成了我们在执行防火墙过程中的“绊脚石”，固然排查故障过程是疾苦的，解决问题后的欢乐是始终铭刻值得回味的。
防火墙为了相信数据包是可信的，在收到数据包的时辰设置了两个“安全查抄点”：
1 反向蹊径查抄Reverse Path Forwarding (RPF)
2 异步查抄（asymroute，也就是各人常说的衔接齐全性查抄）
两项查抄只有都切合，才会持续其他？椴槌，不然直接抛弃数据包，那针对这两个查抄个性我们发展聊聊：
反向蹊径查抄
所谓反向蹊径查抄，单一举例，就是若是从内网口port31收到一个数据包，反向的回包必须从内网口port31回去，也就是要确保源进源出，反之以为此数据包为糊弄包执行抛弃作为。如果，防火墙收到数据包是src_addr_ip->dst_addr_ip为172.16.1.16->219.222.191.72，防火墙不会执行其他？椴槌ㄕ庑┠？榛嵘婕暗皆粗髡诺刂纷弧TM等），而是先执行反向蹊径查抄，凭据反向流量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[pc1->pc2]，这种数据包也是有问题的防火墙不会允许过的。
那可能各人会问幼锐，异步路由查抄能够关关吗，现实业务场景不建议关关的，做法是找到导致来回蹊径不一致的原因，将异步问题终结掉，由于防火墙关关异步查抄后，多链路出口的场景源进源出职能将不生效，代理防护类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%左右，真的是算上是爱说大真话的号令了，提醒什么原因通常故障就定位出来 了，是幼锐力荐需把握的号令，学会了就是把握了上乘武功了哦，一路建炼起来吧。
文档评价
