NAT的特殊處理

在全球IPv4地址愈發匱乏的大背景下，NAT技術應運而生，並且隨著時間的推移，這項技術運用的越來越廣泛。在實際應用中，NAT大體可以分成EasyIP、PAT、NOPAT、靜態NAT和NAT Server幾種用法。

NAT技術的原理並不複雜，如圖1所示，三個帶有內部地址的資料報文到達NAT裝置，其中報文1和報文2來自同一個內部地址但有不同的源連接埠號碼，報文1和報文3來自不同的內部地址但具有相同的源連接埠號碼。通過NAT映射，三個資料報的源IP地址都被轉換到同一個外部地址，但每個資料報都被賦予了不同的源連接埠號碼，因而仍保留了報文之間的區別。當各報文的回應報文到達時，NAT裝置仍能夠根據回應報文的目的IP地址和目的連接埠號碼來區別該報文應轉寄到的內部主機。

圖1 源地址轉換原理圖(SNAT)

NAT裝置通過建立五元組（源地址、源連接埠號碼、協議類型、目的地址、目的連接埠號碼）表項為依據進行地址分配和報文過濾。即，對於來自相同源地址和源連接埠號碼的報文，若其目的地址和目的連接埠號碼不同，通過映射後，相同的源地址和源連接埠號碼將被轉換為不同的外部地址和連接埠號碼，並且NAT裝置只允許這些目的地址對應的外部網路的主機才可以通過該轉換後的地址和連接埠來訪問這些內部網路的主機。

原理雖然簡單，但是在實際應用中還是會碰到各種的問題，比如ICMP報文沒有連接埠號碼，裝置如何進行NAT映射？分區報文中沒有四層資訊，裝置又如何進行NAT映射？本文將以H3C公司SecPath F1000-E裝置為例，對NAT的特殊處理進行深入的解析。

1 地址統一管理

首先我們在裝置上配置一個PAT方式的NAT轉換，一個NOPAT方式的NAT轉換，再配置兩個NAT Server：

#

nat address-group 3 218.197.70.10 218.197.70.19

nat address-group 13 61.154.70.20 61.154.70.29

#

interface GigabitEthernet0/3

port link-mode route

nat outbound 3001 address-group 13 no-pat

nat outbound 3000 address-group 3

nat server protocol tcp global 218.197.70.20 www inside 192.168.200.2 www

nat server protocol udp global 218.197.70.21 tftp inside 192.168.200.2 tftp

ip address 218.197.70.1 255.255.255.0

#

當我們查看路由表的時候可以看到NAT位址集區的地址以及NAT Server的公網地址全部被加入其中。

<SecPath F1000-E>display ip routing-table

Routing Tables: Public

Destinations : 31 Routes : 31

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/0 Static 60 0 162.105.12.1 GE0/0

61.154.70.20/32 Static 1 0 0.0.0.0 NULL0

61.154.70.21/32 Static 1 0 0.0.0.0 NULL0

61.154.70.22/32 Static 1 0 0.0.0.0 NULL0

61.154.70.23/32 Static 1 0 0.0.0.0 NULL0

61.154.70.24/32 Static 1 0 0.0.0.0 NULL0

61.154.70.25/32 Static 1 0 0.0.0.0 NULL0

61.154.70.26/32 Static 1 0 0.0.0.0 NULL0

61.154.70.27/32 Static 1 0 0.0.0.0 NULL0

61.154.70.28/32 Static 1 0 0.0.0.0 NULL0

61.154.70.29/32 Static 1 0 0.0.0.0 NULL0

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

162.105.12.0/24 Direct 0 0 162.105.12.211 GE0/0

162.105.12.211/32 Direct 0 0 127.0.0.1 InLoop0

192.168.200.0/24 Direct 0 0 192.168.200.1 GE0/2

192.168.200.1/32 Direct 0 0 127.0.0.1 InLoop0

218.197.70.0/24 Direct 0 0 218.197.70.1 GE0/3

218.197.70.1/32 Direct 0 0 127.0.0.1 InLoop0

