[ipsec] 特別硬核的ike/ipsec NAT穿越機制分析

〇 前言

這怕是最後一篇關於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..）