在《華為防火墻產(chǎn)品一覽》中，強(qiáng)叔曾介紹：華為出品低、中、高端共三個(gè)系列防火墻，對(duì)應(yīng)當(dāng)前的主力產(chǎn)品型號(hào)分別為USG2000、USG5000和USG9000。<注>2013年8月發(fā)布了下一代防火墻USG6000系列，強(qiáng)叔后續(xù)針對(duì)性詳述。這三個(gè)系列產(chǎn)品毫無(wú)疑問(wèn)都基于狀態(tài)檢測(cè)與會(huì)話機(jī)制實(shí)現(xiàn)，但是中低端防火墻與高端防火墻在架構(gòu)實(shí)現(xiàn)上有些區(qū)別：中低端防火墻采用集中式架構(gòu)，高端防火墻采用分布式架構(gòu)，這使得它們?cè)趯?duì)報(bào)文處理的實(shí)現(xiàn)上，稍有不同。不過(guò)這個(gè)稍有不同并不影響主線，強(qiáng)叔的思路是單刀直入，先講大同的報(bào)文處理流程（同樣會(huì)話機(jī)制），再?gòu)?qiáng)調(diào)求同存異（架構(gòu)差異影響）。

華為大同：全系列狀態(tài)檢測(cè)防火墻報(bào)文處理流程

下面先以USG5500系列產(chǎn)品為例，梳理防火墻報(bào)文處理流程。 狀態(tài)檢測(cè)與會(huì)話機(jī)制是華為防火墻對(duì)報(bào)文處理的關(guān)鍵點(diǎn)：即防火墻收到報(bào)文后，何時(shí)、如何創(chuàng)建會(huì)話、命中會(huì)話表的報(bào)文被如何轉(zhuǎn)發(fā)。那么可以此關(guān)鍵點(diǎn)為界線延伸，我們將報(bào)文經(jīng)防火墻處理分為查詢會(huì)話表前、中、后三個(gè)階段，參見(jiàn)如下USG5500報(bào)文處理全景圖。友情提醒：圖很復(fù)雜，對(duì)三個(gè)階段有印象即可，重點(diǎn)看圖下的文字拆解吧。

我們來(lái)進(jìn)一步介紹下每個(gè)階段的目的和處理過(guò)程。 1、 查詢會(huì)話之前的處理過(guò)程：基礎(chǔ)處理。 這個(gè)階段的主要目的是解析出報(bào)文的幀頭部和IP報(bào)文頭部，并根據(jù)頭部當(dāng)中的信息進(jìn)行一些基礎(chǔ)的安全檢測(cè)（單包攻擊防范）。 2、 查詢會(huì)話的處理過(guò)程：轉(zhuǎn)發(fā)處理，關(guān)鍵是會(huì)話建立。 這個(gè)階段到了防火墻對(duì)報(bào)文轉(zhuǎn)發(fā)處理的核心。建立會(huì)話表，根據(jù)會(huì)話表轉(zhuǎn)發(fā)報(bào)文，是狀態(tài)檢測(cè)防火墻的精髓。此部分要梳理清楚思路，耗費(fèi)很多筆墨，還請(qǐng)小伙伴們耐心觀看。 報(bào)文到此階段，防火墻最先判斷該報(bào)文是否要?jiǎng)?chuàng)建會(huì)話。 1）OSPF、IGMP組播報(bào)文等一些協(xié)議報(bào)文是不創(chuàng)建會(huì)話的，那么這些報(bào)文就會(huì)去直接查路由和安全策略。 2）而TCP首包、UDP等報(bào)文都需要?jiǎng)?chuàng)建會(huì)話，那么判斷該報(bào)文要?jiǎng)?chuàng)建會(huì)話后，接下來(lái)馬上查詢會(huì)話表中是否已經(jīng)創(chuàng)建了該報(bào)文的會(huì)話。

A. 對(duì)于會(huì)話表中不存在匹配任一表項(xiàng)的報(bào)文，防火墻判斷該報(bào)文為某一流量的首包，進(jìn)行首包處理流程。

B. 對(duì)于會(huì)話表中存在匹配表項(xiàng)的報(bào)文，防火墻判斷該報(bào)文為某一流量的后續(xù)包，進(jìn)行后續(xù)包處理流程。

