rfcrfc2764.txt

本程序为在linux下实现FTP传输文件的实现

仅仅可以应用于后者，因为它们所利用的工具（如路由协议背载）只能由ISP访问，不能由用户
访问，甚至由于CPE节点联合管理问题，连那些拥有和操作CPE的ISP主机也不能访问。本文将指
出那些技术仅仅适用于网络VPN。
2.3 VPN和外联网
    外联网的概念是指两个或者两个以上的公司网络可以互相访问对方有限的数据信息。例如，
一个设备制造商可能用一个外联网为它的供应商提供查询数据库，允许后者查询元件价格和用
途，以及定购情况。再如，在联合软件开发中，公司A允许公司B的一个开发小组访问它的操作
系统代码，公司B允许公司A的一个开发小组访问它的安全性软件。注意，访问策略可以做到任
意复杂，例如，公司B可以对自己的安全性软件作出一些内部访问限制，为适应出口控制法律，
只允许特定的地理位置进行访问。
    外联网的关键特性就是控制访问者和被访问的数据，这是一个策略决策问题，策略决策一
般在不同域的互联点上受到加强，例如专网和Internet之间，或者公司的软件测试实验室和公
司其余的网络之间。这种加强可以通过防火墙、带有访问表功能和应用网关的路由器或者任何
其他任何能够执行传输策略应用的设备来完成，策略控制除了可以实现在公司网络之间，还可
以实现在公司网络的内部。网络间的互联也可以是双向链接的集合，或者就是一个独立的网络
－－由工业组织维护的网络，这个单独的网络本身也可以是一个VPN或者物理网络。
    VPN的引入不需要改变这个模型，策略可以应用于两个VPN之间，或者在VPN和Internet之间，
就像以前没有VPN一样。例如，两个VPN可以互联，每个都有自己的策略控制，通过一个防火墙，
查看进来的流量是来自于另一个VPN还是Internet。
    VPN的这个模型提供了一种与包传输基础模式不同的策略，例如，路由器可能把语音流量直
接路由到ATM VCC上以保证QoS，非本地内部公司流量路由到安全隧道里，其他流量路由到
Internet链路上，在过去，安全隧道是帧中继电路，现在它们也可以是安全IP隧道或者MPLS标
记交换通道。
    当然还可能有其他一些VPN模型，例如，可以有一个应用流集映射进VPN的模型，由于网络
管理员给出的策略规则会相当复杂，在策略规则库中使用的不同应用流集的数目，也就是VPN
的数目，就会变得很大，可能造成多重交搭的VPN，然而，引入这种新的复杂性到网络中却实在
获得不了什么好处。VPN应该看成是物理网络的直接模拟，这样可以充分利用现有的协议和规程
以及现有的网管和用户技术。

3.0 隧道技术：
    如2.1所述，VPN需要用某些形式的隧道机制来实现，本小节讨论VPN隧道机制的要求，比较
链路层协议的特性和现有隧道协议的特性，提供协议差异比较的基础，突出隧道协议特点，更
好的支持VPN环境运作。
    连接两个VPN端点的IP隧道是一个基本的构件，基于它各种不同的VPN才得以建立。IP隧道
运行在IP骨干网之上，发送到隧道中的数据流量对IP骨干网络是不透明的，在效果上IP骨干网
用作了链路层技术，隧道形成了点到点连接。
    VPN设备可以终止多个IP隧道，在这些隧道和不同的网络接口之间以各种方式转发数据包，
在后面不同类型VPN的讨论中，数据包在接口（如桥或者路由器）间的转发方式是造成类型差异
的主要原因，非常类似于以前网络设备的特性。两端口转发器直接转发数据包，不检查包的内
容；桥使用MAC层信息来转发数据包；而路由器用第三层地址信息来转发，如本文后面所述，这
三个场合都有和VPN的直接相似性。要注意，IP隧道被视为另一种链路，可以和其他链路串连，
绑定在桥转发表中，或者绑定在IP转发表中，具体根据VPN的类型而定。
    下面的章节就看一看建设不同类型VPN的基础构件－－IP隧道协议。
3.1 VPN的隧道协议要求
    有许多种IP隧道机制，IP/IP，GRE、L2TP、IPSec、MPLS。虽然有些协议没有被视作隧道协
议，但是它实际上做的也是建立隧道的事情，都是从封装包的地址域提取转发信息，允许不透
明帧作为包载荷通过IP网络传输。
    然而要注意的是，MPLS和其他隧道协议有所不同，它是一种专门的链路层协议，MPLS只能
