跳轉到內容

計算機網路技術與服務/VPN

來自華夏公益教科書,開放的書籍,開放的世界
Previous page
遷移到IPv6
計算機網路技術與服務 Next page
VoIP
VPN

一個想要為其遠端終端(單個使用者,資料中心,分支機構)構建企業私有網路的公司,可以採用兩種不同的方法

  • 公司可以構建自己的專用基礎設施(租賃線路,撥號連線);
  • 公司可以採用VPN解決方案。

虛擬專用網路 (VPN) 允許公司透過公共共享基礎設施(網際網路或網際網路服務提供商的網路)將連線部署到多個使用者,並實施自己的策略(如安全性,服務質量,私有定址),就好像它自己的私有網路一樣。

VPN解決方案的優勢是

  • 廉價性: 到達遠端使用者的昂貴物理連線不再需要構建,而是VPN解決方案利用了現有的基礎設施,因此成本是共享的;
  • 選擇性: 由於防火牆的存在,只有擁有許可權的使用者才能訪問→更高的安全性;
  • 靈活性: 允許的使用者可以輕鬆新增,使用者也可以輕鬆移動。

VPN由一些主要元件組成

  • 資料透過隧道傳遞,因此它們透過使用GRE、L2TP、MPLS、PPTP和IPsec等協議與在共享基礎設施上傳輸的其他資料分離
  • 資料為了更高的安全性而被加密,使用IPsec和MPPE等協議;
  • 資料透過完整性檢查,因此它們不能被篡改,這要歸功於TCP校驗和或IPsec中的AH;
  • 在隧道建立之前,透過身份驗證機制檢查隧道另一端是誰的身份(例如,使用數字證書)。

VPN解決方案可以根據以下標準進行分類

疊加 對等
接入 L2TP、PPTP
站點到站點 IPsec、GRE MPLS

部署場景

[編輯 | 編輯原始碼]

VPN可以在兩種主要場景中部署

  • 接入VPN(也稱為“遠端VPN”或“虛擬撥號”):它將撥號連線虛擬化,並透過使用PPTP和L2TP等協議,透過ISDN、PSTN、電纜調變解調器、無線區域網將單個使用者連線到企業網路;
  • 站點到站點VPN: 它將租賃線路虛擬化,並透過使用IPsec、GRE和MPLS等協議將多個遠端網路相互連線。
站點到站點VPN可以以兩種方式部署
  • 內聯網VPN: 所有互連網路都屬於同一家公司
  • 外聯網VPN: 互連網路屬於多家公司

VPN功能必須滿足一些要求

  • 安全:防火牆可以限制對網路資源的訪問;
  • 資料加密:為了保護透過共享基礎設施傳輸的資訊;
  • 可靠性:關鍵任務流量必須得到保證,以到達目的地;
  • 可擴充套件性:該解決方案必須適用於小型和大型網路;
  • 增量部署:隨著網路的增長,該解決方案保持工作;
  • 接入VPN的額外要求
    • 強身份驗證:為了驗證移動使用者的身份(例如,個人筆記型電腦可能被盜);
    • 使用者及其帳戶的集中管理;
  • 站點到站點外聯網VPN的額外要求
    • 選擇性訪問:每家公司都可以授予其他公司對某些服務的訪問許可權,但阻止其私人網路的其他服務的訪問許可權;
    • 地址衝突管理:一個私有地址可能屬於兩個不同的私有網路→需要NAT;
    • 使用開放的、基於標準的解決方案:不同的公司需要能夠共享相同的VPN解決方案;
    • 流量控制:每家公司都需要控制來自其他公司網路的流量量,並消除網路接入點的瓶頸。

網際網路訪問

[編輯 | 編輯原始碼]

連線到VPN的遠端終端可以透過兩種方式訪問公共網際網路

  • 集中式網際網路訪問: 所有進出網際網路的流量都始終透過總部VPN閘道器傳遞;
  • 分散式網際網路訪問: 進出網際網路的流量不涉及VPN,VPN僅用於企業流量。

集中式網際網路訪問

[編輯 | 編輯原始碼]
優點
  • 集中式策略管理:公司可以針對所有連線的遠端終端一次性設定自己的網際網路訪問策略(例如,禁止員工在工作時訪問某些網站);
  • 安全優勢:企業防火牆可以保護主機免受來自網際網路的惡意資料包的攻擊。