這也是強(qiáng)叔在《狀態(tài)檢測(cè)和會(huì)話機(jī)制》一節(jié)中提到的“為數(shù)據(jù)流的第一個(gè)報(bào)文建立會(huì)話，數(shù)據(jù)流內(nèi)的后續(xù)報(bào)文直接根據(jù)會(huì)話進(jìn)行轉(zhuǎn)發(fā)，提高了轉(zhuǎn)發(fā)效率?！?首包處理流程要點(diǎn)： （1）先使該報(bào)文與黑名單匹配，若報(bào)文源地址命中黑名單，則此報(bào)文被丟棄，不再繼續(xù)后續(xù)流程。 （2）查詢?cè)搱?bào)文是否命中正反向Server-map表，若報(bào)文命中Server-map表，記錄Server-map表中的信息。

（3）繼續(xù)根據(jù)（2）的記錄結(jié)果，查詢命中哪條路由，優(yōu)先查詢策略路由。若未命中策略路由，則查詢正向路由表，決定報(bào)文的下一跳和出接口。

? ? ? ? 這里說(shuō)明下：為什么要強(qiáng)調(diào)根據(jù)（2）的記錄結(jié)果呢？因?yàn)榇藭r(shí)報(bào)文未進(jìn)行實(shí)質(zhì)轉(zhuǎn)換，但查詢路由是使用虛擬出來(lái)的、命中Server-map表經(jīng)轉(zhuǎn)換后的報(bào)文查詢，這是為了最終經(jīng)過(guò)防火墻各種處理完畢的報(bào)文能夠正確轉(zhuǎn)發(fā)。

（4）查詢是否命中安全策略，已知報(bào)文入接口源地址、判斷出報(bào)文出接口后，可以查詢到該出入接口所在安全區(qū)域的安全策略配置，若報(bào)文沒(méi)有匹配到安全策略或匹配到安全策略中定義為“阻斷”的規(guī)則，則報(bào)文被丟棄，不再繼續(xù)后續(xù)流程；若報(bào)文匹配安全策略中定義為“允許”的規(guī)則，則繼續(xù)后續(xù)流程。 （5）查詢是否命中源NAT策略，若報(bào)文匹配到一條源NAT策略，則記錄NAT轉(zhuǎn)換后的源IP地址和端口信息。 （6）順利通過(guò)安全策略匹配檢查后，終于走到這一步：根據(jù)上述記錄結(jié)果，創(chuàng)建會(huì)話。

【文章福利】小編推薦自己的Linux內(nèi)核技術(shù)交流群:【891587639】整理了一些個(gè)人覺(jué)得比較好的學(xué)習(xí)書(shū)籍、視頻資料共享在群文件里面，有需要的可以自行添加哦！?。。ê曨l教程、電子書(shū)、實(shí)戰(zhàn)項(xiàng)目及代碼)? ? ??

后續(xù)包處理流程：

很簡(jiǎn)單，判斷會(huì)話是否需要刷新。當(dāng)為首包創(chuàng)建會(huì)話的各表項(xiàng)和策略（如路由表、安全策略）變化時(shí)，會(huì)話需要刷新。若需要?jiǎng)t繼續(xù)查詢路由、查詢安全策略，若不需要直接進(jìn)行后續(xù)階段處理。

總結(jié)：

強(qiáng)叔在開(kāi)篇中提到防火墻與路由器的區(qū)別，對(duì)于路由器來(lái)說(shuō)可說(shuō)是使出渾身解數(shù)（通過(guò)路由表）將報(bào)文轉(zhuǎn)發(fā)出去，而對(duì)于防火墻來(lái)說(shuō)要作為守護(hù)神堅(jiān)決阻擋非法報(bào)文（只有通過(guò)各種安全檢查建立會(huì)話表才可能被轉(zhuǎn)發(fā)）。所以防火墻丟棄一些報(bào)文是正常的處理流程，包括第一階段的解決IP報(bào)文頭、單包攻擊，第二階段的黑名單、安全策略，第三階段的UTM處理、限流等等，是報(bào)文的主要丟棄點(diǎn)。

進(jìn)行故障定位時(shí)，防火墻上是否創(chuàng)建了指定某條流量的會(huì)話，是定位要考慮的關(guān)鍵界線。若未創(chuàng)建會(huì)話，則考慮是報(bào)文是否到達(dá)設(shè)備、接口丟包、命中黑名單或安全策略、無(wú)路由、或NAT等配置出現(xiàn)問(wèn)題；而存在會(huì)話，則向后續(xù)的安全業(yè)務(wù)處理階段考慮。

