PPTP/L2TP協議講述以及應用部署

一、基本概念

PPTP

PPTP是對端對端協議（PPP）的一種擴展，它採用了PPP所提供的身份驗證、壓縮與加密機制。PPTP能夠隨TCP/IP協議一道自動進行安裝。PPTP與Microsoft端對端加密（MPPE）技術提供了用以對保密數據進行封裝與加密的VPN服務。 MPPE將通過由MS-CHAP、MS-CHAP v2身份驗證過程所生成的加密密鑰對PPP幀進行加密。爲對PPP幀中所包含的有效數據進行加密，虛擬專用網絡客戶端必須使用MS-CHAP、MS-CHAP v2身份驗證協議。

L2TP

與PPTP不同，Windows所支持的L2TP協議並非利用MPPE對PPP幀進行加密。L2TP依靠Internet協議安全性（IPSec）技術提供加密服務。L2TP與IPSec的結合產物稱爲L2TP IPSEC VPN。VPN客戶端與VPN服務器都必須支持L2TP和IPSec。也可以單獨使用L2TP，這就需要修改windows主機的註冊表，具體的修改過程，在建立"簡單的L2TP隧道"中講述。

二、數據封裝

PPTP

1.控制連接和隧道維護

PPTP控制連接建立在PPTP客戶端機IP地址和PPTP服務器IP之間，PPTP客戶端機使用動態分配的TCP端口號，而PPTP服務器則使用保留TCP端口號1723。PPTP控制連接攜帶PPTP呼叫控制和管理信息，用於維護PPTP隧道，其中包括週期性地的發送回送請求和回送應答消息，用於檢測出客戶端與服務器之間可能出現的連接中斷。PPTP控制連接數包包括一個IP報頭，一個TCP報頭和PPTP控制消息。

Star-Control-Connection-Request：由PPTP客戶機發出，請求建立控制連接

Star-Control-Connection-Reply：PPTP服務器對Star-Control-Connection-Request迴應

Outgoing-Call- Request:由PPTP客戶機發出，請求創建PPTP隧道，該消息包含GRE報頭中call id，該id可唯一地標識一條隧道

Outgoing-Call- Reply：PPTP服務器對Outgoing-Call- Request t迴應

Set-Link-Info：由PPTP客戶機或服務器任一方發出，設置PPP協商選項

Call-Clear-Request：由PPTP客戶機發出，請求終止隧道

Call-Disconnect-Notify：PPTP服務器對Call-Clear-Request迴應或者其他原因指示必須終止隧道

Stop-Control-Connection-Request：由PPTP客戶機或者服務器任一方發出，通知對端控制連接將被終止

Stop-Control-Connection-Reply：迴應Stop-Control-Connection-Request消息

2.PPTP數據封裝

將原來Ethernet數據包先封裝成PPP packet，再由GRE封裝，通過Internet傳送至接收端（注意：當身份認證協議選擇MS-chap以及MS-chapv2的時候，ppp payload將被加密）

L2TP

L2TP控制連接

L2TP控制連接建立在L2TP客戶端機IP地址和L2TP服務器IP之間，PPTP客戶端機使用動態分配的UDP端口號，而L2TP服務器則使用保留UDP端口號1701。L2TP控制連接用於隧道和會話連接的建立、維護以及傳輸控制。L2TP控制連接數包包括一個IP報頭，一個UDP報頭和L2TP控制消息。

控制連接建立和會話建立

首先由客戶端發起隧道建立請求SCCRQ（start-control-connection-request）

服務器收到後用SCCRP（start-control-connection-reply）

客戶端收到應答後返回確認SCCCN（start-control-connection-conneted）

服務器收到之後用ZLB（zero-length boby）消息作爲最後應答，其中ZLB消息是一個只有L2TP頭的控制消息，其作用是作爲一個明確應答，以確保控制消息的可靠傳輸

