〇 前言

這怕是最后一篇關于IKE，IPSEC的文字了，因為不能沒完沒了。

所以，我一直在想這個標題該叫什么。總的來說可以將其概括為：IKE NAT穿越機制的分析。

但是，同時它也回答了以下問題：

（1）IKE協議交互消息概述。（2）為什么IKE除了端口500還用了端口4500 。（3）IKE MOBIKE是什么。

（4）迷之端口500和迷之端口4500 。（5）IKE/IPsec為什么要將端口500換成端口4500。

（6）ike/ipsec為什么使用了兩個端口。

另外，本篇的所有內容與討論僅局限在IKE V2的定義域內。

好的，開始。

 Author: classic_tong

一 IKE消息簡述

我也不想簡述，但是不述后邊的事情說不清楚。而且，如果是最后一篇的話，也希望能夠做一個總結。

如果有的選的話，我建議你不要讀我的這一小節，而是讀RFC7296的第一章 。然后進入第二小節。

首先，約定一下概念，IKE交互的兩端分別叫做發起端和響應端。基本的通信模式是，發起端發送一個請求報文，響應端回復一個響應報文。

這兩個報文在一起稱為一次交互。一個報文里包含這多個報文段，每個報文段都有其特別的功能和特別的報文段類型，用以和彼此區分。

多次IKE交互之后，IKE通信兩端將成功（或者失敗）建立一個安全的可信信道。這條信道的建立，刪除，狀態維護便是IKE交互的任務。

信道建立之后通信任務將交由ESP/AH協議完成。ESP消息承載的通信信息，依據信道標識（SPI）在可信信道間穿梭。

深入到協議細節里的話。IKE交互其實建立了兩條信道，一條叫IKE SA，一條叫IPSEC SA（child SA）。在這里，我們將SA理解為信道

的等價物。IKE SA負責信道的可信任性，IPSEC SA負責信道機密性。

下面單獨討論IKE SA。

為了得到可信性IKE需要（1）對雙方身份進行AUTH（驗證）。同時為了完成信道的建立過程還需要（2）幫助IPSEC SA進行秘鑰交換。以及

（3）完成自身信道（ike sa）的秘鑰交換。（4）其他特性協商。

以上是IKE的要完成的任務，下面基于對以上任務的理解，我們來看一下IKE的主要交互過程。

先來一張感性的截圖，進行一下直觀的認識：

主要的IKE交互，按照邏輯順序，有：

1. IKE_SA_INIT （截圖中1,2包）

在這個交互里，完成上文提到的功能3），4）。該交互完成之后IKE SA信道便已經成功建立了。

2. IKE_AUTH  （截圖中3,4包）

在這個交互中，完成上文提到的功能1）。該交互已經是在IKE SA的保護之下進行的了。并完成了對彼此雙方信任的建立。

3. CHILD_SA_CREATE （上面的截圖中沒有，下面的截圖中9,10包）

在這個交互中，完成上文提到的功能2）。在此之后便完成了IPSEC SA信道的建立。

從這個時刻開始，便可以開始進行ESP消息（截圖中7,8包，因為解密了，他們帶有ESP頭）的通信了。但是在實際應用中，在2完成之后，ESP消息交互便已經開始了，是暫時使用的IKE SA的秘鑰。

在3完成之后，ESP會切換使用新的秘鑰。REKEY也就是秘鑰的更新，也是這樣的一個過程，使用CHILD_SA_CREATE交互來進行秘鑰更新。

4 INFORMATION （截圖9,10包）

信道的拆除，探活等其他housekeeping（家務活）任務，都使用該消息完成。

簡述到此為止，更多內容可以深入的讀上邊引用的RFC。下一小節將進入主題NAT穿越。

二 端口