缺點
  • 遠端終端速度較慢:進出網際網路的資料包需要經過更多的跳躍才能傳遞,因為它們始終必須經過總部VPN閘道器,而不是直接到達目的地;
  • 總部需要更高的頻寬;
  • 強制連線:VPN必須始終處於活動狀態,即使用者不能臨時停用VPN,並在沒有企業防火牆保護的情況下瀏覽網際網路,否則,如果他在返回VPN時被感染,他將感染企業網路,因為來自他的流量沒有被防火牆保護。

分散式網際網路訪問

[編輯 | 編輯原始碼]
優點
  • 遠端終端速度更快:資料包始終直接前往網際網路目的地;
  • 自願連線:使用者可以隨時停用VPN,而不會造成額外的安全威脅。
缺點
  • 分散式策略管理:公司需要在遠端終端配置多個路由器,以設定自己的策略;
  • 安全威脅:企業防火牆保護缺失。

VPN可以根據共享基礎設施的作用分為兩種模型

  • 疊加模型: 基礎設施不知道VPN解決方案,只提供IP連線服務:它只傳輸資料包,而不知道它們是VPN資料包,在不與基礎設施互動的VPN閘道器之間傳輸→有利於資料隱私:基礎設施的管理人員無法檢視私人資料,也無法利用路由資訊;
  • 對等模型: 基礎設施內的閘道器參與VPN的建立,並相互互動→更好的路由,更高的可擴充套件性。
非 MPLS 基於對等模型的 VPN 可以是
  • 專用路由器:基礎設施的管理者將一些路由器完全分配給一個客戶,另一些路由器完全分配給另一個客戶,等等;
  • 共享路由器:基礎設施中的每個路由器都由多個客戶共享 → 成本更低。

VPN 可以由客戶或提供商配置

  • 客戶配置:使用者自行建立和管理 VPN,隧道在客戶邊緣 (CE) 之間建立;
  • 提供商配置:VPN 由網際網路連線提供商完全提供和管理,隧道在提供商邊緣 (PE) 之間建立。

客戶配置的 VPN 不能是對等模型,因為提供商無法感知客戶自行建立的 VPN。

VPN 連線可以在不同的層級

  • 第 2 層:乙太網幀在 VPN 中交換
    • 虛擬專用區域網服務 (VPLS):它虛擬化了一個區域網:終端連線在一起,就好像它們在同一個區域網中一樣 → 允許廣播資料包;
    • 虛擬專用線路服務 (VPWS):它虛擬化了一條租用線路(在分組交換網路上);
    • 僅 IP 區域網式服務 (IPLS):它虛擬化了一個 IP 網路,但只允許 IP(ICMP 和 ARP)資料包;
  • 第 3 層:IP 資料包在 VPN 中交換;
  • 第 4 層:TCP 連線(可能使用 SSL 進行安全保護)在 VPN 中建立。

虛擬拓撲

[編輯 | 編輯原始碼]

根據虛擬拓撲,VPN 可以分為兩類

  • 星型:每對終端只能透過總部進行通訊 → 總部由於流量較高可能會出現瓶頸;
  • 網狀:每對終端可以直接相互通訊,無需透過總部 → 路由更好,但隧道數量更多。

點對點協議 (PPP) 是一種第 2 層協議,用於點對點連線(撥號、ISDN)以封裝上層協議。它是 HDLC 的擴充套件。

一個 PPP 資料包具有以下格式

1 位元組 1 位元組 1 位元組 1 或 2 位元組 2 或 4 位元組 1 位元組
01111110(標誌) 地址 控制 協議 資料 CRC 01111110(標誌)

其中最重要的欄位是

  • 起始和終止標誌:它們是資料幀所必需的;
  • 地址控制 欄位:它們繼承自 HDLC,但在點對點連線中完全沒有意義;為了簡化 HDLC 裝置中的處理演算法,它們被保留了下來;
  • 協議 欄位:它指定封裝資料包的上層協議。

'01111110' 是分隔幀的序列,但為了將該序列作為資料傳送,需要一些填充規則。在 PPP 中,填充是在位元組級別進行的:當資料中出現等於分隔位元組的位元組時,以及當資料中出現等於轉義位元組本身的位元組時,都會插入轉義序列 '01111101'

