再談會話
現在IP網絡里面離不開TCP、UDP這兩種傳輸層協議，主流應用都基于這兩種協議來做封裝傳輸，對于TCP來說，在發送實際數據的時候必須先建立可靠的連接，俗稱 ”三次握手”，而UDP則不需要建立連接，它有數據就直接發送出去。當然除了這些協議以外，網絡層用的比較多的ICMP、ESP、OSPF、BGP等協議，這就要求防火墻能夠分析各種協議的交互模式，能夠準確的識別并且建立會話信息，我們來了解了解這些常見主流協議的會話建立，對于后續排錯是很有幫助的。
對于TCP在防火墻上的會話建立
上面說過TCP的建立需要雙方進行三次會話交流，也就是“三次握手”的過程，我們來看防火墻是如何建立會話的。
對于一個正常的網絡構建TCP建立，首先進行三次握手
（1）Client發送SYN（序列號假設為a），防火墻收到這個報文后會檢查是否符合TCP協議規范，并且看安全策略是否允許該報文通過，通過后開始建立會話信息，并且實時關注后續的建立過程。
（2）服務器回應，發送SYN+ACK（seq=b，ack=a+1），其中ack用于確認已經收到來自于Client的SYN，表示已經收到了，服務器也會發送SYN來與Client進行建立同步會話，這里序列號為b
（3）防火墻收到這個報文后檢查會話表發現是來自于剛建立（1）會話表的同一個會話，直接允許通過，Client收到后，回應服務器一個ack（b+1），表示已經收到了，發送出去，防火墻發現整個TCP會話建立已經完成，會把TCP的狀態變成established，表示整個TCP建立完成，等待實際數據發送。
結合抓包跟狀態表查看就是
- （整體的配置與案例引用第五篇的配置）
首先Client 192.168.1.1往192.168.2.1發送SYS，seq=0，服務器收到后回應ACK1（對應Client發過來的SYN的seq=0+1），并且也同時發送一個SYN給客戶端seq=也是0，客戶端收到后直接回復ACK=1（對應服務器發送過來的SYN），最終會話建立，開始發送HTTP實際訪問。
總結：TCP連接的首發標志就是SYN報文，防火墻在狀態檢測開啟的情況下，在收到TCP的SYN首包情況并且安全策略允許的情況下就會創建會話信息。
對于UDP在防火墻上的會話建立
UDP對于TCP來說就簡單很多了，它是沒有連接狀態的協議，在防火墻上面的話則只要安全策略允許通過，則會直接創建會話信息。
對于ICMP在防火墻上的會話建立
ICMP的類型非常多，我們常用的比如ping、tracert都屬于ICMP范圍，ping的話有兩種主要的類型，一個是echo request（回顯請求報文）、一個是echo replay（回顯應答報文），在狀態開啟的情況下，防火墻收到來自于echo request（回顯請求報文），并且安全策略允許的情況下，就會建立會話，如果防火墻沒有收到ping的回顯請求，卻收到了ping的回應報文，那么會話是不會建立的，直接丟棄。
這里注意下，ICMP是網絡層協議，沒有端口號的，但是防火墻會把ICMP報頭中的序列號字段作為源端口號，以固定值2048作為會話的目的端口號。
異步路由導致來回路徑不一致的場景
正常情況下，數據包的來回路徑是保持一致的，這樣是很正常，但是也存在特殊的環境，比如跨運營商或者是網絡規劃以及配置上的失誤導致了來回路徑不一致的情況出現，那么出現了這種情況，會遇到什么樣的問題呢？（這個也是第五篇最后提的一個問題），我們來實際驗證下。
實驗拓撲根據自己想實驗難度的來搭建
難度一點的，這個環境實現其實比較簡單的，防火墻策略全放，然后寫靜態去往server1指向ISP2，而回Client的流量邊界指向ISP1，這樣就來回路徑不一致了，但是這個有點太繁瑣了，所以博主這里比較推薦大家用一個簡單點的拓撲。
PC去往服務器的時候直接通過路由器抵達，而返回的數據包，則路由器利用策略路由特性強制它交給防火墻，防火墻在寫192.168.1.1的路由指向10.1.1.1交給路由器，形成一個路徑不一致的環境，策略可以全放。（具體步驟就不在給出了，購買課程了的朋友可以直接看視頻講解，留言處有環境源文件提供，都可以直接參考）
實際測試下（分別抓取E0/0/1以及G1/0/0 10.1.2.2接口的包，這里圖上面顯示錯誤了，實際G1/0/0在上面 G1/0/1是下面的口）
首先客戶的發起訪問，這個結果肯定是失敗的。
可以發現，路由器上面能夠看到客戶端發起的SYN建立，以及服務器回應的SYN+ACK，而防火墻上面只收到了SYN+ACK。
這個時候數據轉發路徑與處理情況就是這樣
（1）Client1發起TCP首包SYN建立，交給路由器處理
（2）路由器查詢路由表直接丟給Server1
（3）Server1回應SYN+ACK，在路由器返回的時候，由于對接服務器的接口調用了策略路由，它會把這個數據包強制的交給10.1.2.2處理，這個時候防火墻收到后發現會話表并沒有存在該數據包的匹配信息，而且這個包不是TCP的首發SYN包，則直接丟棄。
導致這個丟棄的原因我們在上面已經深入了解了防火墻對于TCP建立會話的前提條件就是收到的包必須是首發SYN的包，而這里防火墻收到的是首發是SYN+ACK，那么防火墻則直接不予處理丟棄掉。那么在實際中真的遇到這樣的情況了，防火墻也是可以處理的，由于狀態檢測機制的存在，它會檢測各種協議的特征與是否規范，我們可以關閉這個功能，防火墻就不會對連接的狀態進行分析，就相當于包過濾的策略一樣，后續報文只要有安全策略允許，則直接通過。
[USG6000V1]undo firewall session link-state check ：關閉很簡單，一條命令搞定，這里博主提醒，關閉狀態檢測功能，防火墻就失去了它的魅力所在了，除非在一些特殊的環境，不建議關閉這個功能。
這個時候客戶端訪問成功了。
防火墻的會話表會發現，收到的為0，發出去的有數據，這是因為Client1發送的流量直接路由器轉發給服務器了，服務器回應的流量才經過防火墻，所以出現了這種特殊的狀況。
總結TCP/UDP/ICMP協議會話創建的情況
會話創建的情況包括開啟狀態檢測機制與關閉，上面TCP已經驗證完畢了，也可以趁著這個環境驗證下UDP與ICMP，博主就不在演示了，這里給出一個總結 。
建議大家可以在開啟與關閉下測試測試TCP、UDP、ICMP協議的情況，對于大家在學習狀態檢測、會話機制有很大的幫助，也為排錯提供了一個很好的思路。
博主經驗分享
在實際中如果遇到了特殊環境，確實需要關閉狀態檢測的情況下，但是關閉狀態檢測防火墻就回到了傳統的包過濾時代功能了，防火墻提供了一個非常好的功能，就是可以指定某些流量關閉狀態檢測，其余的保持不變。
#
acl number 3000
rule 5 permit ip source 192.168.2.1 0 destination 192.168.1.1 0
#
firewall session link-state exclude acl 3000
#
firewall session link-state check
可以看到這個功能就很實用，帶來的風險也不大，對于特定會話存在這種情況的，用ACL匹配出來，可以利用exclude來關閉狀態檢測，這樣的話對應ACL的不啟用狀態檢測，其余的還是會啟用。
WEB操作關閉狀態檢測
“承上啟下”
至此安全區域與狀態檢測就學習完畢了，但是里面涉及到安全策略是不是很陌生，那么它跟我們學習完的安全區域、狀態檢測會話有什么關聯呢？為什么在講解安全策略之前要先把這些講解完畢，下一篇我們就進入安全策略的內容。
介紹
《華為下一代USG防火墻（由淺入深實際案例系列）》是博主原創的針對華為廠商下一代USG防火墻組網系列應用部署為主的系列課程，結合實際環境出發，加上了博主部署經驗以及會遇到哪些問題等進行綜合，做到學以致用，給各位看官朋友一個不一樣的學習體驗。
如果大家有任何疑問或者文中有錯誤跟疏忽的地方，歡迎大家留言指出，博主看到后會第一時間修改，謝謝大家的支持，更多技術文章盡在網絡之路Blog，版權歸網絡之路Blog所有，原創不易，侵權必究，覺得有幫助的，關注、轉發、點贊支持下！~。