再來一張圖。我們驚奇的發現，除了port 500 ，怎么又跑出來一個port 4500 ？尼瑪，這到底怎么回事？（為什么上面的圖都是500？ 這個最后的最后，你就懂了。先劇透一下，上圖關了MOBIKE特性）

 首先，我詳細的描述一下這個現象。 我們前邊討論了，這個IPsec過程分兩類報文，一類是IKE報文，一類是ESP報文。然后我們拋開ESP報文不討論。現在，這個現象是這樣的。除了第一次交互（也就是

前兩個包）使用500端口之外。之后的所以報文都使用4500端口進行通信。

即使是在發送IKE的rekey或reauth時，也使用4500端口。也就是說500端口，后續的報文序列里再也不會使用了。如圖：

接下來，我先說結論，也就是什么情況下什么樣的條件會觸發這個現象發生。這里邊分為兩個場景，每個場景有各自的觸發條件，如下：

場景A：IKE通信雙方至少有一端處于NAT網關的后邊。

1. 當通信雙方檢測到彼此都支持NAT穿越。（當然支持，不然這個場景也沒有意義。所以，處于該場景下天然就是觸發條件。）

這個時候，在第二次交互開始，通信雙方將使用4500端口開始通信。同時ESP包（通常情況下ESP包是IP承載的）會被封包為UDP承載，并使用4500端口。

場景B：IKE通信雙方之間沒有NAT網關的存在。

1. 通信雙方檢測到彼此都支持NAT穿越。

2. 通信雙方都啟用了MOBIKE特性。（原諒我排版不好，你可以先翻到下面去看看mobike是個啥）

場景B下的1,2條件同時滿足時，IKE雙方將在第二次交互時改用4500端口。因為這兩個特性的同時存在，會導致場景B在之后的某個時刻有回落進場景A的可能。

所以，為了防止在突然落入場景A時著急忙慌的切換端口，還不如一開始就切了。（忘記了出處，好像是在 RFC4555 中提到）

所以除了上面的條件，其他情況下，500端口會一直使用。

需要特別說明的是，當使用4500承載的時候，IKE報文頭與UDP報文頭之間，會插入4個字節的0，用來區分ESP報文和IKE報文。

其他，同樣要明確說明的時候，即使在沒有出現NAT的情況下，也就是場景B中，4500的報文里同樣存在這4個字節的0. 如圖留下證據：

 圖中的兩個IP，是我的兩個虛擬機，在同一個網段中在host上使用網橋連接。

三 WHY

說了這么多，都是前提。我真正想說的，以及總結了這么多知識并編寫了整篇內容的全部動機，其實只是要回答這樣一個問題：為什么要換端口？難道不能一直用500端口么？

坦白的說，（經過了大概有怕是4個小時的研究之后）不知道。我收集并總結了如下兩個理由，但是，都不能說服我！

理由一和二是整個思考過程，可以跳過。理由三是正解（我差不多都寫完了之后，突然無意間找到了理由三，所以，寫了不能不寫，就索性置灰了）。

理由一：由于NAT設備的某種限制。

因為，rfc7296里有這樣一段話，說NAT設備會對4500進行特殊處理，同時也會對500進行特殊處理。

Port 4500 is reserved for UDP-encapsulated ESP and IKE.  An IPsec
   endpoint that discovers a NAT between it and its correspondent (as
   described below) MUST send all subsequent traffic from port 4500,
   which NATs should not treat specially (as they might with port 500).

我們知道，500與4500的區別在于500是作為知名端口存在的。總之這里比較含糊。但是作為RFC它給予和我足夠多的重視（誤導）。

理由二：500與4500代表著不同的抽象含義。

什么意思呢？ 就是說作為知名端口（1~1024）和注冊端口（1024~49151）每一個都不是隨便亂用的。必須有明確的定義和正確的使用方法。

所以，如果用500端口來承載ESP/AH包的話，就含糊了500端口的定義。這樣的適合是不好的，所以要用4500來單獨承載。