鏈路控制協議 (LCP) 的任務是開啟和關閉 PPP 連線,協商一些選項(例如幀最大長度、身份驗證協議)。

一個 IP 資料包不能直接封裝第 3 層或更低層的協議,因為 IPv4 首部中的 '協議' 欄位只能指定上層協議(例如 TCP、UDP、ICMP)。

通用路由封裝 (GRE) 是一種協議,用於將任何協議(包括 IP 和其他更低層協議)封裝到 IP 中:GRE 首部插入封裝的 IP 首部和封裝的資料包之間,封裝的 IP 首部中的 '協議' 欄位設定為 47。

GRE 首部具有以下格式

5 8 13 16 32
C R K S s 遞迴 標誌 版本(0) 協議型別
校驗和(可選) 偏移量(可選)
金鑰(可選)
序列號(可選)
路由(可選) ::

其中最重要的欄位是

  • CRKS 標誌(每個 1 位):它們指示可選欄位的存在/不存在;
  • 嚴格源路由 (s) 標誌(1 位):如果設定為 1,當源路由列表('路由' 欄位)結束時,如果目標還沒有到達,則丟棄資料包(類似於 TTL);
  • 遞迴 欄位(3 位):它指定允許的最大額外封裝數量(目前不支援);
  • 版本 欄位(3 位):它指定 GRE 協議的版本(在本例中為 0);
  • 協議型別 欄位(16 位):它指定封裝資料包的協議;
  • 路由 欄位:它指定對應於資料包應經過的中間路由器的 IP 地址序列(源路由)。
'路由' 欄位又由一些欄位組成(除了 IP 地址列表外),包括
  • 地址族 欄位:它指定列表中地址的型別(在本例中為 IP);
  • SRE 偏移量 欄位:它是指向包含當前下一跳 IP 地址的列表項的指標,在每個源路由跳躍時更新;
  • SRE 長度 欄位:它指定列表的長度(以位元組為單位)。

增強型 GRE

[編輯 | 編輯原始碼]

增強型 GRE 首部的格式引入了新的 '確認號' 欄位

5 8 13 16 32
C R K S s 遞迴 A 標誌 版本(1) 協議型別
金鑰(有效負載長度) 金鑰(呼叫 ID)
序列號(可選)
確認號(可選)

其中最重要的欄位是

  • 金鑰 欄位(32 位)
    • 有效負載長度(16 位):它指定資料包的長度,不包括 GRE 首部(以位元組為單位);
    • 呼叫 ID(16 位):它指定資料包的會話 ID;
  • 確認號 欄位(32 位):傳送方在資料包中放入它從目標接收到的最後一個數據包序列號(累積 ACK)。
新的 '確認號' 欄位與 '序列號' 欄位結合,允許一些額外的機制
  • 流量控制:滑動視窗避免目標氾濫,並在收到 ACK 資料包時移動;
  • 亂序資料包檢測:增強型 GRE 是為 PPP 封裝設計的,PPP 是點對點連線的協議,預計資料包不會亂序到達 → 亂序資料包始終被丟棄;
  • 丟失資料包檢測:當超時到期時,即沒有收到 ACK,則檢測到資料包丟失,但檢測到的丟失資料包不會重新傳輸;
  • 擁塞控制:當檢測到太多超時時,資料包傳輸會減慢,以免網路擁塞。
L2TP 的原始參考場景:提供商配置的部署模式。

第 2 層隧道協議 (L2TP) 是一種將任何第 2 層協議(在本討論中為 PPP)封裝到 IP 中的協議。L2TP 最初是為提供商配置的訪問 VPN 設計的,並且由 IETF 標準化;後來透過簡單地將 LAC 功能實現到使用者機器中,它被擴充套件到客戶配置的訪問 VPN。

在 L2TP 的原始參考場景中,遠端使用者想要透過點對點 (PPP) 連線向公司網路內部的內部伺服器傳送資料包。需要建立一個到目標 L2TP 網路伺服器 (LNS) 的 L2TP 隧道以及隧道內的 L2TP 會話,以在服務提供商網路上模擬 PPP 連線。

當 PPP 幀到達 L2TP 訪問集中器 (LAC) 時,如果還沒有建立到 LNS 的 L2TP 隧道,則在開啟 L2TP 會話之前,LAC 必須建立到 LNS 的隧道:LNS 使用類似於挑戰握手身份驗證協議 (CHAP) 的基於挑戰的機制向 LAC 進行身份驗證,並建立一個新的控制連線。

