IPsec ×××、NAT衝突輕鬆解決

AH協議爲IP通信提供數據源認證、數據完整性和反重播保證，它能保護通信免受篡改，但不能防止竊聽，適合用於傳輸非機密數據。AH的工作原理是在每一個數據包上添加一個身份驗證報頭。AH報頭位置在IP報頭和傳輸層協議報頭之間，見下圖：
    
● Encapsulating Security Payload（ESP）協議結構：ESP爲IP數據包提供完整性檢查、認證和加密，可以看作是"超級 AH"， 因爲它提供機密性並可防止篡改。ESP可以單獨使用，也可以和AH結合使用。一般ESP不對整個數據包加密，而是隻加密IP包的有效載荷部分，不包括IP頭。但在端對端的隧道通信中，ESP需要對整個數據包加密。ESP報頭如下所示：
　　
●Internet Key Exchange Protocol（IKE）協議結構：Internet 密鑰交換 (IKE) 協議是 IPsec 安全關聯（SA）在協商它們的保護套件和交換籤名或加密密鑰時所遵循的機制。IKE 定義了雙方交流策略信息的方式和構建並交換身份驗證消息的方式。IKE 是由另外三種協議（ISAKMP：Internet安全關聯和密鑰管理協議、Oakley 和 SKEME）混合而成的一種協議。IKE使用了兩個階段的ISAKMP：第一階段，協商創建一個通信信道（IKE SA），並對該信道進行驗證，爲雙方進一步的IKE通信提供機密性、消息完整性以及消息源驗證服務；第二階段，使用已建立的IKE SA建立IPsec SA。

二．IPsec與NAT的衝突問題分析

IPsec的設計和NAT存在衝突，它主要表現在以下幾點：

(1)IPsec中的AH協議和NAT存在衝突．AH用驗證算法保護包括IP頭在內的整個
IP報文不被修改，如果到達執行NAT功能的網關，NAT需要修改IP報文，經過修改的報文到達對方後因無法通過驗證，會被丟棄．ESP協議由於只保護IP載荷，所以如果修改IP地址不會影響通信．IPsec和NAT的校驗也存在衝突．TCP／UDP／SCTP中校驗都是依賴於IP源目的地址的，它需要計算“僞頭”(即IP源、目的地址加上TCP頭)，通過NAT和NAPT後由於地址和端口被修改，校驗要重新計算．如果對源報文進行了完整性或密碼保護，報文到達對方後，驗證就會出現不一致，對方IPsec將丟棄此報文，除非IPsec使用通道模式、IPsec／GRE模式或不計算校驗才能避免報文丟棄．即使這樣也仍然存在問題，在IKE中最普遍最基本的驗證方法就是預共享密鑰，這種方法依賴於源IP地址，所以也和NAT衝突，解決辦法就是使用另外的驗證方法，如X．509．

(2)IKE的協商端口固定爲500，這和NAPT有衝突．當多個主機在一臺NAT設備後與
同一目的主機協商IKE SA 時，從這一目的主機來的報文需要由NAPT分路到不同的源主機，典型的做法是轉換內部主機IKE的UDP源端口．但是，在重建密鑰時會出現不可知錯誤，除非修改的源端口在重建密鑰時用作目的端口．

(3)當多個主機在一個NAT設備後與同一個目標主機協商安全策略庫(SPD)的內容時，
很可能發送到錯誤的SA（安全關聯） 中，因爲對目標主機來說，這些SA 好象是相同的，它們都是存在於同一對主機間．

三．IPSec與NAT共存之解決方案

    NAT廣泛應用家庭，賓館，網吧，如果不解決這個問題，許多使用IP隧道模式的××× 的
客戶就無法從家或辦公室接入互聯網，同樣，使用IPsec通道模式保護的TCP／UDP流也無法進行

對等體到對等體、server到server的交換． 針對這些問題可以考慮以下解決方法：

    共存方案1：IPsec協議或NAT做一定修改

    如果能夠在一個設備中實現IPsec和NAT，那麼，將NAT 放在前面處理，而
IPsec放在後面處理，就可以避免衝突．但有些情況下NAT不能放在IPsec前處理．

    共存方案2：使用NAT的替代協議RSIP

     用RSIP替代NAT，解決IP地址短缺問題．RSIP是將一個擁有合法IP的服務