在MPLS网络范围内应用，而IP可以伸展到任何可以达到的地方，基于MPLS隧道建立的VPN机制从
定义上就不能伸展到MPLS网络之外，就像基于ATM机制如LANE不可以伸展出ATM网络一样。可是，
MPLS可以横跨许多不同的链路层技术，就像IP网络，它的范围也不是限定在特定的链路层之上。
现已经提出了许多机制允许基于MPLS网络建设交互VPN。
    VPN隧道机制有好多要求，当前的隧道机制还没有完全满足这些要求，它们包括：
3.1.1 复接
    在相同的两个IP端点之间可能要求建立多个VPN隧道，基于网络的VPN就有这种需求，每个
端点支持多个用户。在两个相同的物理设备上，不同用户的数据通过各自独立的隧道，应该有
一个复接域标识数据包所属的那个隧道，或者以类似的方式共享一个隧道，这样可以减少隧道
建立的负担和时延。在现有的IP隧道机制中，L2TP（通过隧道标识和会话标识）、MPLS（通过
标签）和IPSec（通过安全参数索引）有复接机制；严格地讲，GRE没有复接域，但是它的钥匙
域可以用来认证信息包源，有时可以作为复接域；IP/IP没有复接域。
    IETF和ATM论坛都标准化了全局唯一的标识符VPN－ID，用来标识一个VPN。VPN－ID可以放
在控制平面，在隧道建立时间中绑定一个隧道和VPN，或者放在在数据数据平面，基于数据包来
标识该数据所关联的VPN。在数据平面中，VPN封装头可以用在MPLS、MPOA和其他一些隧道机制
上，为不同VPN在一个隧道上收集数据包。在这种情况下，VPN－ID显式地包含在每一个数据包
中，隧道不需要特别的复接域；在控制平面上，VPN－ID可以包含在任何隧道建立信令协议上，
让隧道（如，由SPI域标识）和VPN关联，在这种情况下，不需要在每个数据包中包含VPN－ID，
5.3.1中将做进一步讨论。
3.1.2 信令协议
    在隧道建立之前端点必须知道一些配置信息，如远端IP地址以及隧道所要求的相关隧道属
性（如安全水平），一旦这些信息配置完成，隧道便可以通过两种方式完成建立，可以通过管
理操作，或者也可以通过信令协议，信令协议可以动态建立隧道。
    管理操作的例子如用SNMP MIB配置不同隧道参数，如MPLS标记、IP/IP或者GRE隧道的源地
址，L2TP的隧道标识、会话标识，或者IPSec的安全连接参数。
    信令协议可以减轻管理负担，在许多场合下这非常重要，它可以减少需要配置的工作量，
如果VPN横跨多个管理域，可以减少管理协同的必要。例如，上面描述的复接域的值，节点分配
时为本地化，通过信令协议可以在发布后仍保持本地化，而不是首先配置在管理站，然后发布
到相关节点。信令协议也允许移动节点或者间歇连接的节点按需建立隧道。
    在VPN环境下，信令协议应该允许VPN－ID的传输，让产生的隧道关连到特定的VPN，也应该
允许隧道属性交换和协商，例如帧序列和多协议传输的使用，注意，信令协议的角色只是协商
信道属性，而不是运载隧道如何使用的信息，如隧道中的帧是在层2转发还是在层3转发，（就
像Q.2931 ATM信令－－除LANE的又一种建立IP逻辑子网络的信令）。
    在各种IP隧道协议中，下列协议支持适应此目的的信令协议，L2TP（L2TP控制协议）、IPSec
（IKE协议）、和GRE（移动IP隧道)。还有两种MPLS信令协议可以用来建立LSP隧道，一个是MPLS
标签分布协议（LDP）的扩展，叫做受限路由LDP，CR－LDP，另一个是LSP隧道的资源保留协议
RSVP的扩展。
3.1.3 数据安全
    VPN隧道协议必须支持用户所要求的任何档次的安全，包括认证和不同强度的加密能力。除
了IPSec，其他的协议都没有内在的安全机制，它们依赖于基础IP骨干网络本身的安全特性。特
别是，MPLS依赖显式的标记交换通道来保证它的信息包不会传错方向，其他的隧道协议可以用
IPSec来提供安全保障。对于是实现在非IP骨干网上的VPN（如，MPOA，FR和ATM VC），数据安
全隐式的由层2交换结构提供。
    从总体来看，VPN不仅仅包括隧道的安全能力，还包括在边缘路由器中信息包是如何进入隧
道的，例如，用虚拟路由器实现的VPRN中，独立的路由表、转发表实例保证了VPN之间的隔离，
一个VPN上的数据包，不会错误的路由到另一个VPN的隧道上，因为这些隧道对于第一个VPN的转
发表是不可见的。
    如果VPN端点使用某些形式的信令机制和另一端点动态建立隧道，那么就要求认证试图建立