218.197.70.10/32 Static 1 0 0.0.0.0 NULL0

218.197.70.11/32 Static 1 0 0.0.0.0 NULL0

218.197.70.12/32 Static 1 0 0.0.0.0 NULL0

218.197.70.13/32 Static 1 0 0.0.0.0 NULL0

218.197.70.14/32 Static 1 0 0.0.0.0 NULL0

218.197.70.15/32 Static 1 0 0.0.0.0 NULL0

218.197.70.16/32 Static 1 0 0.0.0.0 NULL0

218.197.70.17/32 Static 1 0 0.0.0.0 NULL0

218.197.70.18/32 Static 1 0 0.0.0.0 NULL0

218.197.70.19/32 Static 1 0 0.0.0.0 NULL0

218.197.70.20/32 Static 1 0 0.0.0.0 NULL0

218.197.70.21/32 Static 1 0 0.0.0.0 NULL0

2所示，從內網來的報文經過NAT轉換，到達外網中的目的地，目的主機向NAT轉換後的地址回應報文；當報文到達與NAT出介面直連的裝置時，這個裝置並不知道這個經過轉換的公網地址所對應的MAC，此時便會發送ARP請求。

圖2 NAT裝置的ARP響應

NAT使用的公網地址，包括了被引用的位址集區的地址、NAT Server的公網地址和被引用的靜態配置的公網地址。這些地址全部會進入地址管理模組進行統一地址管理，並由地址管理模組通知路由管理模組將這些IP地址加入路由表。當外部裝置向這些地址發起ARP請求，裝置便會將ARP請求送到地址管理模組檢查ARP報文的合法性，地址管理髮現ARP所請求的IP地址為NAT位址集區地址，則通知NAT模組判斷是否需要回應ARP，NAT模組會檢查ARP所請求的IP地址是否是收到ARP介面下配置的NAT的地址，如果是則通知ARP模組進行ARP應答。

由於有了地址統一管理，與介面不在同一網段的位址集區的地址被加入的本地路由表，並且可以有選擇的將其引入動態路由協議，通過OSPF或者BGP將其發布出去，簡化了組網中其他裝置的配置。

2 位址集區的優先順序

雙機熱備對於防火牆來說是一個必不可少的功能，兩台防火牆上的NAT配置也需要完全相同，這樣就會出現一個問題：如果兩個防火牆分別將兩條不同的流映射到相同的公網地址，並且連接埠也相同的話，勢必會造成表項的混亂，所以我們引入了位址集區優先順序的概念。

在雙機熱備的環境中，如果位址集區被配置為高優先順序，在進行連接埠映射的時候連接埠取值範圍為1024~35000；如果位址集區被配置為低優先順序，其連接埠取值範圍為35001~65535。這樣主備兩台防火牆雖然使用相同的NAT位址集區中的地址，但是由於位址集區的優先順序不同，所以就不會出現NAT轉換後公網IP和公網連接埠完全相同的情況了。

位址集區優先順序只有在雙機熱備的環境中才有意義，如果是單機環境，高優先順序的位址集區的連接埠取值範圍就是1024~65535，而低優先順序位址集區的連接埠取值範圍依舊是35001~65535。

3 PING操作的NAT映射

H3C ComwareV5平台為了保證內網的安全性，採用了五元組匹配NAT映射表項，但是ICMP報文沒有類似於TCP和UDP報文的連接埠資訊，既要對ICMP的請求報文進行NAT映射，又要確保網路的安全性，只允許合法的ICMP響應報文進入內網，就必須對其進行特殊的處理。

圖3 NAT簡單組網圖

圖3是一個最簡單的NAT組網圖，內網使用192.168.200.0/24的私網地址，外網是218.197.70.0/24的公網地址，而在裝置串連外網的介面上我們啟用了NAT。我們從內網的PC1去PING外網的PC2是可以成功的，而我們在裝置上看到了這樣的一個表項：

Initiator:

Source IP/Port : 192.168.200.2/2048

Dest IP/Port : 218.197.70.2/1024

VPN-Instance/VLAN ID/VLL ID:

Responder:

