IPSec NAT-T技術

在 NAT 技術和 IPsec 技術的應用都非常廣泛。但從本質上來說，兩者是存在著矛盾的。

1. 從 IPsec 的角度上說， IPsec 要保證資料的安全，因此它會加密和校驗資料。
2. 從 NAT 的觀點來看，為了完成地址轉換，勢必會修改 IP 地址。

         IPSec 提供了點對點的 IP 通信的安全性，但在 NAT 環境下對 IPSec 的支持有限， AH  Protocol是肯定不能進行 NAT 的了，這和 AH 設計的理念是相違背的； ESP  Protocol在 NAT 環境下最多只能有一個 VPN 主機能建立 VPN 通道，無法實現多台機器同時在 NAT 環境下進行ESP 通信。關於 IPSec 在 NAT 環境下的需求問題在 RFC3715 中進行了描述。
       NAT 穿越 (NAT Traversal ， NAT-T) 就是為解決這個問題而提出的， RFC3947 ， 3948 中定義，在 RFC4306 中也加入了 NAT-T 的說明，但並沒廢除 RFC3947 ， 3948 ，只是不區分階段 1 和階段 2 。該方法將 ESP  Protocol封包封裝到 UDP 封包中（在原 ESP  Protocol的 IP 封包頭外添加新的 IP Header和 UDP Header），使之可以在 NAT 環境下使用的一種方法，這樣在 NAT 的內部網中可以有多個 IPSec 主機建立 VPN 通道進行通信。
   AH 封裝： AH 封裝的校驗從 IP Header開始，如果 NAT 將 IP 的 Header改動， AH 的校驗就會失敗，因此我們得出結論，AH 是無法與 NAT 共存的。ESP 封裝的傳輸模式：對於 NAT 來說， ESP 封裝比 AH 的優勢在於，無論是加密還是完整性的校驗， IP Header部都沒有被封包括進去。但是還是有新的問題，對於 ESP 的傳輸模式， NAT  無法更新上層Check Sum。TCP  和  UDP   Header封包含一個Check Sum，它整合了源和目標 IP  地址和Port Number的值。

    當  NAT  改變了某個封包的  IP  地址和（或）Port Number時，它通常要更新  TCP  或  UDP  Check Sum。當  TCP  或  UDP  Check Sum使用了  ESP 來加密時，它就無法更新這個Check Sum。由於地址或端口已經被  NAT  更改，目的地的Check Sum檢驗就會失敗。雖然  UDP  Check Sum是Option的，但是  TCP  Check Sum卻是必需的。
       ESP 封裝的 Tunnel模式：從 ESP  Tunnel模式的封裝中，我們可以發現， ESP  Tunnel模式將整個原始的 IP 封包整個進行了加 ​​密，且在 ESP的 Header外面新加了一層 IP Header，所以 NAT 如果只改變最前面的 IP 地址對後面受到保護的部分是不會有影響的。因此， IPsec 只有採用ESP 的 Tunnel模式來封裝資料時才能與 NAT 共存。

由於完整性Check牽涉到 IP Header部，所以 NAT 無法對其修改，不相容。
ESP 的傳輸模式，因為 TCP 部分被加密， NAT 無法對 TCP Check Sum進行修改，不相容。
ESP 的 Tunnel模式，由於 NAT 改動外部的 IP 而不能改動被加密的原始 IP ，使得只有這種情況下才能與 NAT 共存。

NAT 穿越 (NAT Traversal ， NAT-T)
       以前 NAT 和 IPsec 只能以 1 對 1 的形式共存， NAT-T 打破了這種形式。而且NAT-T 支持 ESP 的傳輸模式。NAT-T 的基本思想：
    將 ESP  Protocol封包封裝到 UDP 封包中（在原 ESP  Protocol的 IP 封包頭外添加新的 IP Header和 UDP Header）。使得 NAT 對待它就像對待一個普通的UDP 封包一樣。而且支持 ESP 的傳輸模式。NAT-T 的基本原理和執行步驟

1. 檢測通信中是否存在 NAT 設備和對方是否支持 NAT-T NC 
2.檢測對方是否支持 NAT-T 是通過交換 vendor ID 載荷來實現的，如果自身支持 NAT-T ，在 IKE 開始交互就要發送這種載荷，載荷內容是“ RFC 3947 ”的 MD5 值，也就是十六進制的“ 4a131c81070358455c5728f20e95452f ”