思科如是說：這是一個同樣困惑于此的人，也提出了這樣的問題給思科之后，思科的回答。我只能說，這聽起來好像挺對的，可是存在著無力的邏輯支持。

另外，也是思科，還有，同時一個人特逗，一直耿耿于懷與為什么IKE的源port也必須是500 。以至于因為得不到想要的答案而憤怒。

https://learningnetwork.cisco.com/thread/83219

理由三（精華精華精華）

這個，就是強有力的，無懈可擊的，我想要的，答案：https://serverfault.com/questions/937763/ipsec-nat-traversal-on-port-4500

The problem is multiplexing IKE and ESP on the same UDP port. To distinguish between the two protocols one or the other has to be marked somehow (otherwise some potentially error-prone heuristic had to be employed).

So continuing on UDP port 500 would have meant to mark the ESP packets as non-IKE packets, in order for the recipient to properly decide whether to process a packet as ESP or hand it to the IKE process. The first two drafts of UDP Encapsulation of IPsec ESP Packets (RFC 3948) actually defined it that way. An all-zero eight byte non-IKE marker in the location where the initiator's IKE SPI is stored in IKE packets was defined as prefix to the actual ESP packet (between UDP header and ESP header).

The problem with that was, of course, that there are usually a lot more ESP packets than IKE packets and imposing an overhead of eight bytes (in addition to the UDP header) to every one of them was not ideal.

The alternative was to mark the IKE packets, which is what version 02 of the draft defined and eventually ended up in the RFC. An all-zero non-ESP marker of four bytes in the location where the SPI is stored in an ESP packet is inserted between UDP and IKE header.

However, that meant port 500 couldn't be used for such packets because all IKE messages (even the first ones) would have to be marked that way, which wouldn't have been backward compatible to IKE/IPsec implementations that didn't support NAT-Traversal. Instead, a separate port is used for UDP-encapsulated ESP and IKE with non-ESP marker. And in order to create a mapping on the NAT before any UDP-encapsulated ESP packets are transmitted (i.e. so inbound traffic can be processed even before any outbound traffic is sent) the switch to port 4500 happens as soon as IKE detects that a NAT is present.

源答復

下面，用我的話翻譯一下：

首先我們知道，當出現NAT場景時，發起端和響應端直接存在著三種報文。

1. 由UDP4500承載的ESP報文。2. 由UDP4500承載的IKE報文。3.由UDP500承載的IKE報文。

然后我們假設不使用4500端口，而全部使用500端口來承載。之后會發生什么？ 首先，NAT設備是沒有問題的，對于我們這里討論或假設的任何場景。

它都可以處理，而且NAT設備也不關心500是不是知名端口，也不對其進行特殊處理。

好，然后，這三種報文都由UDP 500端口來承載。這個時候操作系統收到了udp 500的包的時候是沒有辦法區分出它到底是IKE還是ESP的。

于是，我們面臨一個選擇。

A：讓操作系統首先進入IKE報文的處理流程，然后為ESP報文加一個特殊的MARK，從而進行區分，識別到ESP報文。

B：讓操作系統首先進入ESP報文的處理流程，然后為IKE報文加一個特殊的MARK，從而進行區分，識別到IKE報文。

最終，這個選擇里，RFC們選擇了B。理由是ESP報文的數量遠遠多余IKE報文。在每一個包上加mark（也就是四個字節的0）作為一種資源消耗。兩種陷害擇其輕，自然便選擇了IKE。

可是，這依然不能解釋，為什么要用兩個端口來做。我們可以在最開始的兩個包里，便加上這個mark。這樣的話所有包都使用500端口也是沒有問題的。

然后，并不行。因為為了向前兼容，包格式是不能隨便改的。所以只能讓帶mark的ike報文用新的端口，也就是udp 4500，從而將一開始我們提到的三種報文區分開來。

另外。還能再引申出一個新的問題：為什么不能保持ike的包繼續沿用500端口，而只是將UDP封裝的esp放在4500端口上？

