發布時間：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，防火墻不會執行其他模塊檢查（這些模塊會涉及到源目的地址轉換、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[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%左右，真的是算上是愛說大實話的命令了，提示什么原因一般故障就定位出來 了，是小銳力薦需掌握的命令，學會了就是掌握了上乘武功了哦，一起修煉起來吧。
文檔評價