每個 L2TP 會話在隧道內使用兩個通道

  • 資料通道:用於傳輸資料報文,即 PPP 幀;
  • 控制通道:用於交換控制報文,用於管理通訊(例如驗證資料包是否到達、重傳丟失的資料包、檢查資料包的正確順序)。
與資料報文不同,控制報文以可靠的方式交換:丟失的控制報文總是會被重傳。

多個會話可以在同一個隧道內共存,共享同一個控制連線,以區分來自多個遠端使用者的多個 PPP 幀流:每個隧道由一個隧道 ID 標識,每個會話由一個會話 ID 標識。

安全性

除了在隧道建立步驟中確保的身份驗證之外,L2TP 本身不提供任何安全機制:實際上,對沿著隧道傳輸的 L2TP 資料包使用加密等機制沒有意義,因為服務提供商的 LAC 仍然可以看到第 2 層幀 → 任何安全機制都必須端到端地實現,即在使用者和公司網路內部的最終目的地之間。
可以選擇透過隧道使用 IPsec:它提供強大的安全性,但實施起來很複雜。

L2TP 隧道內的資料包包含多個封裝的報頭

MAC 報頭 IP 報頭 UDP 報頭 L2TP 報頭 PPP 報頭 PPP 負載
PPP 報頭

它標識遠端使用者與公司網路內部伺服器之間的點對點連線。

L2TP 報頭

它標識 L2TP 隧道

8 16 32
T L 0 S 0 O P 0 版本 (2) 長度
隧道 ID 會話 ID
Ns Nr
偏移量大小 偏移量填充 ::

其中最重要的欄位是

  • T 標誌 (1 位):如果設定為 0,則資料包為資料報文,如果設定為 1,則為控制報文;
  • 隧道 ID 欄位 (16 位):它標識 L2TP 隧道;
  • 會話 ID 欄位 (16 位):它標識 L2TP 會話,即隧道中的資料通道;
  • Ns 欄位 (16 位):它包含資料/控制報文的序列號;
  • Nr 欄位 (16 位):它包含要為可靠的控制連線接收的下一個控制報文的序列號。
UDP 報頭

為什麼像 UDP 這樣的第 4 層協議被用來移動第 2 層幀?這可以透過考慮一般網路上的防火牆來解釋:如果資料包不包含第 4 層封裝,它更容易被防火牆丟棄。
另一個可能的原因是,第 4 層可以透過套接字訪問,而作業系統負責第 3 層。由於 L2TP 希望成為針對 PPTP(由作業系統供應商提出)的解決方案,L2TP 設計人員希望使其對應用程式可訪問,而不是緊密地依賴作業系統供應商的意願。
也可以使用不同的第 4 層協議(例如 ATM、幀中繼)。

IP 報頭

它包含隧道端點的 IP 地址。
在原始參考場景中,IP 地址對應於 LAC 和 LNS。

PPTP 原始參考場景:客戶配置部署模式。

點對點隧道協議 (PPTP) 是一種將 PPP 協議隧道化到 IP 中的協議。PPTP 最初是為客戶配置的訪問 VPN 而設計的,並且是由主要的運營系統供應商開發的;後來它透過引入具有類似於 LAC 功能的 PPTP 訪問集中器 (PAC) 而擴充套件到提供商配置的訪問 VPN。

PPTP 原始參考場景與 L2TP 場景的不同之處在於,PPTP 隧道是在遠端使用者本身和 PPTP 網路伺服器 (PNS) 之間建立的。

與 L2TP 相比,PPTP 提供弱(可選)的安全機制:該標準涵蓋了使用特定微軟專有的安全協議(例如 MPPE 用於加密和 MS CHAP 用於身份驗證),因此沒有協議協商。

資料通道

[edit | edit source]

封裝的 PPP 幀透過資料通道傳輸

IP 報頭 GRE 報頭 PPP 報頭 PPP 負載

PPTP 使用增強型 GRE 協議將 PPP 幀封裝到 IP 中。PPP 負載可以選擇透過 MPPE 進行加密。

控制通道

[edit | edit source]

PPTP 控制報文透過控制通道傳輸

IP 報頭 TCP 報頭 PPTP 控制報文