隧道的实体，IPSec为了这个目的形成了一系列的方案，例如，允许使用预共享密钥来进行认证
对方，也可以用数字签名和身份验证。其他一些隧道协议的认证能力比较弱，但在一些情况下
可能根本就不需要认证，例如，如果隧道是预分配而不是动态建立的，或者如果系统根本不需
要信任模型。
    现在IPSec ESP可以建立SA即能支持加密又能支持认证，或者二者都支持，然而如果不用认
证和加密，协议也可以不使用SA。在一个VPN环境中，这个"NULL/NULL"选项是非常有用的，
因为可能有时仅仅需要协议的其他方面（如，支持隧道和复接）可能都是必需的。在效果上，
"NULL/NULL"可以视为另外一种水平的数据安全。
3.1.4 多协议传输
    许多应用中，VPN可以承载不透明多协议数据，因此，隧道协议必须能够支持多协议传输。
L2TP可以传输PPP包，而PPP包可以运载多协议，因此L2TP可以传输多协议。GRE也提供隧道协议
标识，而IP/IP和IPSec隧道没有这样的协议标识域，因而只能建立IP协议隧道。
    扩展IPSec协议集允许传输多协议是完全可能的，例如，可以通过扩展IPSec的信令组件IKE
来实现IPSec的多协议传输，指示隧道里传输的协议类型，或者在每个隧道包里运载一个包复接
头，（例如，一个LLC/SNAP头或者GRE头）等等。这种方法类似ATM网络，它使用信令来指示VCC
里面的封装，VCC发送的数据包使用一个LLC/SNAP头，或者直接放在AAL5载荷中，后者就是VC
复接。
3.1.5 帧序列
    用户所要求的QoS属性之一便是VPN帧序列，类似于物理租用线或专线的特性。特定端到端
协议和应用的有效操作可能需要帧序列，为了实现帧序列，隧道机制必须支持序列域，L2TP和
GRE都有这样一个域，IPSec有一个序列号码域，但是它是由接收者执行反重播检验，不是为了
保证数据包的有序传送。
    扩展IPSec允许使用已有的序列域来保证有序包传送是完全可能的，例如，用IKE协商来确
定序列是否使用，定义保留包序列的端点行为。
3.1.6 隧道维护
    VPN端点必须监视VPN隧道的运作，保证连接不丢失，如果发生意外应该采取适当的措施（如
路由重计算）。
    有两种可能的方法，一种是让隧道协议自身周期性地检查隧道连接，提供显式的失败指示，
例如，L2TP有一个保持存活机制选项来检测不运作的隧道。
    另一种方法不需要隧道协议自身来执行这个功能，而是依赖于一些外部机制来确定连接的
丢失，例如路由协议RIP和OSPF运行在一个隧道上，在一定的周期里侦听到邻通道的失败后，便
在路由协议上报告隧道的关闭。还有一种方法是不断的执行ICMP ping，这也可以确保隧道运作
特性，因为隧道本身也是在同一个IP骨干网上运行。
    当隧道动态建立时，我们需要了解动态和静态隧道信息的不同，一个隧道建立之前，节点
需要知道一些静态信息，例如远端的验证，所发起或者接受的隧道的属性等等。一般这都是配
置操作，作为建立隧道的信令交换结果，在每一个端点都形成了一些动态状态，如复接域的值，
密钥等，例如，在IPSec中，SA建立后，在它生存时间里的密钥也得以建立。
    建立动态隧道时将会用到不同的策略，一种是数据驱动机制，当数据需要传输时，就启动
隧道建立，没有数据传输，就发出隧道超时信息，当为QoS分配隧道时，这种方法非常有效。另
一种方法是每当静态隧道配置信息安装完毕时，就建立隧道，然后努力保持该隧道存在。
3.1.7 MTU问题
    一个IP隧道关联一个MTU，就像常规的链接一样，可以想象，这个MTU可能比通道上任何两
端点之间的单跳或多跳的MTU都要大，这样在隧道中就可能要求某些形式的帧分割。
    如果帧映射在一个IP包里面，当IP数据报到达一个MTU小于IP隧道MTU的节点时，就会进行
正常的IP分割。这种隧道中间分割可能会在路由器上造成意料不到的性能牵连。
    一种可选的方法是让隧道协议本身包含隧道级分拆和重组的能力，例如，可以用隧道序列
号和某种类型的消息终止符，（注意，多链接PPP就是用这种类似的机制分割信息包），避免IP
层隧道自身的分割。现在还没有什么协议支持这样的机制。