客戶端發起建立請求ICRQ（incoming-call-request）

服務器收到請求後返回應答ICRP（incoming-call-reply）

客戶端收到應答會返回確認ICCN（incoming-call-conneted）

服務器收到ICCN後，用ZLB消息作爲最後的應答，會話建立

L2TP數據連接

L2TP數據消息用於封裝PPP幀，並在隧道上傳輸。

工作原理

原始用戶數據爲IP報文，先經過PPP封裝，然後鏈路層將PPP幀進行L2TP封裝，將其封裝成UDP，並繼續封裝成可以在internet上傳輸的IP報文，此時的結果就是IP報文中有PPP幀，PPP幀中還有IP報文，但兩個IP地址不同，裏面的IP頭部是私有地址（原地址爲L2TP服務器動態分配的地址，目的地址爲公司內網服務器的地址），外層IP頭部的原IP是客戶端的原始地址，目的IP是L2TP服務器的地址，至此完成客戶端數據封裝，然後通過L2TP隧道將報文發送到L2TP服務器，L2TP服務器收到封裝的IP報文，發現外層IP頭部的目的地址是指定自己的，然後L2TP服務器解封裝報文，得到裏面的IP報文，然後根據IP頭部的的目的IP地址將數據包發送到內網局域網服務器。

L2TP IPSEC VPN

可以發現L2TP IPSEC VPN的數據封裝是在原始L2TP數據連接的IP頭部後面加入ESP字段的，所以這是一種傳輸模式的IPSEC隧道。因爲ESP後面的數據是經過加密的，所以這裏就不例舉抓包結果了。

三．協議和算法介紹

PPP

1.工作流程

一個IP分組需要傳輸，出發PPP層啓動連接過程，LCP協議負責完成連接的建立過程，PAP或者CHAP協議完成身份認證，IPCP協議進一步完成網絡層協議協商，當以上過程都成功完成之後，IP分組封裝在PPP幀中傳輸到對方

2.協議分析

LCP：負責鏈路的建立，維護以及拆除

CHAP：對客戶端進行身份認證

IPCP：負責協商IP地址以及DNS等信息

CCP：負責壓縮的協商

GRE

1.概述

GRE（通用路由封裝）定義了在任意一種網絡層協議上封裝任意一個其它網絡層協議的協議。

2.封裝

在大多數情況下，系統擁有一個有效載荷包，需要將它封裝併發送某個目的地。首先將有效載荷封裝在一個GRE包中，然後將此GRE包封裝在其它某協議中並進行轉發。比如在PPTP隧道中，IP包封裝GRE包，在IP頭部中指明下層協議GRE的協議號47，GRE包封裝PPP包，在GRE頭部中指明下層協議PPP的協議號0x880b

3.應用

GRE OVER IPSEC

當數據包到達隧道一端A，A查詢路由，發現去往該目的地的數據包需要經過GRE封裝，在原始的數據包上加上GRE頭部以及新的ip頭部，然後A重新查詢規則，發現該新的ip頭部需要經過ipsec模塊處理，所以數據包又經過加密封裝之後，查詢路由之後發送到隧道對端B，B發現該數據包的目的是發給自己的，解封裝時ip頭部的協議字段指明封裝的是ESP或者AH，然後B解密等操作，發現該數據包的原始目的，查詢路由之後，該數據包送到保護網絡中。因爲ipsec並不能承載動態路由協議以及組播，所以需要用到這兩種技術的時候，可以選擇GRE OVER IPSEC。

IPSEC OVER GRE

沒有什麼實際的使用意義

PPTP

請查看PPTP的講述

L2TP

請查看L2TP的講述

PAP

口令直接以明文在網絡上傳輸，建議選擇CHAP，更安全。

CHAP