Source IP/Port : 218.197.70.2/0

Dest IP/Port : 218.197.70.12/1036

VPN-Instance/VLAN ID/VLL ID:

Pro: ICMP(1) App: unknown State: ICMP-CLOSED

Start time: 2011-05-28 11:44:35 TTL: 23s

Root Zone(in): Private

Zone(out): Public

Received packet(s)(Init): 4 packet(s) 240 byte(s)

Received packet(s)(Reply): 4 packet(s) 240 byte(s)

既然ICMP報文沒有連接埠資訊，那麼表項中的連接埠資訊又是從何而來的呢？我們不妨通過對報文的分析找到答案。

圖4 內網ICMP請求報文

從內網抓到的ICMP請求報文可以看出TYPE+CODE欄位的值是0x0800，而Identifier欄位的值是0x0400，這兩個值轉換成十進位的數值，正好是2048和1024。與發起方的源連接埠數值和目的連接埠數值一致。那麼我們再看一下內網抓到的ICMP響應報文是否可以與回應程式的源連接埠和目的連接埠對應。

圖5 內網ICMP響應報文

在響應報文中TYPE+CODE欄位為0x0000，十進位也是0，這與表項中回應程式的源連接埠相同；但是問題出現在回應程式的目的連接埠，在報文中Identifier欄位的值是0x0400，十進位為1024，而表項中的目的連接埠卻為1036，這又是為什麼呢？原來Windows系統發出的ICMP報文的Identifier欄位全部都為0x0400，當多台內網PC同時PING一個外網PC時，如果裝置僅僅對Identifier欄位進行簡單的運算，極有可能造成多個表項中回應程式的參數相同，使得回程報文發送錯誤。為避免這種情況的發生，裝置會在對ICMP請求報文進行IP地址轉換的同時，還會選擇一個閒置連接埠號碼對報文中的Identifier欄位進行變化，以避免上述情況的發生。

圖6 外網ICMP請求報文

在圖6中我們可以看到轉換後的ICMP請求報文的Identifier欄位已經變成了0x040c，也就是十進位的1036，這與表項中回應程式的目的連接埠一致，這樣的一個五元組就能唯一確定一個PING操作了。

4 ICMP差錯報文的處理

內網PC1試圖通過TFTP協議從外網的PC2下載aaa.bin檔案，但是PC2並沒有開啟TFTP服務，這時PC2會向PC1回應ICMP連接埠不可達的差錯報文。如果我們依然按照上一節中的規則來理解ICMP差錯報文的轉換過程，那就大錯特錯了。對於源地址轉換的NAT來說，外網的報文要想順利進入內網，就必須五元組匹配裝置上的NAT表項，內網訪問外網時使用的是UDP協議，而ICMP差錯報文是ICMP協議，這一點就不符合要求。但是從圖7內網PC1上抓包我們清楚的看到這個ICMP差錯報文確確實實的被轉寄了進來。這其中的奧妙就在於裝置對ICMP差錯報文的特殊處理。

圖7 內網TFTP訪問抓包

當PC1訪問PC2時，裝置上會產生這樣一個表項，PC1使用的是UDP協議，源IP和源連接埠為192.168.200.2/2428，目的IP和目的連接埠為218.197.70.2/69；裝置進行NAT轉換後的源IP和源連接埠為218.197.70.12/1048。

Initiator:

Source IP/Port : 192.168.200.2/2428

Dest IP/Port : 218.197.70.2/69

VPN-Instance/VLAN ID/VLL ID:

Responder:

Source IP/Port : 218.197.70.2/69

Dest IP/Port : 218.197.70.12/1048

VPN-Instance/VLAN ID/VLL ID:

Pro: UDP(17) App: TFTP State: UDP-OPEN

Start time: 2011-05-28 13:17:49 TTL: 119s

Root Zone(in): Private

Zone(out): Public

Received packet(s)(Init): 2 packet(s) 88 byte(s)

Received packet(s)(Reply): 0 packet(s) 0 byte(s)

再讓我們來看看PC2回應的ICMP差錯報文的結構，8和圖9所示：

