IPSec NAT 穿越概述

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

一種稱為 IPSec NAT 穿越（NAT-T）的新技術正在由 網際網路工程任務推動小組的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 保護。

IPSec NAT-T 受Windows Server 2003、Microsoft L2TP/IPSec VPN Client（一個免費的 Web 下載組件，它支援運行 Windows 98、Windows Millennium Edition 和 Windows NT 4.0
Workstation 的電腦建立 L2TP/IPSec 串連）以及L2TP/IPSec NAT-T Update for Windows XP and Windows 2000（一個免費的 Web下載組件，它支援運行Windows 2000和Windows XP的電腦建立 L2TP/IPSec 串連）的支援。

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

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

本頁內容

與通過 NAT 使用 IPSec 相關的問題
對 IPSec 的 NAT-T 修改概述
通過 NAT 使用 IPSec 的問題的 IPSec NAT-T 解決辦法
使用 IPSec NAT-T 的主模式和快速模式 SA 的 IKE 協商例子
更多資訊

與通過 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 驗證方法的主模式訊息

主模式訊息	寄件者	有效載荷
1	發起者	Security Association（包含提議）、Vendor ID、Vendor ID（NAT-T功能）
2	響應者	Security Association（包含一個選定的提議）、Vendor ID、Vendor ID（NAT-T 功能）
3	發起者	Key Exchange（包含 Diffie-Hellman 公開密鑰）、Nonce、Kerberos Token（發起者）、NAT-D（目標地址和連接埠）,NAT-D（源地址和連接埠）
4	響應者	Key Exchange （包含 Diffie-Hellman 公開密鑰）、Nonce、Kerberos Token（響應者）、NAT-D（目標地址和連接埠）,NAT-D（源地址和連接埠）
5（已加密）	發起者	Identification、Hash（發起者）
6（已加密）	響應者	Identification、Hash（響應者）

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

快速模式訊息

快速模式訊息	寄件者	有效載荷
1 (已加密)	發起者	Security Association (包含建議，包括對“UDP 封裝的隧道”或“UDP 封裝的傳輸隧道”模式的選擇)、Identification（包含安全流量描述）、Nonce、NAT-OA
2 (已加密)	響應者	Security Association（包含一個選定的建議）、Identification（包含安全流量描述）、Nonce、NAT-OA
3 (已加密)	發起者	Hash
4 (已加密)	響應者	Notification（通知）

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