公司有台華為USG-6350，可以說是我修改得最多的網絡設備，我剛進公司的時候它就只拉了一條100M對等長寬，為商場公共wifi提供網絡出口。乖乖~~，這可不是便宜貨，保守估計三年前搭機房的時候花了2萬，居然和我屋企200蚊的Netgear一樣待遇，所以我有事無事都會折騰一下。
4月底公司其中一個移動的網絡出口需要降速，原來100M對等專線，帶5個IP的，換成1:5單IP的，有點可惜，我都未真正體驗過上傳100M的速度。狠下心來找個時間把這篇文章敲定了。
USG現狀
原來的長寬已經換成 “移動100M”、“移動50M”和“電信10M”，直接上圖（以后這張圖就叫“現狀圖”了）。
圖左，終端數大的都走移動100M ，微信Server單獨走電信10M，其余的類似服務器和商場聯網設備走移動50M。路由表長這樣⇓
第一條是臨時的，大家可以忽略。第二條用於“IP回流”，下面會講。各走到網絡出口后要NAT，NAT表長這樣⇓
同樣第一、二條用於“IP回流”，先略過。作為防火牆，需要在策略中放行外出的數據包，安全策略長這樣⇓
同樣第一條用於“IP回流”。數據包溜達完回家后也需要一條路由，回程路由長這樣⇓
回程路由最好寫成靜態路由，唔洗煩。這樣就完成了“現狀圖”中的“內網訪問外網”的過程；另一個“外網訪問內網”需要用到NAT-Server，就是經常說的映射，涉及公司服務器的安全，就不上圖了。
IP回流
IP回流其實並不常見，我以前就無碰過，這種現象和服務器映射有關，現在很多傻瓜設備都支持IP回流功能，不過USG-6350只在手冊中給出了簡例，我覺得需要詳細記錄下。
未做IP回流前，USG拉了兩條專線，微信Server 192.168.0.200映射公網IP（120.130.14.11）發布服務，商場訪客sec 192.168.0.2經由公網IP（120.130.14.10）的NAT上網。
以TCP三次握手為例，當普通用戶使用公網IP訪問服務器時出現下面的過程。
數據包在經過USG時，匹配映射表，目的地址D:120.130.14.11被轉成D:192.168.0.200，並安全到達服務器，服務器根據這個請求包寫了一份回復（就是把原來的S與D對調），回復包經過USG時目的地址為內網，直接就本地轉發了，根本不會查NAT的緩存表把S轉回來。回復包雖然安全到達用戶電腦，但請求包與回復包不能匹配（S與D不對應），用戶繼續等待，直到兩邊都超時…連接失敗。
#這里延伸一下：
SNAT，源地址轉換，就是平時 內網訪問外網的NAT
DNAT，目的地址轉換，就是NAT-Server，俗稱映射，發布服務用的
SNAT/DNAT我們都有了，但上面的過程明顯只觸發了DNAT，那是因為SNAT只配置在所有內對外的路徑上（移動100M、移動50M、電信10M都是內網訪問外網），內對內的，無論是安全策略、路由還是NAT，我們一樣都未配置。
理想情況是這樣的⇓
現在情況就很明朗了。
α：安全策略放行trust to trust；
β：策略路由指定內網到內網怎么走
γ：內對內的對應NAT
#其實微信Server與訪客sec可以走同一條專線，用同一個公網IP，因為NAT的時候是用端口號作為區分的，保存到NAT的緩存表中，SNAT與DNAT每次都使用不同端口，復原的時候也不會亂。