圖8 外網ICMP差錯報文結構

圖9 內網ICMP差錯報文結構

比較內網和外網的報文之後答案已經非常清楚了，裝置根據ICMP差錯報文體中的IP地址和連接埠號碼匹配裝置上的NAT表，再根據這個NAT表項對報文目的IP，以及報文體中的源IP和源連接埠進行了轉換，然後發送到內網的PC1。

同時裝置會根據ICMP差錯報文對相應的會話進行加速老化，已達到節省裝置資源的目的。剛才老化時間還是120秒的表項在收到ICMP差錯報文後迅速將老化時間調整為15秒。工作階段狀態也由UDP-OPEN變為了Accelerate。

Initiator:

Source IP/Port : 192.168.200.2/2428

Dest IP/Port : 218.197.70.2/69

VPN-Instance/VLAN ID/VLL ID:

Responder:

Source IP/Port : 218.197.70.2/69

Dest IP/Port : 218.197.70.12/1048

VPN-Instance/VLAN ID/VLL ID:

Pro: UDP(17) App: TFTP State: Accelerate

Start time: 2011-05-28 13:17:49 TTL: 14s

Root Zone(in): Private

Zone(out): Public

Received packet(s)(Init): 9 packet(s) 403 byte(s)

Received packet(s)(Reply): 0 packet(s) 0 byte(s)

5 分區報文的NAT轉換

在PAT轉換類型的NAT地址轉換中，NAT除了對IP地址轉換外，還使用到TCP或UDP報文的連接埠號碼、ICMP報文的ICMP頭中的Identifier欄位資訊。當一個報文被分成若干片之後，這些資訊只有首片報文會攜帶，後續分區報文依靠報文ID、分區標誌位、分區位移量依次關聯到前一個分區。以ICMP報文為例，說明NAT對分區的IP報文進行的處理。在ICMP報文分區後，只有在首片ICMP報文中包含ICMP頭的Identifier欄位。在首片報文到達NAT裝置後，按照正常的轉換流程，根據源IP地址和Identifier資訊產生轉換表項並轉寄出去。在第二個及後續分區到達後，由於只包含IP地址卻沒有Identifier資訊，可能因此無法進行NAT轉換。解決的辦法有兩種：

1) 先重組，再進行NAT轉換，在分區報文到達後，先進緩衝，等屬於這個IP報文的所有分區到達後進行虛擬分區重組，再進行NAT地址轉換。最後將NAT轉換完成的IP報文按照順序發送出去。

2) 在首片到達並轉換後，裝置記錄並儲存轉換首片使用的IP及Identifier資訊，並在後續分區到達後應用同樣的轉換表項進行轉換。

在H3C SecPath F1000-E中會由流分類和虛擬分區重組兩個模組對分區報文進行處理。首先流分類會對到達裝置的報文進行標識，如果是非首片的IP報文，流分類別模組會將這個報文打上和其首片報文相同的標記，交給後續模組處理。NAT模組根據這個標識就可以判斷如何對非首片的IP報文進行NAT轉換了。

而虛擬分區重組所解決的就是報文亂序到達裝置的情況，也就是使用上面的第一種方法對分區的報文進行NAT轉換。

6 多核產品的無限串連

最後我們來介紹一下多核產品特有的NAT無限串連。

顧名思義，NAT無限串連就是內網通過NAT訪問外網不會受到公網地址數量的影響，並發訪問的數量只與裝置的最大會話數相關。

前面我們講到，裝置在判斷從外網進入內網的報文是否合法是採用了五元組匹配，源地址、源連接埠號碼、協議類型、目的地址、目的連接埠號碼必須完全一樣裝置才會唯一確認一個表項。這裡我們可以做一個實驗，配置NAT裝置的公網地址只有一個，並且配置成了高優先順序。也就是說在內網所有的PC全部使用相同的協議訪問外網同一台伺服器、同一個連接埠的情況下，SecPath F1000-E可以支援64512個並發會話。

<SecPath F1000-E>display session statistics

Current session(s):64514

Current TCP session(s): 1