控制報文是隧道資料會話設定、管理和拆除所必需的,它們被髮送到 PNS 的知名 TCP 埠 1723。

IPsec

[edit | edit source]

IPv4 中的網際網路協議安全 (IPsec) 協議套件的功能與 IPv6 中的功能非常相似: Computer network technologies and services/IPv6#IPsec.

主要區別在於,在 IPv6 中,IPsec 是標準中包含的擴充套件報頭,而在 IPv4 中,它是一個封裝到 IP 中的新附加協議(對於 AH,'Protocol' 欄位設定為 51,對於 ESP,它設定為 50)

認證報頭 (AH)。
IPv4 報頭 AH 報頭 TCP/UDP 報頭 有效負載
經過身份驗證的資料


封裝安全負載 (ESP)。
IPv4 報頭 ESP 報頭
(用於加密)
TCP/UDP 報頭 有效負載 ESP 報頭
加密資料
經過身份驗證的資料

安全套接字層 (SSL),現在稱為傳輸層安全 (TLS),是一種旨在為客戶端和伺服器之間提供通訊安全的加密協議

  1. 客戶端在埠 443 上與伺服器開啟一個 TCP 連線,併發送一個用於伺服器身份驗證的挑戰;
  2. 伺服器向客戶端傳送一個 Hello 訊息,其中包含其證書和對挑戰的響應,這些響應由伺服器的私鑰加密;
  3. 客戶端透過檢視由可信證書頒發機構提供的證書列表來驗證證書,然後它使用伺服器的公鑰解密對挑戰的響應;
  4. 客戶端為安全通訊決定一個私鑰,並透過使用伺服器的公鑰加密將其傳送給伺服器 → 從這一點開始,所有記錄訊息將使用該私鑰加密(該私鑰應定期重新協商);
  5. 通常,伺服器要求使用者在網頁上輸入其使用者名稱和密碼以進行客戶端身份驗證(在應用程式層)。

訪問 VPN

[edit | edit source]

撥號連線場景

[edit | edit source]

基本上,遠端使用者,通常是公司的員工,想要透過公司網路聯絡伺服器。他可以使用 PPP 建立與公司閘道器的撥號點對點連線,以封裝 IP 資料包

  • 透過鏈路控制協議 (LCP),他可以協商第 2 層引數(例如身份驗證協議);
  • 透過網路控制協議 (NCP),他可以協商第 3 層引數(例如公司網路內的私有 IP 地址、DNS)。

在接受撥號連線之前,公司閘道器會透過遠端身份驗證撥號使用者服務 (RADIUS) 協議與公司安全伺服器聯絡以檢查使用者。公司安全伺服器是集中式的AAA 伺服器

  • 身份驗證:識別使用者(例如透過使用者名稱和密碼);
  • 授權:檢查使用者可以訪問哪些服務以及哪些服務對使用者是受限的;
  • 計費:跟蹤使用者活動(例如計費)。

訪問 VPN 可以將遠端使用者與公司網路之間的撥號連線虛擬化到服務提供商共享的基礎設施上,以降低成本。PPP 協議將繼續在 VPN 隧道中使用,以避免過多地更改公司閘道器。

客戶配置

[edit | edit source]
作為客戶配置部署的訪問 VPN。

在客戶配置的訪問 VPN 中,隧道是在遠端使用者和公司閘道器之間建立的

  1. 使用者請求建立與服務提供商 NAS 的 PPP 撥號連線,並要求透過 LCP 和 NCP 協商連線的配置引數;
  2. NAS 透過使用 RADIUS 協議透過提供商安全伺服器檢查使用者身份;
  3. NAS 為使用者提供 PPP 撥號連線的配置引數,特別是公共 IP 地址;
  4. 使用者透過傳送包含一個 IP 資料包的 PPP 幀來請求與企業閘道器建立 VPN 隧道,該資料包的目標 IP 地址是企業閘道器的公共 IP 地址;
  5. NAS 透過服務提供商網路將請求轉發到企業閘道器;
  6. 企業閘道器使用 RADIUS 協議透過企業安全伺服器檢查使用者身份;
  7. 企業閘道器為使用者提供 VPN 隧道的配置引數,特別是企業網路內的私有 IP 地址;
  8. NAS 將企業閘道器的回覆轉發到遠端使用者。

