由於歷史的原因，部署帶 Internet 協議安全的第二層隧道協議（L2TP/IPSec）的問題之一在於無法定位網路地址轉換（NAT）之後的 IPSec 對話方。 Internet 服務提供商和小型辦公/家庭辦公（SOHO）網路通常使用 NAT 來共享單個公共 IP 地址。 雖然 NAT 有助於節省剩餘的 IP 地址空間，但是它們也給諸如 IPSec 之類的端對端協議帶來了問題。

一種稱為 IPSec NAT 穿越（NAT-T）的新技術正在由 Internet 工程任務組的IPSec 網路工作組標準化。 IPSec NAT-T 是在標題為 “UOSec 包的 UDP 封裝”（draft-ietf-ipsec-udp-encaps-02.txt）和“IKE中的 NAT 穿越協商”（draft-ietf-ipsec-nat-t-ike-02.txt）的 Internet 草案中描述的。 IPSec NAT-T 對協商過程進行了修改，並且定義了傳送受 IPSec 保護的資料的不同方法。

在 IPSec 協商過程中，支援 IPSec NAT-T的對話雙方會自動確定：

• 發起 IPSec 對話的一方（通常是一個客戶端計算機）和響應 IPSec 對話的一方（通常是一個伺服器）是否都能執行 IPSec NAT-T。

• 它們之間的路徑中是否存在任何 NAT。

如果這兩個條件同時為真，那麼雙方將使用 IPSec NAT-T 來通過 NAT 傳送受 IPSec 保護的流量。 如果其中一方不支援 IPSec NAT-T，則執行常規的 IPSec 協商（在前兩個訊息之後）和 IPSec 保護。 如果雙方都支援 IPSec NAT-T，但是它們之間不存在 NAT，則執行常規的 IPSec 保護。

本專欄研究與通過 NAT 使用 IPSec 相關聯的問題，以及這些問題如何通過 IPSec NAT-T 來得到解決，以及用於快速模式和主模式的 Internet 金鑰交換（IKE）協商中的結果變更。

注意： IPSec NAT-T 是僅為 ESP 流量定義的。

本頁內容

與通過 NAT 使用 IPSec 相關的問題

與通過 NAT 使用 IPSec 相關的問題如下：

• NAT 無法更新上層校驗和。

  TCP 和 UDP 報頭包含一個校驗和，它整合了源和目標 IP 地址和埠號的值。 當 NAT 改變了某個包的 IP 地址和（或）埠號時，它通常要更新 TCP 或 UDP 校驗和。 當 TCP 或 UDP 校驗和使用了 ESP 來加密時，它就無法更新這個校驗和。 由於地址或埠已經被 NAT 更改，目的地的校驗和檢驗就會失敗。 雖然 UDP 校驗和是可選的，但是 TCP 校驗和卻是必需的。

• NAT 無法多路傳輸 IPSec 資料流。

  ESP 保護的 IPSec 流量沒有包含可見的 TCP 或 UDP 報頭。 ESP 報頭位於 IP 報頭和加密的 TCP 或 UDP 報頭之間，並且使用 IP 協議號 50。 因此，TCP 或 UDP 埠號就無法將流量多路傳輸到不同的專用網主機。 ESP 報頭包含一個名為 Security Parameters Index（安全引數索引，SPI）的欄位。 SPI 與明文（plaintext）IP報頭中的目標 IP 地址和 IPSec 安全協議（ESP 或 AH）結合起來用於識別 IPSec 安全關聯（SA）。

  對於到 NAT 的傳入流量，目標 IP 地址必須對映到一個專用 IP 地址。 對於 NAT 專用端的多個 IPSec 對話方，多個 IPSec ESP 資料流的傳入流量的目標 IP 地址是同一個地址。 為了將一個 IPSec ESP 資料流與另一個區分開，目標 IP 地址和 SPI 必須得到跟蹤並對映到某個專用目標 IP 地址和 SPI。

  由於 SPI 是一個 32 位的數字，多個專用網客戶端使用相同 SPI 值的概率很低。 問題在於，您很難確定哪個傳出 SPI 值對應於哪個傳入 SPI 值。

  NAT 無法對映 SPI，因為ESP尾部包含一個訊息驗證雜湊碼（hashed message authentication code，HMAC），它檢驗 ESP 協議資料單元（PDU）的完整性（ESP PDU 包含 ESP 報頭、ESP 有效載荷和 ESP 尾部），SPI 無法在 HMAC 值失效之前改變。

• 無法改變 IKE UDP 埠號。

  IPSec 的某些實現同時使用 UDP 埠 500 來作為源和目標 UDP 埠號。 然而，對於一個位於 NAT 之後的 IPSec 對話方，NAT 會改變初始 IKE 主模式包的源地址。根據具體的實現方式，來自 500 之外的其他埠的 IKE 流量可能會被丟棄。

• IKE UDP 埠對映的 NAT 超時可能導致問題。

  NAT 中的 UDP 對映通常會很快被刪除。 發起者的 IKE 流量在 NAT 中建立了一個 UDP 埠對映，它在初始主模式和快速模式 IKE 協商期間使用。 然而，如果響應者隨後向發起者傳送 IKE 訊息卻沒有提供 UDP 埠對映，那麼這些訊息將被 NAT 丟棄。

• Identification IKE 有效載荷包含嵌入的 IP 地址。

  對於主模式和快速模式協商，每個 IPSec 對話方傳送一個 Identification IKE 有效載荷，其中包括髮送對話方的嵌入 IP 地址。 由於傳送節點的源地址已經被 NAT 改變，該嵌入地址和 IKE 包中的 IP 地址不匹配。 驗證 Identification IKE 有效載荷的 IP 地址的 IPSec 對話方將丟棄該包，並放棄 IKE 協商。

