在 NAT 技術和 IPsec 技術的應用都非常廣泛。但從本質上來說,兩者是存在著矛盾的。
-
從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 封包整個進行了加 <span "times="" mincho'","serif";mso-bidi-font-family:="" ms="" new="" roman";color:black'="" style="font-family: "; font-size: 9.0pt;" lang="EN-US">密,且在 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 的基本原理和執行步驟
- 檢測通信中是否存在NAT 設備和對方是否支持 NAT-T NC
2.檢測對方是否支持 NAT-T 是通過交換 vendor ID 載荷來實現的,如果自身支持 NAT-T ,在 IKE 開始交互就要發送這種載荷,載荷內容是“ RFC 3947 ”的 MD5 值,也就是十六進制的“ 4a131c81070358455c5728f20e95452f ”