VPN 建立後,使用者將擁有兩個 IP 地址:一個用於服務提供商 NAS 的公共 IP 地址,另一個用於企業閘道器的企業 IP 地址。使用者可以透過隧道傳送的 PPP 幀具有以下格式

PPP 報頭 IP 報頭 PPP 報頭 IP 報頭 IP 負載
使用者的公共 IP 地址 使用者的企業 IP 地址
目標 企業閘道器的公共 IP 地址 目標 最終目標的企業/公共 IP 地址
優點

使用者獨立於服務提供商:事實上,服務提供商只為使用者提供到企業閘道器的網際網路連線。

缺點

使用者可能會暫時停用 VPN 連線並透過網際網路連線到外部伺服器→如果他感染了惡意軟體,當他回到 VPN 時,他將感染企業網路。

提供商供應

[edit | edit source]
訪問 VPN 部署為提供商供應。

在提供商供應的訪問 VPN 中,隧道是在服務提供商 NAS 和企業閘道器之間建立的

  1. 使用者請求建立到企業閘道器的 PPP 撥號連線,要求透過 LCP 和 NCP 協商連線的配置引數;
  2. NAS 使用 RADIUS 協議透過提供商安全伺服器檢查使用者身份,特別是識別使用者為 VPN 使用者;
  3. NAS 請求與企業閘道器建立與使用者相關的 VPN 隧道,透過傳送目標 IP 地址為企業閘道器的公共 IP 地址的 IP 資料包來請求;
  4. 企業閘道器使用 RADIUS 協議透過企業安全伺服器檢查使用者身份;
  5. 企業閘道器為 NAS 提供 VPN 隧道的配置引數;
  6. NAS 可選地記錄接受和/或流量以向公司收取服務費用;
  7. 企業閘道器為使用者提供 PPP 連線的配置引數(撥號虛擬化),特別是企業網路內的私有 IP 地址;
  8. NAS 將企業閘道器的回覆轉發到遠端使用者。

VPN 建立後,使用者只擁有企業 IP 地址,不知道服務提供商 NAS 和企業閘道器之間的隧道。NAS 可以透過隧道傳送的 IP 資料包具有以下格式

IP 報頭 PPP 報頭 IP 報頭 IP 負載
服務提供商 NAS 的公共 IP 地址 使用者的企業 IP 地址
目標 企業閘道器的公共 IP 地址 目標 最終目標的企業/公共 IP 地址
優點

使用者無法在不透過企業閘道器的情況下訪問網際網路(集中訪問)→更高的安全性。

缺點

使用者不獨立於服務提供商:事實上,如果他更換服務提供商,VPN 連線將不再起作用。

站點到站點 VPN

[edit | edit source]

基於 IPsec 的 VPN

[edit | edit source]

在基於 IPsec 的 VPN 中,IPsec 在 VPN 閘道器之間以隧道模式使用:兩個主機之間的 IP 資料包被封裝到一個 IP 資料包中,在兩個 VPN 閘道器之間具有 ESP 標頭(以及可選的 AH 標頭),因此兩個主機的 IP 地址也可以被 ESP 加密。

私有內部網可以由以下保護

  • 防火牆:它根據企業關於例如允許的 IP 地址的策略過濾流量,它可以在與 VPN 閘道器相關的不同位置放置
    • 在 VPN 閘道器之前:VPN 閘道器受到保護,但防火牆無法過濾 VPN 流量,因為它已加密;
    • 在 VPN 閘道器之後:防火牆可以過濾解密的 VPN 流量,但 VPN 閘道器不受保護;
    • 與 VPN 閘道器並行:資料包在 VPN 閘道器之前和之後都透過防火牆,因此 VPN 閘道器受到保護,並且過濾了 VPN 流量,但防火牆的工作量更高;
    • 整合到 VPN 閘道器中:VPN 閘道器和防火牆的功能都整合到一個裝置中→最大限度地提高靈活性;
  • 入侵檢測系統 (IDS):它觀察流量,試圖檢測是否正在發生攻擊,並且兩個 IDS 探測器與 VPN 閘道器並行放置
    • VPN 閘道器之前的探測器觀察來自隧道的流量並保護免受來自共享基礎設施的攻擊;
    • VPN 閘道器之後的探測器觀察 VPN 流量並保護免受來自企業網路的攻擊(例如,安裝在員工 PC 上的惡意軟體,如果站點到站點 VPN 是外聯網,來自另一家公司的攻擊)。

