小銳常常接到客戶的反饋是，防火牆部署好了但是業務還是不通，往往束手無策。今天小銳，不藏着掖着了，把收藏多年的佳釀，故障小竅門拿出來讓喜歡小銳的大家細品細品。

防火牆的安全檢查特性

網絡源于生活卻又高于生活，作為網絡世界大門的鼎鼎大名的“安全檢查官“下一代防火牆，有他自己特有的“安全屬性”，遵守網絡世界的“安全規則”，我們就能更好的在防火牆的故障排查過程中遊刃有餘。這些“安全屬性”倒成了我們在實施防火牆過程中的“絆腳石”，雖然排查故障過程是痛苦的，但解決問題後的快樂是永遠銘記值得回味的。

防火牆為了相信數據包是可信的，在收到數據包的時候設置了兩個“安全檢查點”：

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%左右，真的是算上是愛說大實話的命令了，提示什麼原因一般故障就定位出來 了，是小銳力薦需掌握的命令，學會了就是掌握了上乘武功了哦，一起修煉起來吧。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!