3、查詢（或創(chuàng)建或刷新）會(huì)話的處理過(guò)程：進(jìn)行實(shí)質(zhì)各安全業(yè)務(wù)處理、及之后的報(bào)文去向。

報(bào)文在首包處理流程中經(jīng)一通查詢、創(chuàng)建會(huì)話后，就與后續(xù)包處理流程殊途同歸了，即都進(jìn)入第3階段。 此階段首先進(jìn)行基于IP的限流、IPS等UTM業(yè)務(wù)處理，報(bào)文順利通過(guò)檢查之后，到了實(shí)質(zhì)性的地址轉(zhuǎn)換：根據(jù)已創(chuàng)建的會(huì)話表，進(jìn)行目的地址轉(zhuǎn)換、源地址轉(zhuǎn)換。 這個(gè)目的地址轉(zhuǎn)換、源地址轉(zhuǎn)換對(duì)應(yīng)配置就是NAT Server、源NAT策略等NAT功能，對(duì)應(yīng)報(bào)文則是在第2階段首包流程中已經(jīng)經(jīng)過(guò)一通查詢并創(chuàng)建了會(huì)話表。 那么，如果想要在此階段能夠準(zhǔn)確地對(duì)報(bào)文進(jìn)行源地址轉(zhuǎn)換，有兩個(gè)常見(jiàn)的points需要關(guān)注：

一是報(bào)文在前面流程中是否命中了Server-map表，尤其是反向Server-map表，若已經(jīng)命中，那么報(bào)文會(huì)根據(jù)反向Servermap表進(jìn)行源地址轉(zhuǎn)換，不會(huì)再往后匹配源NAT策略了。

一是報(bào)文在后續(xù)流程中是否計(jì)劃要進(jìn)行×××加封裝，如果在此時(shí)定義該條數(shù)據(jù)流進(jìn)行了NAT轉(zhuǎn)換，那么后續(xù)就無(wú)法進(jìn)入×××協(xié)商流程了。

而按計(jì)劃進(jìn)行目的地址轉(zhuǎn)換問(wèn)題不大，一般是配置NAT Server，其報(bào)文處理優(yōu)先級(jí)很高，報(bào)文走入歧途可能性就小。

最后，該轉(zhuǎn)換轉(zhuǎn)換，該過(guò)濾過(guò)濾，一切安全業(yè)務(wù)流程順利通過(guò)后，報(bào)文終于到了分發(fā)十字路口： A. 如ping、OSPF等路由協(xié)議報(bào)文是要到防火墻本身，會(huì)被上送至管理層面處理； B. 如×××報(bào)文（防火墻為隧道終點(diǎn)，收到×××報(bào)文）就會(huì)被解封裝、并在解封裝后重走一次上述1、2、3流程； C. 如準(zhǔn)備進(jìn)入×××隧道的報(bào)文（防火墻為×××隧道起點(diǎn)）就會(huì)被進(jìn)行×××封裝等等。

求同存異：集中式與分布式防火墻差異對(duì)報(bào)文處理流程影響

防火墻大同的報(bào)文處理流程介紹完畢，我們來(lái)看一下集中式與分布式架構(gòu)的區(qū)別會(huì)導(dǎo)致哪些差異。

對(duì)于集中式低端防火墻，來(lái)往報(bào)文會(huì)被上送至一個(gè)集中的CPU模塊（可能由多個(gè)CPU組成）進(jìn)行處理。 集中式防火墻一般為盒式設(shè)備，可以插接多種擴(kuò)展接口卡，但設(shè)備的總機(jī)性能恒定，即取決于該設(shè)備配置的CPU模塊處理能力。上述介紹的USG5500產(chǎn)品報(bào)文處理流程即為其全部流程。

對(duì)于分布式高端防火墻，對(duì)報(bào)文的處理就會(huì)比較復(fù)雜，有多種情況，上述介紹的報(bào)文處理流程是其中一個(gè)最核心的子集—SPU板業(yè)務(wù)處理流程。

分布式防火墻一般為框式設(shè)備，以USG9000來(lái)說(shuō)，由兩塊標(biāo)配主控板MPU、交換網(wǎng)板SFU、接口板LPU、業(yè)務(wù)板SPU組成，其中LPU與SPU的槽位可混插，客戶按需購(gòu)買。相比集中式防火墻，分布式防火墻由各種單板組成，每種單板各司其責(zé)。