NAT 的存在可能會導致 IPsec 出現問題

  • AH 對整個資料包進行身份驗證,因此它也涵蓋了 IP 標頭→NAT 需要更改 IP 地址,因此身份驗證將不再起作用;
  • ESP 對有效負載進行加密,因此位於隧道中的 NAT 將無法看到加密的 IP 地址和 TCP/UDP 埠,以處理不同的 VPN 站點。

基於 MPLS 的 VPN

[edit | edit source]

第 2 層:PWE3

[edit | edit source]
基於 MPLS 的第 2 層站點到站點 VPN 的示例。

偽線模擬端到端 (PWE3) 標準允許在 MPLS 網路上模擬線,以在第 2 層終端(如乙太網交換機或電話交換機)之間交換乙太網幀。[1]這種型別的連線對乙太網幀的恆定延遲有一些要求,就像它們透過物理線纜傳輸一樣。

流量透過 LSP 傳輸,然後需要能夠到達連線到入/出 LSR 的多個介面之一的多個站點

  • 外部標籤:它標識兩個入/出 LSR 之間的 LSP,並且它後面是多個內部標籤之一;
  • 內部標籤:它標識公司的 VPN 隧道,並且入/出 LSR 使用它將幀從其介面之一發送到公司的站點。

基於 MPLS 的第 2 層 VPN 不會利用所有 MPLS 的優勢,因為流量工程的路由協議與 IP 非常有效→通常手動配置 LSP。

第 3 層:BGP

[edit | edit source]
基於 MPLS/BGP 第 3 層站點到站點 VPN 的示例。

邊界閘道器協議 (BGP) 擴充套件到內部 BGP外部 BGP 以支援在 MPLS 上部署 VPN,例如對於公司 A 的站點 1

  1. 公司 A 的 CE1 透過內部 BGP向 PE1 通告站點 1 內的目的地,也就是說它告訴 PE1 所有可以在站點 1 內到達的 IP 地址;
  2. PE1 為來自 CE1 的每個 IP 地址分配一個標籤,並將對映記錄到特定於其指向 CE1 的埠的VPN 路由和轉發 (VRF) 表中;
  3. PE1 透過外部 BGP向其他 PE 通告所選標籤,透過傳送包含每個 IP 地址和一個路由區分符的包,該區分符標識地址族,實際上是公司 A 站點的埠,這在兩個不同的企業網路中存在兩個相同的私有地址時很有用。
    此步驟需要手動執行:系統管理員必須在 PE1 和 MPLS 網路中的每個其他 PE 之間開啟一個對等會話
  4. 其他 PE 可以處理通告訊息或忽略它們
    • 連線到公司 A 的某個站點的其他每個 PE(圖中為 PE3)將其 VRF 表記錄為來自 PE1 的通告資訊,即站點 1 中每個 IP 目的地的所選標籤,換句話說,與站點 1 的地址族相關的 IP 地址,加上 PE1 的 IP 地址;
    • 沒有連線到公司 A 的任何站點的其他每個 PE(圖中為 PE2)只忽略來自 PE1 的通告資訊;

一旦 IP 目的地在 PE 之間通告,VPN 資料就可以開始沿著 MPLS LSP 傳送,例如從公司 A 的 CE3 到公司 A 的 CE1

  1. PE3,即入 LSR,將兩個標籤壓入標籤棧
    • 內部標籤:PE1 之前通告的標籤;
    • 外部標籤:由 LSR 透過 MPLS 標籤繫結、分發和對映協議為從 PE3 到 PE1 的 LSP 決定的標籤;
  2. 中間 LSR 不關心內部標籤,但它們只對沿著 LSP 的外部標籤進行操作;
  3. PE1 之前的最後一個 LSR 會剝離外部標籤(倒數第二個標籤彈出),並將資料包傳送到 PE1;
  4. PE1,即出 LSR,在 VRF 表中搜索內部標籤,並找到要將資料包傳送出去的埠,然後剝離內部標籤,並將資料包傳送到 CE1。
優點

此解決方案非常可擴充套件

  • 每個中間 LSR 必須處理與 PE 數量一樣多的 LSP,而不是與 IP 目的地數量一樣多的 LSP;
  • 每個 PE 必須處理與其連線的站點一樣多的 VRF 表。