器放在私有地址域內，和NAT工作原理不同，它不是採用替換IP來工作，而是允許域內主機直接同時在幾個地址域內通信．在通信過程中，RSIP對IP載荷做的修改不會削弱IPsec這類對NAT敏感的協議的功能，當一個RSIP客戶機想要在自己所在地址域外通信時，首先在RSIP網關上登記，RSIP網關給它分配一個合法的IP地址(或一個IP地址和端E1)，RSIP客戶使用這個地址做爲源地址和外部設備通信，直到這個地址過期或被更新．實際處理起來並不是這麼簡單，RSIP還要將此數據報文封裝在源地址爲其私有IP的報頭內，封裝方式可以用IP—in—IP，GRE或L2TP． 數據報文首先傳給RSIP網關，網關將外面的報頭脫掉，然後將報文發出去．

　　然而，RSIP也存在一定的問題，RSIP使用的是一個公有端口分路進來的報文流，當多個內部主機使用一個RSIP網關和同一個外部主機傳送ESP時，由於ESP流是加密的，會出現分路衝突問題，所以，必須要使用另外的標識． 幸運的是每個安全聯盟都有不同的SPI，由於SPI的唯一性只針對一個主機，爲了確保對一個RSIP網關的唯一性，選用SPI+協議(AH或ESP)+目的IP作爲標識．同樣的問題會出現在IKE協商安全聯盟時，由於使用知名端口 500，當多臺主機使用一個RSIP網關時，可能發生衝突，所以，這裏使用另外的一個新標識：初始化cookie+目標端口+目標地址． 在重建密鑰時可能仍然會出現問題，因爲通常重建密鑰用到的cookie是和以前數據流中所用的不同．使用RSIP替代NAT解決了分路和SPD重疊問題，並且和類似隱藏IP地址這樣的協議都兼容，所以，既適合於企業也適合於家庭使用．通過將IKE和IPsec封在隧道里，RSIP避免了對IKE和IPsec協議的修改，既適合現有的AH和ESP協議也適合隧道和傳輸兩種方式．但是，爲了解決IKE重建密鑰時的分路傳輸問題，RSIP需要改動IKE的源端口，這就不能保證和現有的IPsec實現兼容．

    共存方案3：使用UDP封裝ESP載荷

     這種方法的核心思想是使用UDP封裝ESP，報文格式如圖1所示，當報文交
給網關後，網關照舊做NAT、NAPT轉換，它不會破壞ESP的加密或驗證．之所以使用UDP是因爲UDP提供了最小標準的封裝，8比特就夠了，如果換做TCP封裝則需要20比特而且UDP是面向無連接協議，TCP的建鏈和拆鏈過程會引入諸如RESET***這類影響IPsec性能的負效果．
          
                           

圖1 ESP封裝格式

　　這種方法只適用ESP協議，既然ESP被UDP封裝了，就要求網關到網關、客戶到客戶、網關到客戶都能相互識別並將UDP頭脫去，對於同一廠家的產品可能還能實現，但是對不同廠家在實現上會有些困難．解決的方法是IKE對等體將交換一個定義好的值，來確定對方是否支持UDP ESP封裝，如果發現雙方都支持，對等體就會探測負荷中是否運用了這種封裝．由於IKE對等體已經使用了UDP的500號端口，所以這裏也沿用這一端口，可以避免在防火牆的過濾規則中再多開一個漏洞．發送者會將UDP後第一個8比特設置爲0，該位置在IKE中是初始cookie的位置，如圖2所示．接收者就可以在都使用500號端口的情況下區分是IKE還是UDP封裝下的ESP 。
　　
　　
　　
                  

圖2 ESP和IKE封裝格式比較

 

    總結

   綜上所述，爲了解決IPsec和NAT 的共存問題，主要有三種解決方法，一種是對IPsec協議或NAT做一定修改，但實現需要很小心，因爲很容易引入實現帶來的錯誤；第二種是使用NAT的替代協議RSIP，這種方法較爲全面地解決了IPsec和NAT的兼容問題，但是，它的實現相對複雜，而且需要對原有設備做較大改動；第三種是使用UDP封裝ESP載荷，這種方法不需要對IPsec或IKE做修改，實現最爲簡單。