主控板MPU：主要負(fù)責(zé)系統(tǒng)的控制和管理工作，包括路由計(jì)算、設(shè)備管理和維護(hù)、設(shè)備監(jiān)控等。

交換網(wǎng)板SFU：主要負(fù)責(zé)各板之間數(shù)據(jù)交換。

接口板LPU：主要負(fù)責(zé)接收和發(fā)送報(bào)文，以及QoS處理等。

業(yè)務(wù)板SPU：主要負(fù)責(zé)防火墻的安全業(yè)務(wù)處理，包括安全策略、NAT、攻擊防范、×××等。設(shè)備總機(jī)性能隨插接SPU板的數(shù)量增加而線性增加，這是分布式防火墻的特性和價(jià)值所在。

那么我們來(lái)看一下，各類報(bào)文在分布式高端防火墻上是如何被處理的：

已經(jīng)提到①②是防火墻業(yè)務(wù)處理的核心，也正是防火墻的安全防護(hù)價(jià)值所在。③④多用于設(shè)備管理、定位故障；⑤⑥多用于網(wǎng)絡(luò)互聯(lián)如路由學(xué)習(xí)。

還有一個(gè)更復(fù)雜的問(wèn)題：當(dāng)一臺(tái)分布式防火墻配置多個(gè)業(yè)務(wù)板時(shí)，報(bào)文經(jīng)過(guò)接口板處理后，會(huì)被送至哪個(gè)業(yè)務(wù)板呢？如上圖中的①②③④報(bào)文都會(huì)經(jīng)業(yè)務(wù)板處理，那么會(huì)被送至SPU1還是SPU2呢？ 這時(shí)會(huì)有選擇“由哪塊SPU板進(jìn)行業(yè)務(wù)處理”的動(dòng)作，即USG9000產(chǎn)品文檔中提到的hash選板。默認(rèn)配置是根據(jù)報(bào)文的源+目地址經(jīng)過(guò)運(yùn)算選擇。----由于配置了多個(gè)SPU板，業(yè)務(wù)可能在防火墻多個(gè)業(yè)務(wù)板分別建立會(huì)話。 例如，以PC訪問(wèn)Web服務(wù)器來(lái)說(shuō)，假設(shè)PC發(fā)往Web服務(wù)器在業(yè)務(wù)板SPU1上建立了會(huì)話，而Web服務(wù)器的回應(yīng)報(bào)文可能會(huì)由業(yè)務(wù)板SPU2處理。一句話就是請(qǐng)求報(bào)文與回應(yīng)報(bào)文有可能被分配到防火墻的不同業(yè)務(wù)板處理。那么可能會(huì)產(chǎn)生一個(gè)問(wèn)題：由于請(qǐng)求報(bào)文基于業(yè)務(wù)板SPU1建立了會(huì)話，而回應(yīng)報(bào)文查不到反向會(huì)話被丟棄。實(shí)際上，USG9000在建立業(yè)務(wù)板的會(huì)話表時(shí)，同時(shí)會(huì)進(jìn)行hash預(yù)測(cè)，準(zhǔn)確預(yù)測(cè)回應(yīng)報(bào)文會(huì)被哪塊業(yè)務(wù)板處理，在該業(yè)務(wù)板上同步建立起一條反向會(huì)話，保證回應(yīng)報(bào)文能夠被正確轉(zhuǎn)發(fā)。當(dāng)然，正反向會(huì)話間會(huì)定時(shí)同步，保證同步老化、統(tǒng)計(jì)報(bào)文信息等等。

配置實(shí)例：與防火墻報(bào)文處理流程相關(guān)的配置技巧

下面我們以實(shí)例來(lái)說(shuō)明，熟悉防火墻報(bào)文處理流程，不需要再死記配置限制，而是根據(jù)邏輯直接判斷如何正確配置。 例1，當(dāng)安全策略遇上NAT Server。 在eNSP模擬器上，PC1（1.1.1.2）----防火墻USG5500----FTP服務(wù)器（192.168.1.2）簡(jiǎn)單組網(wǎng)，在防火墻上配置NAT Server，將FTP服務(wù)器地址轉(zhuǎn)化為與PC同一網(wǎng)段的地址，配置如下：