對 IPSec 的 NAT-T 修改概述

NAT-T 對 IPSec 的修改如下：

• ESP 的 UDP 封裝

  UDP 報頭置於外層 IP 報頭和 ESP 報頭之間，用於封裝 ESP PDU。 用於 UDP 封裝的 ESP 流量的埠和用於 IKE 的埠相同。

• 修改過的 IKE 報頭格式

  IPSec NAT-T IKE 報頭包含一個新的 Non-ESP Marker 欄位，它允許接收方區分 UDP 封裝的 ESP PDU 和 IKE 訊息。 在確定存在一箇中間 NAT 之後，支援 IPSec NAT-T 的對話方開始使用新的 IKE 報頭。

• 新的 NAT-Keepalive 包

  這是一個和 IKE 流量使用相同埠的 UDP 訊息，它包含單個位元組（0xFF），用於為傳送到某個專用網主機的 IKE 和 UDP 封裝的 ESP 流量重新整理 NAT 中的 UDP 埠對映。

• 新的 Vendor ID IKE 有效載荷

  這個新的有效載荷包含一個眾所周知的雜湊值，它表明這個對話方能夠執行 IPSec NAT-T。

• 新的 NAT-Discovery (NAT-D) IKE 有效載荷

  這個新的有效載荷包含一個雜湊值，它整合了一個地址和埠號。 在主模式協商期間，IPSec 對話方包括兩個 NAT-Discovery 有效載荷——一個用於目標地址和埠，另一個用於源地址和埠。 接收方使用 NAT-Discovery 有效載荷來發現 NAT 之後是否存在一個經 NAT 轉換過的地址或埠號，並基於被改變的地址和埠號來確定是否有對話方位於NAT之後。

• 用於UDP封裝的ESP傳輸模式和隧道模式的新的封裝模式

  這兩種新的封裝模式是在快速模式協商期間指定的，用於通知 IPSec 對話方應該對 ESP PDU 使用 UDP 封裝。

• 新的NAT-Original Address (NAT-OA) IKE 有效載荷

  這個新的有效載荷包含 IPSec 對話方的原始（未轉換的）地址。 對於 UDP 封裝的 ESP 傳輸模式，每個對話方在快速模式協商期間傳送 NAT-OA IKE 有效載荷。 接收方將這個地址儲存在用於 SA 的引數中。

通過 NAT 使用 IPSec 的問題的 IPSec NAT-T 解決辦法

IPSec NAT-T 通過以下方式解決了通過 NAT 使用 IPSec 的問題：

• 問題： NAT 無法更新上層校驗和。

  解決辦法： 通過在 NAT-OA IKE 有效載荷中傳送原始地址，接收方擁有檢驗解密之後的上層校驗和（源和目標 IP 地址和埠）所需的所有資訊。

• 問題： NAT 無法多路傳輸 IPSec 資料流。

  解決辦法： 通過使用 UDP 報頭封裝 ESP PDU，NAT 能夠使用 UDP 埠來多路傳輸 IPSec 資料流。 跟蹤 ESP 報頭中的 SPI 就不再必要了。

• 問題： 無法改變 IKE UDP 埠號。

  解決辦法： IPSec NAT-T對話方能夠接受來自 500 之外的埠的 IKE 訊息。 此外，為了防止 IKE 敏感（IKE-aware）的 NAT 修改 IKE 包，IPSec NAT-T 對話方在主模式協商期間把 IKE UDP 埠 500 改為 UDP 埠 4500。 為了允許IKE流量使用這個新的 UDP 埠，您可能必須配置防火牆以允許 UDP 埠 4500。

• 問題： Identification IKE有效載荷包含嵌入的 IP 地址。

  解決辦法： 通過在 NAT-OA IKE 有效載荷中傳送原始地址，接收方擁有了可用來在快速模式協商期間檢驗 Identification IKE 有效載荷內容的原始地址。 由於NAT-OA IKE 有效載荷在快速模式協商發生之前沒有傳送，對於驗證主模式期間傳送的 Identification IKE 有效載荷中的 IP 地址的 IPSec 實現，它要麼一定不會執行這個驗證，要麼通過使用另一種機制（比如名稱檢驗）來驗證對話方。

• 問題： IKE UDP 埠對映的 NAT 超時可能導致問題。

  解決辦法： 通過定期傳送 NAT Keepalive 包，用於後續 IKE 協商和 UDP 封裝的 ESP PDU 的 UDP 埠對映同時在 NAT 中得到重新整理。

使用 IPSec NAT-T 的主模式和快速模式 SA 的 IKE 協商例子

增添新的 NAT-D 和 NAT-OA 有效載荷和 UDP 通道型別將修改主模式和快速模式 IKE 協商。 例如，下表顯示了快速模式協商期間，一個使用 Kerberos 身份驗證的基於 Windows 的 IPSec 對話方使用 Vendor-ID 和 NAT-D IKE 有效載荷的情況。 其中用於 IPSec NAT-T 的附加 IKE 有效載荷和訊息變更以粗體顯示。

用於 Kerberos 身份驗證方法的主模式訊息

如果兩個節點都支援 IPSec NAT-T，並且它們之間至少存在一個 NAT，那麼它們將在快速模式協商期間使用 IPSec NAT-T 選項。 假設這兩個對話方之間至少存在一個NAT，結果快速模式協商將如下表所示。

快速模式訊息

在快速模式協商結束時，兩個 IPSec 對話方都擁有彼此的原始地址，並根據需要定期傳送 NAT-Keepalive 包，同時對 ESP PDU 使用 UDP 封裝。