網際網路上有很多關于NAT回流故障的分析，但大多數是模棱兩可，沒有從根本上給出NAT回流故障的具體原因，本文通過資料包捕獲、分析資料包，結合TCP三向交握原理，詳細的分析了NAT回流故障的具體原因，并給出相應的解決辦法。
術語”NAT回流“，有的技術文檔上又稱為”NAT回環“，什麼是NAT回流？舉例說明或許會更加通俗易懂：
某公司有一個出口路由器連接配接ISP網絡，在公司内部有web伺服器。
公司員工在公司内部網絡，使用公司網站的域名或公網IP位址（ISP的DNS伺服器解析域名後，得到公司的公網IP位址），來通路公司内部的web伺服器，其通路請求資料包在網絡裝置上的轉發映射過程，就叫做”NAT回流“，如果通路請求失敗，則意味着NAT回流發生故障了，這也是本文需要分析原因并加以解決的目标。
網絡裝置在NAT回流的過程中，将目标公網位址轉換為web伺服器的私有位址，然後将http通路請求資料包轉發到web伺服器上，這叫做”NAT映射“。
PS：
有人問，在公司内網為什麼不直接使用web伺服器的私有位址通路web伺服器？
答，很多普通員工不知道什麼是”IP位址“，隻知道”網址“。如果公司内網沒有架設DNS伺服器，而使用ISP的DNS伺服器解析域名，則解析結果為公網IP位址。
百度經驗:jingyan.baidu.com
工具/原料
- 線上遠端實驗室網絡（見之前的文章）
- MSR5040路由器、DCR2659路由器、MSR30路由器、交換機S16、PC2、PC3
- sniffer抓包程式、360流量防火牆
百度經驗:jingyan.baidu.com
方法/步驟
-
1
提供實驗拓撲圖和說明如下：
S16（模拟内網普通交換機）
R1（MSR5040路由器，提供NAT服務）
R4（DCR2659路由器，模拟ISP網絡）
R3（MSR30路由器，模拟公網使用者終端）
PC2（模拟内網用戶端PC，提供抓包功能）
PC3（模拟内網WEB伺服器、Telnet伺服器，提供抓包功能）
步驟閱讀
由TCP三向交握原理來分析NAT回流故障 -
2
在PC3上配置WEB服務、Telnet服務、安裝sniffer抓包軟體。
配置WEB服務比較簡單，這裡配置步驟省略。
安裝sniffer抓包軟體比較簡單，這裡安裝過程省略。
配置Telnet服務，這裡簡單配置一下（達到測試目的即可），如下列截圖所示：
步驟閱讀
由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 -
3
在内網PC2上測試PC3的WEB服務、Telnet服務是否正常：
步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 -
4
根據實驗拓撲圖，配置下列網絡參數，具體步驟很簡單，這裡省略：
配置R3、R4、R1的相關接口的IP位址；
配置R3的預設路由指向R4的G0/4（192.168.34.4）；
配置R1的預設路由指向R4的G0/6（192.168.14.4）；
測試R3到R1的G0/0接口的連通性（ping 192.168.14.1），確定連通性；
步驟閱讀 由TCP三向交握原理來分析NAT回流故障 -
5
配置PC2和PC3的預設網關為：192.168.8.13。
本案例中，遠端線上實驗使用者vpn撥号後配置設定的ip網段為192.168.5.0/24，為了保持遠端線上實驗使用者持續、正常的遠端登入PC2和PC3，務必確定PC2和PC3有到192.168.5.0/24、192.168.6.0/24網段的靜态路由，具體原因見之前的文章：“ 遠端線上網絡實驗室搭建”
步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 -
6
下面開始配置R1的NAT服務，包括src-nat和dst-nat，并測試scr-nat
1）、配置基本acl 2000，permit 192.168.8.0/24網段
2）、在G0/0接口上配置src-nat
3）、在G0/0接口上配置nat server（即dst-nat），針對www服務（80端口）和telnet服務（23端口）進行dst-nat轉換
4）、在R3上開啟icmp的debug調試，在PC2上pingR3，測試src-nat是否成功
截圖如下：
步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 -
7
接下來開始測試外網使用者（R3）對内部伺服器PC3的通路。
假設PC3的域名解析結果IP位址為R1的G0/0接口位址192.168.14.1
1）、内部伺服器PC3上打開360流量防火牆，檢測呼入連接配接
2）、R1上開啟nat packet debug調試輸出，檢視nat的狀态
3）、R1關閉自身的http服務和telnet服務，避免沖突
4）、測試R3到PC3的telnet連接配接
5）、測試R3到PC3的http連接配接
具體截圖如下：
步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 -
8
到目前，外網使用者已經可以通過PC3的公網IP來通路PC3，下面重點分析内網使用者通過PC3的公網IP來通路PC3的過程，抓包分析，結合TCP三向交握原理。
-
9
在R1的G0/1接口配置并開啟nat server（dst-nat），這樣當R1在G0/1接口收到PC2針對PC3的公網IP位址的通路請求時，才能進行nat轉換
且在R1上開啟nat packet的debug調試輸出
步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 -
10
在PC2和PC3上同時啟動sniffer抓包功能
在PC2上分别使用telnet和http兩種方式來通路PC3的公網IP（192.168.14.1），發現通路失敗
步驟閱讀 由TCP三向交握原理來分析NAT回流故障 步驟閱讀 由TCP三向交握原理來分析NAT回流故障 -
11
在PC2上停止并檢視資料包，分析如下：
首先，PC2原本希望和PC3的公網IP（192.168.14.1）建立三次握手，但一直沒有收到192.168.14.1的ACK，是以此連接配接請求失敗；
其次，PC2收到了PC3的内網IP（192.168.8.203）傳回的ACK，但是PC2認為自己從來沒有向PC3的内網IP進行過連接配接請求，是以此連接配接請求失敗；
第三，PC2向PC3發送了一個RST類型的TCP封包，PC2和PC3之間的“非法連接配接”被複位了（reset）
步驟閱讀 由TCP三向交握原理來分析NAT回流故障 -
12
在R1上檢視調試資訊輸出，分析如下：
R1在這個通信過程中，隻幹了一件事，就是不斷的将目标IP 192.168.14.1轉換為192.168.8.203，源IP 192.168.8.202保持不變，将資料包轉發給192.168.8.203（PC3）
而PC3收到資料包後，PC3認為是PC2向它發送了連接配接請求，是以回應一個SYN ACK連接配接響應給PC2，且此回應包沒有經過R1的轉發（直接經過交換機到達PC2)
步驟閱讀 由TCP三向交握原理來分析NAT回流故障 -
13
在PC3上停止并檢視資料包，分析如下：
首先，PC3收到R1轉發過來的資料包，源IP為PC2（192.168.8.202），它認為這是PC2向自己發送的TCP連接配接請求；
其次，PC3向PC2發送回應資料包SYN ACK；
第三，PC3期待收到PC2的SYN ACK，但事與願違，它收到了PC2的reset包
是以，連接配接請求建立不成功；
步驟閱讀 由TCP三向交握原理來分析NAT回流故障 -
14
到目前為止，NAT回流不成功的原因已經找到了，就是TCP三向交握無法完整的建立導緻的。
知道深層次的原因後，自然就有解決方法了：
首先，在R1的G0/1接口配置src-nat，這樣，R1轉發PC2到PC3公網IP的請求時，一方面将PC3的公網IP轉換為PC3的内網IP（目标位址），另一方面，将源位址（PC2的IP）轉換為G0/1接口的IP（192.168.8.13）
其次，當PC3收到這個SYN請求時，回應SYN ACK包，目标為R1的G0/1接口IP，由于R1的G0/1接口同時配置了dst-nat和src-nat，是以此資料包的源IP轉換為192.168.14.1（根據上一步建立的IP端口映射表），目标IP轉換為192.168.8.202（根據上一步建立的IP端口映射表），R1完成轉換後，從G0/1接口轉發資料包給PC2
第三，PC2收到這個SYN ACK後，發現源位址為192.168.14.1，即原先SYN請求的目标位址，于是向192.168.14.1回應SYN ACK
……
以此類推，後面的通信過程是一樣的。
在這裡，PC2認為自己一直是和192.168.14.1通信的，而PC3則認為自己一直是和192.168.8.13進行通信的，而實際上PC2和PC3一直進行着真正的通信。
-
15
R1的G0/1接口同時配置src-nat和dst-nat（nat server）
步驟閱讀 由TCP三向交握原理來分析NAT回流故障 -
16
R1的nat packet debug輸出如下：
可以看出來，第一條和最後一條的源、目标IP位址以及端口号達到了一緻性
步驟閱讀 由TCP三向交握原理來分析NAT回流故障 -
17
PC2成功的和192.168.14.1建立了三次握手
PC3成功的和192.168.8.13建立了三次握手
步驟閱讀 由TCP三向交握原理來分析NAT回流故障 由TCP三向交握原理來分析NAT回流故障