[USG5500] nat server 0 global 1.1.1.5 inside 192.168.1.2

若希望PC1及其他多個(gè)PC能且只能訪問(wèn)該FTP服務(wù)器，應(yīng)該如何配置嚴(yán)格的安全策略？實(shí)際是基于固定的目的地址配置安全策略問(wèn)題。

分析：根據(jù)防火墻報(bào)文處理流程，先進(jìn)行NAT Server轉(zhuǎn)換、查詢Server-Map表，再進(jìn)行安全策略處理。那么，該固定的目的地址，應(yīng)配置為該FTP服務(wù)器的真實(shí)地址（即inside地址）。

[USG5500] dis cu | include policy ? ? ? ? ? ? ? ? ? ? ? ? ?

policy interzone trust untrust inbound ? ? ? ? ? ? ? ? ? ? ?

policy 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

?policy destination 192.168.1.2 0.0.0.0 ? ?

驗(yàn)證如下： 1）關(guān)閉防火墻所有域間缺省包過(guò)濾，只保留上述在trust與untrust域間配置的該條安全策略。 2）在PC上訪問(wèn)FTP服務(wù)器，可以成功看到FTP服務(wù)器的文件列表。

3）查看防火墻USG5500會(huì)話表，可以看到FTP服務(wù)器已經(jīng)做了NAT Server，且FTP控制通道與數(shù)據(jù)通道均已建立。

結(jié)論：根據(jù)防火墻報(bào)文處理流程，先查詢Server-Map表，根據(jù)查詢的記錄結(jié)果再進(jìn)行安全策略處理。當(dāng)需求為允許多個(gè)外網(wǎng)客戶端訪問(wèn)經(jīng)過(guò)NAT Server轉(zhuǎn)換的服務(wù)器時(shí)，安全策略配置允許到達(dá)的目的地址為該服務(wù)器的內(nèi)網(wǎng)真實(shí)地址，而非NAT Server的global地址。

例2，當(dāng)源NAT遇上NAT Server。 某公司分部與總部互聯(lián)組網(wǎng)和關(guān)鍵配置如下，其中HTTP Server無(wú)法訪問(wèn)分部資源，而其他通信完全正常。

分析：防火墻上涉及HTTP Server的配置如下： ① NAT Server，將HTTP Server的私網(wǎng)192.168.1.2：80映射成為1.1.1.1：9980 ②源NAT，策略定義192.168.1.0網(wǎng)段去往分部不進(jìn)行源NAT轉(zhuǎn)換 查看防火墻的Server-map表：

NAT Server轉(zhuǎn)換成功，生成正反向Server-map表。且按照反向Server-map表含義，當(dāng)該HTTP Server主動(dòng)訪問(wèn)網(wǎng)絡(luò)時(shí)，亦進(jìn)行NAT Server轉(zhuǎn)換。根據(jù)防火墻報(bào)文處理流程，優(yōu)先查詢正反向Server-map表，命中反向Server-map表后，源NAT不再生效。這個(gè)問(wèn)題的解決辦法是，配置NAT Server時(shí)增加no-reverse參數(shù)，要求不生成反向Server-map表，這樣總可以繼續(xù)查詢NAT策略，使該HTTP Server可以正常訪問(wèn)分部資源。 結(jié)論：上述報(bào)文處理流程第3階段時(shí)已進(jìn)行提醒，進(jìn)行源NAT處理時(shí)，注意報(bào)文在前面流程中是否命中了Server-map表，尤其不要忽略反向Server-map表，如果已經(jīng)命中，此時(shí)源NAT處理不會(huì)再生效。

防火墻配置類問(wèn)題與報(bào)文處理流程相關(guān)的，可能還有很多，本文難以窮盡，只撿兩個(gè)實(shí)際常用NAT功能的例子拋磚，供小伙伴參考。本文筆墨頗多，邏輯難免有不嚴(yán)謹(jǐn)之處，請(qǐng)小伙伴琢磨指證。防火墻配置類問(wèn)題與報(bào)文處理流程相關(guān)的，可能還有很多，本文難以窮盡，只撿兩個(gè)實(shí)際常用NAT功能的例子拋磚，供小伙伴參考。本文筆墨頗多，邏輯難免有不嚴(yán)謹(jǐn)之處，請(qǐng)小伙伴琢磨指證。