多協議標簽交換虛擬專用網 (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 均缺乏的防電子欺騙保護?？刂泼姘宀僮鞯玫搅藬U展，可支持隧道終端發現和通過隧道的 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 。