缺點

PE 之間的對等會話需要手動配置。

此解決方案不提供任何加密,因為它是由提供商提供的,並且公司需要信任服務提供商。

第 3 層:虛擬路由器

[edit | edit source]
MPLS/虛擬路由器第 3 層站點到站點 VPN 示例。

在基於 MPLS 的 VPN 中,使用 **虛擬路由器**,每個 PE 為連線到它的每個公司執行一個(虛擬)路由器例項,因此每個例項只需要處理一個公司網路→協議更簡單,因為它只需要處理一個 VPN 同時,但可擴充套件性較低,因為路由器例項需要手動配置。

SSL(偽)VPN

[edit | edit source]

SSL 可用於建立站點到站點 VPN 和訪問 VPN,但它主要用於 **SSL(偽)VPN**,以透過基於 TCP/UDP 的隧道授予對服務的安全訪問(例如 Web 服務、電子郵件)。SSL(偽)VPN 的主要優勢在於,它們很有可能在任何網路場景中工作,在遍歷 NAT、防火牆或路由器時沒有任何問題,SSL 服務還可以透過 HTTPS 被 Web 瀏覽器訪問。

與替代解決方案的比較

[edit | edit source]

與 IPsec 的比較

[edit | edit source]
優點

SSL 在以下方面比 IPsec 更方便

  • 使用情況:IPsec 有太多需要配置和管理的選項,而 SSL 只需要將應用程式與實現 SSL 的庫一起編譯;
  • 安全性:它在應用層工作→對 SSL 的攻擊只涉及應用程式,而不是整個作業系統;
  • 成熟度:它已經使用了多年,並且經過了許多版本→程式碼中的錯誤很少;
  • 與 NAT 穿越的相容性
    • 沒有 IP 頭的認證,因為 SSL 位於傳輸層之上;
    • 不像 IPsec ESP 那樣加密埠。
缺點

SSL 在 DoS 攻擊中至關重要:資料包始終需要處理到傳輸層,而在 IPsec 中,它們已經在網路層被丟棄。

與 PPTP 的比較

[edit | edit source]

SSL 克服了一些 PPTP 問題

  • 與非 Microsoft 平臺的互操作性差;
  • 一些網路管理員可能會配置他們的路由器來阻止基於 PPTP 的 GRE,因為他們不喜歡源路由功能。

SSL(偽)VPN 版本

[edit | edit source]
Web 代理

Web 伺服器不支援 HTTPS→公司網路邊緣的“VPN 閘道器”[2],透過 HTTP 從 Web 伺服器下載網頁,並透過 HTTPS 將它們傳送到公司網路之外的使用者。

埠轉發

客戶端執行支援應用程式協議(如 FTP、SMTP、POP3)的應用程式→安裝在客戶端的埠轉發器將傳送到特定埠的應用程式協議資料包轉換為 HTTPS 資料包,從另一個埠傳送它們,反之亦然。

應用程式翻譯

Web 伺服器是支援應用程式協議(如 FTP、SMTP、POP3)的應用程式伺服器(例如郵件伺服器)→“VPN 閘道器”透過在“VPN 閘道器”內部實現的埠轉發機制將 HTTPS 轉換為應用程式協議,反之亦然。

SSL 加密協議

一些應用程式協議可以將 SSL 本地整合到自身中(例如 SMTP-over-SSL、POP-over-SSL)→客戶端和 Web 伺服器可以直接以安全的方式通訊,而無需“VPN 閘道器”進行翻譯。

應用程式代理

客戶端使用 SSL 加密協議,但 Web 伺服器不支援它→仍然需要“VPN 閘道器”以及埠轉發機制。

網路擴充套件

客戶端和 Web 伺服器都不支援 SSL→需要兩個“VPN 閘道器”,一個在使用者端,另一個在 Web 伺服器端,因此 SSL 隧道是在這兩個“VPN 閘道器”之間建立的。[3]

參考資料

[edit | edit source]
  1. 也可以使用路由器作為終端,但這幾乎沒有意義。
  2. 這是一個鬆散的 VPN 閘道器定義:實際上,將它定義為代理更準確。
  3. 這不是 SSL(偽)VPN。
Previous page
遷移到IPv6
計算機網路技術與服務 Next page
VoIP
VPN
華夏公益教科書