這樣便不需要修改ike的格式（添加四個字節的0）了。

這是因為NAT設備中的端口map關系是需要長期保持的，也就是首選需要NAT內的包使用4500端口觸發NAT設備建立映射關系，這樣NAT外的設備才能夠將ESP包發進來。

設想，如果還是使用500的IKE報文的話。如果NAT內的設備不主動發送ESP包，NAT設備的map表就建立不起來。外邊的ESP包也就無法發送回來。

另外，NAT后的信道需要一個NAT-keepalive包來長期保活。有NAT內的一端發送，從而保證NAT設備中的map不會超時。如下圖：

四 MOBIKE

雖然解了惑。但是挖了的坑不能不填。MOBIKE在這里：https://tools.ietf.org/html/rfc4555

MOBIKE不是摩拜單車。MOBIKE是 mobile ike。是mobility and multihoming ike。

就是IKE支持，發起端的網絡移動，也就是IP變化。以及響應端的多個IP Interface切換，其實也是IP變化。

他們并不是在第一次交互的時候，就協商好了大家都支不支持，而是由發起端根據是否，是否支持NAT，是否MOBIKE等幾個條件來決定是發給500還是發給4500

然后，將這個mobike消息段放在第二次交互中傳輸。（我猜這樣設計的目的是為了安全考慮？）如下圖：

我看了第三個包的幾種情況。包括是否在NAT后，是否支持NAT，是否設置了MOBIKE等。這個message段是否存在都有著不同的情況。

這里就不再進行擴展做詳細研究了。因為它并不影響本文所要討論的所有結論。

不過有一點格外要說的是，它會改變SA的IP！我們回到xfrm與strongswan交互的層面上，再看這個問題。他會導致一個什么樣的消息下發呢？

以及xfrm如何兼容，如何做到這個場景下的SA管理呢？ 這個話題，有點大。需要作為獨立內容進行分析，不在此擴展了。

不過我們還是來撇一下這個交互吧，rfc里的一個示意圖：（注意看其中的UPDATE_SA_ADDRESSES部分，我揣測它會觸發一個SA UPDATE消息？）

五 NAT穿越協商

本小節講：通信兩端如何知道對方和自己是不是在NAT之后。這里邊兩方是獨自得知的，而不是相互告知。一方要獨自回答兩個問題，

1. 對面在不在NAT后，2，我在不在NAT后。

再講這個方法之前，有一個前提，就是在建立連接前每一端都需要被配置一對local IP和remote IP的已知條件。這一對IP就是在該點它所能直接訪問（直接到達）的那個兩個IP。

所以這個探測方法就是，在第一次交互的第一個包中。發起方將上邊提到的配置的兩個IP都在payload里發給對方。然后，對方會得到4個IP。兩個是報文里邊的，另兩個是承載

這個報文的IP頭里的。所以，只要一對比，響應端就回答了上邊那兩個問題。反方向機制與過程完全相同，在第一次交互的第二個包里進行。

只不過，意思雖然是這個意思，但是在RFC中規定的實現上，略有區別。payload里存的不是IP而是散列值。收到散列值的一方只需要同樣對IP頭里的IP做散列，然后進行比較是否一至，就可以判斷了。這樣即達到了目的，也隱藏了對方的真實IP。

這兩個報文段類型的名稱是：NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP

計算散列的具體方法是： SHA1（SPI + SPI + IP addr + Port number）

詳見：https://tools.ietf.org/html/rfc7296#section-2.23

如示例：

六 報文樣式

為了理解直觀，總結了幾種報文的結構，如下圖：

其中，需要注意的是，傳輸模式下TCP報文頭中的checksum是錯的。因為它保存在加密報文中，所以無法被NAT網關設備修正。這也是為什么

IKE必須關心NAT穿越，而不能無視它的原因之一。

當然，另一個原因是非TCP/UDP承載的報文，會被NAPT設備丟掉？（i dont know..）