Half-Open: 0 Half-Close: 0

Current UDP session(s): 64512

Current ICMP session(s): 0

Current RAWIP session(s): 0

Current relation table(s): 0

Session establishment rate: 0/s

TCP Session establishment rate: 0/s

UDP Session establishment rate: 0/s

ICMP Session establishment rate: 0/s

RAWIP Session establishment rate: 0/s

Received TCP: 100945 packet(s) 22944126 byte(s)

Received UDP: 1222623 packet(s) 63581139 byte(s)

Received ICMP: 630395 packet(s) 17777039 byte(s)

Received RAWIP: 0 packet(s) 0 byte(s)

Dropped TCP: 0 packet(s) 0 byte(s)

Dropped UDP: 0 packet(s) 0 byte(s)

Dropped ICMP: 0 packet(s) 0 byte(s)

Dropped RAWIP: 0 packet(s) 0 byte(s)

如果訪問的目的地址有兩個，則並發會話數可以達到129024個：

<SecPath F1000-E>display session statistics

Current session(s):129026

Current TCP session(s): 0

Half-Open: 0 Half-Close: 0

Current UDP session(s): 129024

Current ICMP session(s): 0

Current RAWIP session(s): 0

Current relation table(s): 0

Session establishment rate: 0/s

TCP Session establishment rate: 0/s

UDP Session establishment rate: 0/s

ICMP Session establishment rate: 0/s

RAWIP Session establishment rate: 0/s

Received TCP: 150635 packet(s) 62257395 byte(s)

Received UDP: 2940678 packet(s) 152925584 byte(s)

Received ICMP: 630395 packet(s) 17777039 byte(s)

Received RAWIP: 0 packet(s) 0 byte(s)

Dropped TCP: 0 packet(s) 0 byte(s)

Dropped UDP: 0 packet(s) 0 byte(s)

Dropped ICMP: 0 packet(s) 0 byte(s)

Dropped RAWIP: 0 packet(s) 0 byte(s)

從下面的詳細會話表項可以看到，經過NAT轉換後，相同的源地址+連接埠可以與不同的目的地址+連接埠建立會話對應關係。

Initiator:

Source IP/Port : 192.168.200.3/52024

Dest IP/Port : 218.197.70.3/5000

VPN-Instance/VLAN ID/VLL ID:

Responder:

Source IP/Port : 218.197.70.3/5000

Dest IP/Port : 218.197.70.200/65535

VPN-Instance/VLAN ID/VLL ID:

Pro: UDP(17) App: unknown State: UDP-OPEN

Start time: 2011-05-28 17:24:12 TTL: 9881s

Root Zone(in): Private

Zone(out): Public

Received packet(s)(Init): 2 packet(s) 104 byte(s)

Received packet(s)(Reply): 0 packet(s) 0 byte(s)

Initiator:

Source IP/Port : 192.168.200.3/50215

Dest IP/Port : 218.197.70.4/5000

VPN-Instance/VLAN ID/VLL ID:

Responder:

Source IP/Port : 218.197.70.4/5000

Dest IP/Port : 218.197.70.200/65535

VPN-Instance/VLAN ID/VLL ID:

Pro: UDP(17) App: unknown State: UDP-OPEN

Start time: 2011-05-28 17:18:28 TTL: 9697s

Root Zone(in): Private

Zone(out): Public

Received packet(s)(Init): 6 packet(s) 312 byte(s)

Received packet(s)(Reply): 0 packet(s) 0 byte(s)

而在真實的網路中，內網PC訪問的目的IP和連接埠的組合可能有幾千甚至上萬個。那麼NAT所能支援的並發數量也就變成了64512與目的地址數量的乘積，在理論上已經接近無限個了。

7 小結

雖然NAT可以解決IP地址空間不足，也可以很好地隱藏內部網路的拓撲結構，使網路更安全。但是它畢竟修改了報文的內容，隨著應用情境的不斷增多，相信還有很多需要NAT進行特殊處理的地方，這些地方有待於我們繼續挖掘、探討，使得NAT技術更加完善。