思科IP MPLS VPN
2006-04-11   网络

多协议标签交换虚拟专用网 (MPLS VPN) 推出了一种对等模式，可以支持大规模 IP VPN 实施。这种模式极大地简化了 VPN 客户和服务供应商的路由和可管理性，与此同时，确保了 VPN 间的正确隔离。为实施该模式， MPLS VPN 需要现有 IP 路由协议扩展和一个 MPLS 传输网络。 Cisco IOS 软件版本 12.0(28)S 及更高版本都支持 思科 IP MPLS VPN ，它采用了与 MPLS VPN 相同的功能，但是用 IP 传输替代了 MPLS 传输。 VPN 流量由 IP 隧道，而非 MPLS 标签交换路径 (LSP) 传输。该特性使 IP 网络上实现了在 MPLS 上无法支持的 MPLS VPN 服务。

应用、服务和架构

无论是在 IP 或 MPLS 骨干网上实施，思科 IP MPLS VPN 都保有相同的应用和服务特征。例如，公司可以利用该技术将 IP 网络分段，以在其架构中支持不同的群组，或者为其他服务方提供专用 IP 服务。这种分段支持重叠地址和灵活的流量转发拓扑结构。在另外一种情况下，网络工程师可以利用该技术构建一种集中服务器基础设施，由多个 VPN 共享。

思科 IP MPLS VPN 为 VPN 服务供应商和用户提供了全新的应用和服务机遇。例如， MPLS VPN 服务供应商可以利用自治系统间配置，将其服务扩展至非 MPLS 支持的网络。同样，两家供应商可以就 MPLS VPN 服务达成对等协议，即使他们采用的是 IP 传输。在另一个案例中， MPLS VPN 用户可以将 VPN 服务分区，以便创建其自身的内部 VPN 服务。由于在用户和供应商间几乎无需协调，所以，这种应用为分级 VPN 配置的实施提供了更高的灵活性。图 1 对采用思科 IP MPLS VPN 的两种示范应用进行了介绍。

思科 IP MPLS VPN 采用多点 IP 隧道集合和一个独立地址空间，扩展了原始 MPLS VPN 架构。每个供应商边缘 (PE) 都拥有一个多点隧道接口，用于连接 PE 和其他所有享有 VPN 服务的 PE 。该隧道可以转发 VPN 分组至相应的目的地 PE ，且同时使 VPN 分组传输对于中间节点保持透明。每个 PE 可以通过隧道自动搜索其他可访问的 PE （即隧道终端）。

图 1 采用思科 IP MPLS VPN 的两种示范应用： VPN 服务扩展和分层 VPN

图 2 采用思科 IP MPLS VPN 的网络逻辑视图

采用思科 IP MPLS VPN 的网络逻辑视图

PE 搜索过程利用了边界网关协议 (BGP) 多点协议的简单扩展，它构建于早已应用于各种 MPLS VPN 的 BGP 扩展之上。多点隧道的独立地址空间为 VPN 流量提供了隔离功能。这种架构保有与传统 MPLS VPN 服务相同的可扩展性，并可扩展以支持多项 IP 隧道技术（见图 2 ）。

流量转发和封装

思科 MPLS VPN 的基本分组转发功能独立于所选的骨干网传输方式 (MPLS 或 IP) 。在这两种情况下，利用 PE 支持的各个 VPN 的虚拟路由和转发 (VRF) 实例功能， VPN 流量可以在 PE 内保持独立。但是，根据思科 MPLS VPN 中传输网络的不同，分组封装也有所差异。当使用 IP 传输时，有两个封装组件：隧道报头和 VPN 报头。隧道报头负责传输分组至输出 PE ，而 VPN 报头则负责确定该位置的相应 VPN 分组处理流程。

思科 IP MPLS VPN 当前的实施采用了第二层隧道协议版本 3 (L2TPv3) 作为 IP 隧道技术。隧道报头利用 L2TPv3 进程 ID 字段识别需要 MPLS VPN 处理流程的 IP VPN 分组，并利用 Cookie 字段提供电子欺骗保护。作为封装的最后部分， VPN 报头采用了与 MPLS 传输中 MPLS VPN 所用相同的 VPN 标签。图 3 对不同传输中提供的 MPLS VPN 服务封装进行了比较。

L2TPv3 为 VPN 流量提供了针对外部攻击的内置保护。一位恶意用户可能会向 PE 发送 VPN 封装分组，从而试图向 VPN 输入分组。在使用 MPLS 传输时，一般可通过拒绝客户访问接口上来自 VPN 用户的 MPLS 分组，来防御这类攻击。在实施 IP MPLS VPN 传输时， PE 设备一般更易于受到 IP 电子欺骗攻击。网络边界或 PE 本身需特殊配置和额外处理（如访问控制列表，即 ACL 等）来识别和阻塞伪装的 VPN 分组。通过直接在 PE 中采用强大的电子欺骗防御功能， L2TPv3 在接近客户的地点提供电子欺骗防御。所以，无论有无 IP ACL ， L2TPv3 都可防止特定 VPN 上的外部电子欺骗攻击，这是因为每个 PE 利用预先加密的随机 64 位 Cookie 来转发分组。

