華為USG系列防火墻雙向NAT處理流程（外聯區場景）
最近公司將外聯區防火墻從已經服役了10年的Juniper Netscreen替換成了華為的USG系列。在這里不得不再佩服一下netscreen系列防火墻的穩定性，公司之前有好幾套netscreen系列的墻，10年來只重啟過兩次并且沒有出過任何問題，在當年一眾防火墻產品里我認為是很無敵的很好用的存在。可惜被Juniper收購后現在已經成為了歷史，在我們公司這也同樣即將成為歷史了。
進入正題，這次實施防火墻替換的網絡區域是外聯區，即專門用于對接第三方合作伙伴的區域。由于我們是金融機構，對于與合作伙伴外聯對接在金融行業的做法通常就是需要做雙向NAT，即一個訪問請求源地址要轉換，目的地址也需要轉換。我們的做法是將NAT功能放在防火墻上做，畢竟路由器等其他設備并沒有防火墻那么強的NAT能力。
在替換為華為USG防火墻之前對它的處理機制不是完全清楚，畢竟每個廠家處理的機制各不相同。但為了日后運維的時候能夠快速排錯還是有必要搞清楚其中的NAT轉發處理流程的，以下是查看官網文檔后梳理后的理解。
外聯區組網拓撲
首先講講為何金融機構外聯訪問通常需要做雙向NAT。在兩個機構之間通常都是用專線進行對接，比如我方發起請求訪問對方的場景，我方的源服務器IP地址在出局后，會做源NAT將我方服務器IP映射成另外一個IP，目的是為了隱藏內部真實IP，是從安全性角度考慮。另外會把對方服務器IP在內部做一個目的NAT，在內部源服務器發起的請求是訪問這個映射后的IP，而不是訪問對方真實的IP，主要目的是對方的IP網段可能跟內部網段會有沖突，因此在將外部地址引入進內部網絡前，將這個IP地址轉換成內部規劃好的網段，就可以避免此問題，同時在內部一看這個請求的目標地址就可以很清晰的知道是屬于外部網絡。
以下是簡化后的外聯區拓撲，我也會基于以下模擬的組網進行整個請求及NAT處理流程的講解。
NAT轉換關系
華為USG系列NAT處理流程
下圖是截取自華為官網的手冊，關于NAT的處理流程。
1) 當請求的流量進入USG防火墻的入接口后，防火墻會查找目的NAT轉換表，匹配請求的目的地址是否需要轉換；
2) 如果命中轉換條目，目的地址會被轉換，不命中將會直接送到下一個流程；
3) 查找路由表，如命中路由表條目則送到下一個流程，路由表沒匹配將會被丟棄；
4) 接下來會送到安全策略里面檢查，如果檢查匹配安全策略的permit條目，則被放行進入下一個流程，否則請求將會被丟棄（安全策略需要配置業務流量最開始的源IP地址和最終的目的IP地址）；
5) 匹配源NAT轉換表，如果命中則會對源地址進行轉換并創建會話表，否則不進行轉換直接創建會話表；
6) 流量從出接口送出。
模擬場景轉發流程
根據以上對華為USG系列防火墻的NAT處理流程，以及結合以上外聯區模擬環境的拓撲，我們再來看看整個做了雙向NAT后的轉發過程。
華為USG防火墻主要配置我列一下出來：
ip route-static 172.16.0.10 255.255.255.255 1.1.1.2 description EXT_Route //根據處理流程，外部地址的路由需要寫成對方真實的IP
ip route-static 10.0.0.0 255.255.255.0 2.1.1.2 description INT_Route //內部DMZ區網段路由
#
//源目轉換可以寫在一條NAT策略里，NAT轉換的地址池需要預先定義
nat-policy
rule name DMZ_EXT_01
source-zone dmz
source-address address-set 10.0.0.10/32
destination-address address-set 192.168.200.10/32
action source-nat address-group Pool_192.168.100.10
action destination-nat static address-to-address address-group Pool_172.16.0.10
#
//安全策略放行
security-policy
rule name DMZ_EXT_01
description NAT(DMZ_EXT_01)
source-zone dmz
destination-zone untrust
source-address address-set 10.0.0.10/32
destination-address 172.16.0.10 mask 255.255.255.255
service https
service icmp
action permit
整個請求及NAT轉換過程如下：
內部服務器發起請求
到達防火墻進行目的NAT轉換，匹配安全策略并查找路由表
進行源NAT轉換，流量送出給合作伙伴
如果是反過來，由對方發起請求到內部服務器，其實整個處理流程也是一樣的，這里就不再贅述。
