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做修改，实现最为简单。