僅僅可以應用于后者，因為它們所利用的工具（如路由協議背載）只能由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
層隧道自身的分割。現在還沒有什么協議支持這樣的機制。