CHAP是一種加密的驗證方式，能夠避免建立連接時傳送用戶的真實密碼，服務器向客戶端發送一個挑戰口令challenge，其中包括會話ID和一個任意生成的挑戰字符串。當客戶端收到後，必須使用MD5算法計算用戶口令以及挑戰口令的hash值，然後將這個hash值和用戶名傳送給服務器。因爲服務器上有該用戶名和口令，然後服務器同樣使用MD5算法計算出該用戶密碼和挑戰口令的hash值，與客戶端傳送給自己的hash值比較，如果相同的話，則身份驗證通過。

Challenge=session_id+challenge_string
Respond=md5(session_id+challenge_string+user_passwd)+uer_name

四．應用環境

建立虛擬專用網絡

第一步： pc機上網絡鄰居-----屬性

第二步：在網絡連接中選擇"創建一個新的連接"

第三步：在彈出的"新建連接嚮導"中選擇下一步

第四步：選擇"連接到我的工作場所的網絡"，然後下一步

第五步：選擇"虛擬專用網絡連接"，然後下一步

第六步：輸入公司名，我這裏輸入的是leadsec，這個是隨便怎麼寫的，然後下一步

第七步：選擇"不撥初始連接"，然後下一步

第八步：輸入服務器的ip地址，然後下一步

第九步：選擇完成即可

不經過NAT的PPTP隧道

1. 拓撲圖

2.環境描述

經過專線的遠程用戶連接互聯網，該遠程用戶需要連接到公司局域網，需要與公司出口防火牆建立PPTP隧道，當建立PPTP隧道成功之後，測試該遠程用戶是否還能訪問互聯網

3.配置

在遠程用戶的虛擬專用網絡屬性中指定VPN類型是PPTP VPN，項目只選擇Internet協議（TCP/IP），常規選項中填入目的主機地址124.1.1.2，在安全選項中選擇高級，指定數據加密可選加密，允許認證協議MSCHAP以及MS-CHAPV2,其他參數保持默認(3.4.6.8版本以及之前的版本必須這麼配置)

在防火牆處開啓PPTP服務，配置遠程撥號用戶以及全局的地址池或者用戶中的虛擬ip地址（如果用戶中配置有虛擬ip地址，則該地址優先與地址池中地址分配給遠程用戶）

連接虛擬專用網絡leadsec

查看防火牆給遠程用戶分配的虛擬地址10.10.10.2

查看虛擬專用網絡leadsec的狀態，類型是PPTP，身份驗證MS CHAP V2,，分配給遠程客戶端地址爲10.10.10.2，防火牆PPTP服務器虛擬地址10.10.10.1

查看遠程客戶端的路由變化，第一條默認路由是虛擬專用網絡leadsec連接成功之後添加，它的網關爲它自己，並且它的度量值爲1，比第二條默認路由的度量值小，所以默認查不到明細路由的數據包都送到第一條默認路由進行處理。所以虛擬專用網絡leadsec連接之後，遠程用戶不能再訪問互聯網地址，只能訪問公司局域網

查看防火牆的路由變化，多了到目的網絡10.10.10.2的出接口ppp0的明細路由

經過NAT的PPTP隧道

1.拓撲圖

2.環境描述

分支機構通過出口FW1連接互聯網，在出口FW1上作NAT，將172.16.1.0/24網段轉換爲出口FW1的外網口地址211.103.135.192，現在分支結構需要通過PPTP隧道連接到公司總部局域網。

3.配置

在公司總部出口FW2上添加兩個遠程撥號用戶，並且開啓PPTP服務

在出口FW1上作NAT轉化，將172.16.1.0/24到any的流量源地址轉化爲211.103.135.192

分別在分支結構的兩個客戶端建立虛擬撥號連接，連接到211.103.135.192，具體的參數配置參考"不經過NAT的PPTP隧道"，這裏不再詳述了。接下來要分析的是PPTP穿越NAT的工作機制

PPTP穿越NAT的工作機制