在 100Mpps 的攻击速率下，要想针对思科 IP MPLS VPN 部署实施一次成功的盲目电子欺骗攻击，将需要至少 6000 年。恶意用户需知道入口和出口 PE 的 IP 地址、 L2TPv3 进程 ID 和 Cookie ，以及 VPN 标签，才能从外部向 VPN 输入流量。猜测出随机（ 64 位） L2TPv3 Cookie 值的巨大投入消除了成功攻击的可能性。其他字段几乎不会提供超出 L2TPv3 Cookie 的额外保护，因为它们不能以随机加密方式选择，因此其规模不够庞大，无法阻止一位坚定的攻击者进行猜测。

当需要非加密解决方案时， MPLS VPN 可使用其他 IP 隧道封装，如 IP MPLS 或通用路由封装 (GRE) 。采用普通 IP 隧道封装（ IP MPLS ）的 MPLS VPN 实施是最简单的，但最易受攻击。假设一位恶意用户已发现了 PE 的源和目的地 IP 地址，该用户只需猜测一个正确的 VPN 标签（ 20 位）。即便在低攻击速率（数千 pps ）的情况下，可能在几秒内就会发生安全违背。

第二种方式是使用 GRE 协议，它有一个未定义的保留密钥（ 32 位）字段。但即使此密钥以类似于 L2TPv3 Cookie 的方式使用 ( 即填充加密随机值 ) ，它仍无法提供足够的防电子欺骗保护。在相对较低的攻击速率下，数小时后就可能出现安全违背（ 100,000pps 时不到 12 小时）。因此， GRE 对此应用意义不大，且会因为需检查和验证各种可选字段而带来不必要的开销。

图 3 IP 网络上提供的 MPLS VPN 服务与 MPLS 网络上提供的 MPLS VPN 服务的具体封装比较

VPN 路由分发，隧道终端发现

无论采用什么骨干传输（ IP 或 MPLS ）， MPLS VPN 都使用相同的 VPN 路由分发机制。但 VPN 路由解析在思科 IP MPLS VPN 和 MPLS 上的 MPLS VPN 中的运行方式不同。在处理输入 VPNv4 BGP 更新时， MPLS VPN 一般需要 PE 对 BGP 下一跳执行回归式路由查询。当采用 MPLS 骨干时， PE 将把下一跳与现有 LSP 匹配。当采用 IP 骨干时， PE 将把下一跳与现有隧道终端相匹配。

成功的匹配可选出作为分组输出接口的多点隧道。该过程保证分组能正确地通过隧道、以正确的封装转发。为正确地进行解析， BGP 下一跳被分解为与隧道相关的独立地址空间。否则就会针对全球路由空间尝试解析，以搜索不存在的 LSP 。

思科 IP MPLS VPN 提供自动隧道终端发现和隧道参数标记。在能进行正确的 VPNv4 BGP 下一跳解析之前，每个 PE 都需要知道可通过多点隧道访问其他哪些 PE （终端）。此外，每个 PE 需知道其他 PE 希望使用的 L2TPv3 进程 ID 和 Cookie ，以便 VPN 分组能准确封装。此信息的手动配置不可扩展；随着 PE 数目的增加，隧道简单的多点特性就会被破坏。

PE 利用现有多协议 BGP(MP-BGP) 基础设施来分发隧道终端信息。思科 IP MPLS VPN 在 MP-BGP 中定义了一个新的隧道地址系列扩展。此地址系列可用于标记 L2TPv3 隧道地址、进程 ID 和 Cookie 。 L2TPv3 只可用作封装机制。本地 L2TPv3 控制面板不起作用。因为已需 MP-BGP 来分发 VPNv4 路由信息，此扩展的运行和处理影响极低。相反，当 MPLS 用作传输机制时，终端发现与 VPNv4 广播相关联，不标记封装类型 (MPLS) 及其 (LSP) 参数。有关通过 MP-BGP 了解的隧道终端信息，请访问 cisco.com/packet/171_5c1 。

思科 IP MPLS VPN 将 L2TPv3 用作 IP 隧道技术，提供了纯 IP 和 GRE 均缺乏的防电子欺骗保护。控制面板操作得到了扩展，可支持隧道终端发现和通过隧道的 VPNv4 下一跳解析。凭借思科 IP MPLS VPN ，现在 MPLS VPN 能以一种可扩展、安全的方式，部署于任意 IP 网络之上。

深入阅读

• 思科 IP MPLS VPN 文档 cisco.com/packet/171_5c2
• L2TPv3 上的 BGP/MPLS IP VPN IETF 草案 cisco.com/packet/171_5c3
• L2TPv3 上的 MPLS 封装 IETF 草案 cisco.com/packet/171_5c4

SANTIAGO ALVAREZ ， CCIE 号 3621 ，是思科互联网技术部的一名技术营销工程师，主要从事的领域是 MPLS 和 QoS 技术。他一直是 Networkers 的特邀演讲人和 Packet 的固定撰稿人。 联系方式： saalvare@cisco.com 。