基于IPSec技术的解决方案
发布: 2006-4-02 03:29 | 作者: Allan | 来源: 《深圳赛佛莱特科技有限公司》技术版
经过多年的讨论、竞争和大量草案的出台，富有献身精神的开发者们的艰苦工作所得的结果终于能够交付使用了——可协作IPSec(IP Security，IP安全)产品已经成为现实。你不必再局限于单一厂商的解决方案，跨越Internet的低价格外部网终于浮出了水面。在写作本文的时候，ICSA认证了七种基于目前使用共享前保密RFC的IPSec兼容产品。（完全列表在www.ncsa.com/services/product_cert/ipsec)。但是实现一个基于IPSec的解决方案到底意味着什么呢？
在我们设在Syracuse大学的Real World实验室中，我们使用以下产品建立了基于共享前保密原则的IPSec管道，这些产品是：
·Check Point软件科技公司的FireWall－14.0；
·Shiva公司的LanRover VPN Gateway；
·TimeStep公司的Permit 4520 ；
·VPNet科技的VSU－1010 V2.0b25。
我们终于可以使所有这些产品互相通信了，干这些活可不简单，而且系统也并不具有多高的鲁棒性。在这个过程中出现了大量的问题，其中包括管道穿过子网时的基本管道构造问题。我们在配置、大量具体实现的细节、指定IPSec协议详细控制参数等方面遇到了问题。在单一厂商进行实现时不相干的事情在多厂商配置来实现管道时也会引发从不对称性到完全失败等各种问题。
值得注意的是，你可能要在多厂商环境中放弃一些专有特性。比如，VPNet的VSU1010支持Stac压缩，但是它只在VPNet环境中支持这一特性。统一管理看起来也是个问题，VPN（Virtual Private Network，虚拟专用网）的一个目标是让一些分散的组织安全地通过Internet从而实现外部网访问，但这样就只能管理VPN的一端而不是全部。
一般来说，IPSec管道在每个IPSec网关通过定义两个终点（或者子网）来配置。使用加密和验证算法，VPN中的每个IPSec网关应用共享前保密原则。这些信息必须精确匹配以使得网关之间可以成功地进行协商。对于单主机VPN来说配置比较简单，而对于子网来说就要复杂一些了。
子网－特殊问题
管道化子网造成了一个特殊的问题，即如何在IPSec协商中处理ID。被保护网络的所有IP地址都要正确地格式化，否则快速模式（Quick Mode）协商就会因为未知ID而失败。保护单个主机时，例如10.2.2.5，两个网关的配置相当简单。在IKE安全结交（Security Association, SA）协商中，IPSec网关把它们自己的IP地址作为ID，但是在第二项中，设备的地址就要使用这个ID加以保护。例如，创建一个VPN在10.2.2.5和10.3.3.5之间传送流量，TimeStep的Permit配置成保护从10.2.2.5出去的流量。我们让Permit向10.3.3.5的VSU1010发送数据。在快速模式中，Permit发送10.2.2.5作为ID，VSU发送10.3.3.5作为ID。为了建立整个子网，每个VPN网关的子网地址——子网掩码对都必须被精确定义。
地址10.2.2.0/255.255.255.0和10.3.3.0/255.255.255.0定义了我们要保护的子网，并且这些地址对必须正确地加入到每个网关中去。即使更改一个公共配置，例如在某个网关上修改地址的子网掩码，如10.2.2.5/255.255.255.0的子网掩码，也会导致VPN失效，因为在IPSec SA协商中发送的ID和目的网关的IP地址/子网掩码不匹配。
在目前的IPSec修正版本中可变的子网掩码(如10.2.2.5/255.255.255.252)不能工作。如果要分割子网而组成特定的VPN，你必须使用单一厂商环境，或者等待基于ICSA1.1的产品的出现。
Shiva的LanRover VPN网关是个例外。我们用这个产品在子网10.1.1.0/255.255.255.0和主机10.2.2.5之间配置了一个VPN，用Permit在主机10.3.3.5和主机10.1.1.5/255.255.255.255之间建立了一个VPN。这个配置当然会失败，但是我们发现我们可以从10.2.2.5 来ping Shiva后的任何IP地址，但是只能ping到Permit 4520后面的10.2.2.5。这个不对称性体现在特定的Shiva－Permit联合体上，也突出了多厂商配置情况下的缺陷。
Permit保护它后面网络的安全，而Shiva后面的网络则是完全开放的。我们重新给Shiva配置了一个本地地址10.1.1.5/255.255.255.255，并只允许访问这台主机。在快速模式交换中，网络地址被用作ID，但是出于安全目的如何使用这些ID则要因厂商而异。测试中Permit可以在这个配置下工作，而VSU则不行。
策略问题
有两个策略范例可用——特定设备:在这里，安全策略为VPN网关而定义；特定VPN：在这里策略为单一VPN而定义。CheckPoint、Shiva和VPNet实现的策略范例是在每VPN基准之上指定安全参数，TimeStep则为每个设备定义策略。
每VPN策略范例的好处是可以明确定义每个VPN节点的参数。VPN对于每个管道只能提议或接受一个安全参数集合。例如，如果在美国境内，就可以使用3DES加密算法或更长的密钥，但是如果要使用国际性的安全VPN，那么就要限制在DES 56这样短一些的密钥。
基于设备的策略提供了更好的管理灵活性，但是需要在构造策略时加倍小心。例如，TimeStep的Permit Enterprise允许对单一设备指定多个安全策略。在初始化IKE协商时，如果远程节点发送一个提议过来，Permit Enterprise要检查这个建议是否可接受并执行相应的动作。当Permit初始化一个VPN时，它发送多个建议来选择远程节点。选择过程因厂商而异。Permit采用自顶向下的方式查询它的提议列表，从中找出第一个匹配的提议来。
需要特别指出的是，你需要了解厂商的日志工具，在设置VPN的时候有多少调试工具就打开多少，而在VPN建立起来之后就全部关掉它们。你要从两个方面测试VPN会话：不对称VPN配置是可能的并且会导致一些很晦涩的问题。你还要决定网关在IKE协商中缺省采用哪种模式：主模式（Main Mode）还是侵略性模式（Aggressive Mode）。TimeStep缺省采用侵略性模式；如果其他网关期望采用主模式，那么这个VPN的构成就会出现问题。此外要为IKE和IPSec二者设置适当的失败重试次数。
使用IKE的IPSec的多个模式
IKE是一个密钥管理协议，为安全交换密钥而研制，被其他加密和验证方案所广泛采用。IPSec草案要使用DES或3DES来支持数据加密，要使用MD5和SHA－1来进行验证。IKE是有关协商安全结交（SA）和密钥的框架结构。
IKE使用两种模式。主模式（Main Mode）为主机初始化IPSec会话，提供身份保护，但是尚需进一步完善。侵略性模式（Aggressive Mode）不提供身份保护，但是它要快一些。所有IPSec设备必须支持主模式，侵略性模式是可选项。请注意，IPSec SA协商和IKE SA无关。
主模式
IKE会话开始于发起者向响应者发出一个或多个提议。提议定义何种加密和验证协议是可以接受的，多长的密钥起作用，以及是否强制完善转发保密性等等。多个提议可以一次发出。节点间的初次信息交换将建立基本安全策略。发起者提议它希望采用的加密和验证算法。响应者选择合适的提议（我们将假设必有一个提议被选中），并把它的选择结果发送给发起者。下次交换传送Diffie－Hellman公钥和其他数据。所有未来的协商都要用IKE SA加密。第三次交换验证ISAKMP会话。一旦IKE SA建立起来，IPSec协商（快速模式）就可以开始了。
侵略性模式
侵略性模式把IKE SA协商压缩为三个包，包含发起者进行SA所需要的所有数据。响应者发送提议、密钥和ID，并在下一包中验证该会话。发起者回复对这次会话的验证。协商比较迅速，而且发起者和响应者的ID用明文发送。
除了协商必须在IKE SA保护下进行这一点外，快速模式（Quick Mode）IPSec协商, 或者称之为快模式，和侵略性模式IKE的协商过程相似。快模式为数据加密协商SA，为IPSec SA管理密钥交换。
在我们设在Syracuse大学的Real World实验室中，我们使用以下产品建立了基于共享前保密原则的IPSec管道，这些产品是：
·Check Point软件科技公司的FireWall－14.0；
·Shiva公司的LanRover VPN Gateway；
·TimeStep公司的Permit 4520 ；
·VPNet科技的VSU－1010 V2.0b25。
我们终于可以使所有这些产品互相通信了，干这些活可不简单，而且系统也并不具有多高的鲁棒性。在这个过程中出现了大量的问题，其中包括管道穿过子网时的基本管道构造问题。我们在配置、大量具体实现的细节、指定IPSec协议详细控制参数等方面遇到了问题。在单一厂商进行实现时不相干的事情在多厂商配置来实现管道时也会引发从不对称性到完全失败等各种问题。
值得注意的是，你可能要在多厂商环境中放弃一些专有特性。比如，VPNet的VSU1010支持Stac压缩，但是它只在VPNet环境中支持这一特性。统一管理看起来也是个问题，VPN（Virtual Private Network，虚拟专用网）的一个目标是让一些分散的组织安全地通过Internet从而实现外部网访问，但这样就只能管理VPN的一端而不是全部。
一般来说，IPSec管道在每个IPSec网关通过定义两个终点（或者子网）来配置。使用加密和验证算法，VPN中的每个IPSec网关应用共享前保密原则。这些信息必须精确匹配以使得网关之间可以成功地进行协商。对于单主机VPN来说配置比较简单，而对于子网来说就要复杂一些了。
子网－特殊问题
管道化子网造成了一个特殊的问题，即如何在IPSec协商中处理ID。被保护网络的所有IP地址都要正确地格式化，否则快速模式（Quick Mode）协商就会因为未知ID而失败。保护单个主机时，例如10.2.2.5，两个网关的配置相当简单。在IKE安全结交（Security Association, SA）协商中，IPSec网关把它们自己的IP地址作为ID，但是在第二项中，设备的地址就要使用这个ID加以保护。例如，创建一个VPN在10.2.2.5和10.3.3.5之间传送流量，TimeStep的Permit配置成保护从10.2.2.5出去的流量。我们让Permit向10.3.3.5的VSU1010发送数据。在快速模式中，Permit发送10.2.2.5作为ID，VSU发送10.3.3.5作为ID。为了建立整个子网，每个VPN网关的子网地址——子网掩码对都必须被精确定义。
地址10.2.2.0/255.255.255.0和10.3.3.0/255.255.255.0定义了我们要保护的子网，并且这些地址对必须正确地加入到每个网关中去。即使更改一个公共配置，例如在某个网关上修改地址的子网掩码，如10.2.2.5/255.255.255.0的子网掩码，也会导致VPN失效，因为在IPSec SA协商中发送的ID和目的网关的IP地址/子网掩码不匹配。
在目前的IPSec修正版本中可变的子网掩码(如10.2.2.5/255.255.255.252)不能工作。如果要分割子网而组成特定的VPN，你必须使用单一厂商环境，或者等待基于ICSA1.1的产品的出现。
Shiva的LanRover VPN网关是个例外。我们用这个产品在子网10.1.1.0/255.255.255.0和主机10.2.2.5之间配置了一个VPN，用Permit在主机10.3.3.5和主机10.1.1.5/255.255.255.255之间建立了一个VPN。这个配置当然会失败，但是我们发现我们可以从10.2.2.5 来ping Shiva后的任何IP地址，但是只能ping到Permit 4520后面的10.2.2.5。这个不对称性体现在特定的Shiva－Permit联合体上，也突出了多厂商配置情况下的缺陷。
Permit保护它后面网络的安全，而Shiva后面的网络则是完全开放的。我们重新给Shiva配置了一个本地地址10.1.1.5/255.255.255.255，并只允许访问这台主机。在快速模式交换中，网络地址被用作ID，但是出于安全目的如何使用这些ID则要因厂商而异。测试中Permit可以在这个配置下工作，而VSU则不行。
策略问题
有两个策略范例可用——特定设备:在这里，安全策略为VPN网关而定义；特定VPN：在这里策略为单一VPN而定义。CheckPoint、Shiva和VPNet实现的策略范例是在每VPN基准之上指定安全参数，TimeStep则为每个设备定义策略。
每VPN策略范例的好处是可以明确定义每个VPN节点的参数。VPN对于每个管道只能提议或接受一个安全参数集合。例如，如果在美国境内，就可以使用3DES加密算法或更长的密钥，但是如果要使用国际性的安全VPN，那么就要限制在DES 56这样短一些的密钥。
基于设备的策略提供了更好的管理灵活性，但是需要在构造策略时加倍小心。例如，TimeStep的Permit Enterprise允许对单一设备指定多个安全策略。在初始化IKE协商时，如果远程节点发送一个提议过来，Permit Enterprise要检查这个建议是否可接受并执行相应的动作。当Permit初始化一个VPN时，它发送多个建议来选择远程节点。选择过程因厂商而异。Permit采用自顶向下的方式查询它的提议列表，从中找出第一个匹配的提议来。
需要特别指出的是，你需要了解厂商的日志工具，在设置VPN的时候有多少调试工具就打开多少，而在VPN建立起来之后就全部关掉它们。你要从两个方面测试VPN会话：不对称VPN配置是可能的并且会导致一些很晦涩的问题。你还要决定网关在IKE协商中缺省采用哪种模式：主模式（Main Mode）还是侵略性模式（Aggressive Mode）。TimeStep缺省采用侵略性模式；如果其他网关期望采用主模式，那么这个VPN的构成就会出现问题。此外要为IKE和IPSec二者设置适当的失败重试次数。
使用IKE的IPSec的多个模式
IKE是一个密钥管理协议，为安全交换密钥而研制，被其他加密和验证方案所广泛采用。IPSec草案要使用DES或3DES来支持数据加密，要使用MD5和SHA－1来进行验证。IKE是有关协商安全结交（SA）和密钥的框架结构。
IKE使用两种模式。主模式（Main Mode）为主机初始化IPSec会话，提供身份保护，但是尚需进一步完善。侵略性模式（Aggressive Mode）不提供身份保护，但是它要快一些。所有IPSec设备必须支持主模式，侵略性模式是可选项。请注意，IPSec SA协商和IKE SA无关。
主模式
IKE会话开始于发起者向响应者发出一个或多个提议。提议定义何种加密和验证协议是可以接受的，多长的密钥起作用，以及是否强制完善转发保密性等等。多个提议可以一次发出。节点间的初次信息交换将建立基本安全策略。发起者提议它希望采用的加密和验证算法。响应者选择合适的提议（我们将假设必有一个提议被选中），并把它的选择结果发送给发起者。下次交换传送Diffie－Hellman公钥和其他数据。所有未来的协商都要用IKE SA加密。第三次交换验证ISAKMP会话。一旦IKE SA建立起来，IPSec协商（快速模式）就可以开始了。
侵略性模式
侵略性模式把IKE SA协商压缩为三个包，包含发起者进行SA所需要的所有数据。响应者发送提议、密钥和ID，并在下一包中验证该会话。发起者回复对这次会话的验证。协商比较迅速，而且发起者和响应者的ID用明文发送。
除了协商必须在IKE SA保护下进行这一点外，快速模式（Quick Mode）IPSec协商, 或者称之为快模式，和侵略性模式IKE的协商过程相似。快模式为数据加密协商SA，为IPSec SA管理密钥交换。