我們知道GRE（請看GRE協議介紹）是沒有端口信息的，並且它是跟TCP、UDP是同一層的，GRE的ip協議號是47，TCP的ip協議號是6，UDP的ip協議號是17。那GRE穿越NAT的時候怎麼映射呢？這個時候你可能會想到那就只轉換ip不就得了，但是這對防火牆是個問題。接下來我們就來分析下：如果處於分支機構的主機A172.16.1.2（NAT轉換爲211.103.135.192）與pptp服務器211.103.135.221建立連接，控制連接成功建立，數據連接由於沒有端口，NAT只做其ip的轉換，於是在出口FW1上有這樣的一個NAT表：

SIP	SPort	Proto	轉換地址	轉換端口	DIP	DPort
172.16.1.2	5000	TCP	211.103.135.192	5001	192.168.1.2	1723
172.16.1.2		GRE	211.103.135.192		192.168.1.2

當211.103.135.192這個防火牆收到來自於pptp服務器211.103.135.221的數據流包時，211.103.135.192這個 nat設備發現來自於網絡211.103.135.221的gre 協議數據包，是給分支結構的172.16.1.2主機的，所以成功通信。分析如果位於分支結構的172.16.1.3 也與211.103.135.221的pptp服務器通信，結果就不太理想了。因爲如果在nat表中還有一條到達主機172.16.1.3的gre通信，到收到一個gre協議數據包時，211.103.135.192這個nat設備猶豫了，這個包給誰呢？172.16.1.2?還是172.16.1.3呢？在此大家也不要忘了，我們的實驗環境是隻有一個公網ip,分支結構的172.16.1.2和172.16.1.3出去的時候，源ip都轉換成了公網的ip211.103.135.192，所以收到的數據包都是目標ip爲211.103.135.192，然後nat設備根據端口的不同轉發到不同的主機，但是又因爲GRE根本就沒有端口這一說法，所以有兩個客戶端就無法通信。

當然了，明知道PPTP穿越NAT的時候有問題，我們就要解決它，就好像IPSEC穿越NAT的時候，就需要在IPSEC包頭前面額外的插上UDP。人們發現gre協議中有一個字段，可以拿來利用，那就是這個call id值，這個值並不固定，可以改變。這個值是怎麼回事呢？用來標識唯一會話的。這個值最早出現在控制連接中，客戶端與服務器互相通告彼此的call id值，然後在其數據連接中，服務器call 　id值寫上客戶端的，客戶端寫上服務器的call　id值。所以我可以把call id值當做端口來看，然後添加到nat表中。下面來具體分析下call id和nat轉化的關係了！！！

分析客戶端172.16.1.2到PPTP服務器211.103.135.221的PPP以及GRE數據報

172.16.1.2到211.103.135.221的Outgoing-Call-Request包中表明自己的call id爲3277

211.103.135.221到172.16.1.2的Outgoing-Call-Reply包中表明自己的call id爲3712，並指明客戶端的call id爲3277

172.16.1.2到211.103.135.221的GRE包中會攜服務器的call id 3712

211.103.135.221到172.16.1.2的GRE包中會攜客戶端的call id 3277

接下來看下NAT設備的NAT表

將NAT錶轉化爲圖標的形式爲：（注意需要把srckey以及deskey當成源端口以及目的端口，並且將十六進制轉化爲十進制）

SIP	SPort	Proto	轉換地址	轉換端口	DIP	DPort
172.16.1.2	3277	TCP	211.103.135.192	3277	211.103.135.221	1723
172.16.1.2	62524	GRE	211.103.135.192	3712	211.103.135.221	3712
211.103.135.221	3712	GRE	211.103.135.192	3277	172.16.1.2	3277
172.16.1.3	2051	TCP	211.103.135.192	1723	211.103.135.221	1723
172.16.1.3	32768	GRE	211.103.135.192	3840	211.103.135.221	3840
211.103.135.221	3840	GRE	211.103.135.192	2051	172.16.1.3	2051