拓撲
拓撲可以儲存到本地，然後擴大檢視，這樣才能看的更清楚。（拖動到新視窗打開即可）
NAT Server測試
說明：之前部署了NAT Server功能，并且轉換了2個位址，提供了對應WWW服務與FTP服務。目前用外網進行測試。
内網測試是否能正常通路
說明：可以看到2個服務都已經正常了。
外網PC通路對應服務【電信】
防火牆是有對應的NAT會話資訊了，
WEB正常 FTP通路不了
外網PC通路對應服務【網通】
還是以公網位址充當外網通路的角色。
一樣無法打開。
問題：為什麼HTTP可以通路，而FTP卻通路失敗。
說明：因為HTTP是單信道協定，而FTP則是多信道協定，而分為主動與被動模式，它會根據不同的模式在應用層動态的協商一個端口号與位址，是以導緻NAT後，位址變化了，但是應用層的位址防火牆沒有感覺到，導緻通路失敗。
解決辦法：【開啟應用層網關功能 ALG】
[USG-GW]firewall interzone trust isp_dx
[USG-GW-interzone-trust-isp_dx]detect ftp
[USG-GW]firewall interzone trust isp_lt
[USG-GW-interzone-trust-isp_lt]detect ftp
說明：該配置就是開啟了應用層網關功能，在trust到2個ISP之間。注意這個不區分方向的 雙向開啟。
可以看到開啟後，2個位址都可以正常通路了。
擴充：如果映射了PPTP伺服器的話，也會出現問題。
說明：PPTP伺服器除了映射端口号以外，它還會封裝GRE，如果不是一對一的轉換，則會出現問題，是以解決辦法還是跟上面一樣，在裡面監控PPTP即可。
工程中常見問題：如何使用公網IP或者域名通路内部伺服器。
說明：在工作當中，往往需要通路伺服器，并且又對外提供了服務，這樣的話，會讓客戶記住2個IP，一個内網通路的，一個外網通路的，這樣非常不友善，也對于不懂IT技術的人來說不可行。是以我們希望的是，通過外網IP或者域名直接通路。
預設情況下用内網位址通路是沒任何問題的。
解決辦法【域内NAT】
1、定義位址池
[USG-GW]nat address-group 5 200.1.1.1 200.1.1.1
2、定義域内NAT
[USG-GW]nat-policy zone trust
說明：位址池的位址可以随意定義的，然後調用在域内NAT裡面。如果是平時的話這裡就可以結束了，可以正常通路了，但是在這個環境中還不行。
3、在雙ISP+政策路由的情況下特别需要注意的地方。
（1）問題：雙ISP綁定了Zone
說明：上面那2個配置隻适合沒有綁定Zone的，也就是在輸入時沒有加入對應的Zone參數，沒加的話屬于任何一個Zone都可以，如果加了則隻處理該Zone的資料包轉換，而之前定義的都是綁定了出口ISP的，是以隻能轉換從2個ISP來的流量，而内部來的則不能正常轉換。這樣會導緻失效。
解決辦法：no-reverse
加了兩條綁定Trust Zone的，這樣的話就可以處理Trust來的轉換了，實際就是在域内直接轉換了。這裡隻給出了WWW的，FTP的就不示範了，注意同一個Zone是需要加no-reverse參數的，否則配置不上。
4、政策路由影響
分析：如果在平時的話，上面3個配置絕對可以解決問題了，但是，在這個環境下，我們還部署了一個政策路由，政策路由是優先于NAT轉換的，也就是說，它會按照政策路由指定的下一跳轉發，那麼導緻的情況是，本來已經轉換成功了通路，但是政策路由交給的下一跳是丢給ISP的，而不是伺服器。
解決辦法：
1、定義新的ACL
[USG-GW]acl number 3001
[USG-GW-acl-adv-3001]rule deny ip source 192.168.0.0 0.0.255.255 destination 192.168.88.251 0
[USG-GW-acl-adv-3001]rule permit ip source 192.168.19.0 0.0.0.255
[USG-GW-acl-adv-3001]rule permit ip source 192.16.21.0 0.0.0.255
[USG-GW]acl number 3002
[USG-GW-acl-adv-3002]rule deny ip source 192.168.0.0 0.0.255.255 destination 192.168.88.251 0
[USG-GW-acl-adv-3002]rule permit ip source 192.168.20.0 0.0.0.255
說明：ACL從标準的變為了擴充的，可以看到先是deny掉了，當192.168.0.0通路伺服器的時候做轉換，平時肯定是直接通過三層交換機進行轉換了，沒經過防火牆，但是做域内NAT的話，其實就是在防火牆的入接口上面做了一下轉換，但是在入接口上面又調用了政策路由，之前的話是比對了直接交給ISP，這樣的話導緻本來正常轉換了的資料包，想發送給伺服器，但是由于政策路由的存在，就強行的發送給ISP了，是以這裡deny掉，就是讓它正常按路由表轉發，而不受政策路由的控制。
2、政策路由改動【把ACL調用為修改後的】
3、應用到入接口（不在示範）
4、FTP的需要注意的地方。
除了之前的NAT Server在Trust定義以外，還需要調用一個應用層監控，因為之前是在域間轉換的，是以在域間調用了ALG功能，但是這次是域内轉換，是以需要再次 監控。
[USG-GW]firewall zone trust
[USG-GW-zone-trust]detect ftp
結果測試
可以看到通過IP位址可以正常通路了，當然通過域名的方式也是可以的，這裡隻是不搭建環境測試了。
總結【政策、NAT、雙ISP部署】
可以看到政策、NAT 雙ISP的情況出現，需要考慮的因素會非常多，比如政策需要考慮需求，要結合NAT、時間政策等因素進行部署，達到效果，源NAT沒什麼需要太多注意的地方，但是NAT Server的需要注意幾點，如果是同一個zone的話，必須加no-resver參數，不同Zone可以不加。而雙ISP的存在，需要考慮到路由的切換，檢測機制，跟政策路由的部署，這裡政策路由的ACL強烈建議用擴充ACL，因為可以看到如果需求有變化的話，标準ACL立馬顯得無奈，隻有擴充的才能更好的比對。 最後是如果部署需要通過公網IP或者域名通路公司内部伺服器的話，則必須部署域内NAT。但是有綁定Zone跟政策路由的情況下，需要非常注意。最後就是NAT的ALG功能，對于多信道的協定必須開啟應用層監控功能，否則NAT識别不了，常見的比如FTP、PPTP、QQ等都有，如果發現該應用工作不正常，則加入ALG功能即可。
如果大家有任何疑問或者文中有錯誤跟疏忽的地方，歡迎大家留言指出，部落客看到後會第一時間修改，謝謝大家的支援，更多技術文章盡在網絡之路Blog（其他平台同名），版權歸網絡之路Blog所有，原創不易，侵權必究，覺得有幫助的，關注、轉發、點贊支援下！~。