- 掛牌上市企業
- 60秒人工響應
- 99.99%連通率
- 7*24h人工
- 故障100倍補償
點對點協議 |
| 發布時間: 2012/7/26 16:27:35 |
|
因為第2層隧道協議在很大程度上依靠PPP協議的各種特性，因此有必要對PPP協議進行深入的探討。PPP協議主要是設計用來通過撥號或專線方式建立點對點連接發送數據。PPP協議將IP，IPX和NETBEUI包封裝在PP楨內通過點對點的鏈路發送。PPP協議主要應用于連接撥號用戶和NAS。 PPP撥號會話過程可以分成4個不同的階段。分別如下： 階段1：創建PPP鏈路 PPP使用鏈路控制協議（LCP）創建，維護或終止一次物理連接。在LCP階段的初期，將對基本的通訊方式進行選擇。應當注意在鏈路創建階段，只是對驗證協議進行選擇，用戶驗證將在第2階段實現。同樣，在LCP階段還將確定鏈路對等雙方是否要對使用數據壓縮或加密進行協商。實際對數據壓縮/加密算法和其它細節的選擇將在第4階段實現。 階段2：用戶驗證 在第2階段，客戶會PC將用戶的身份明發給遠端的接入服務器。該階段使用一種安全驗證方式避免第三方竊取數據或冒充遠程客戶接管與客戶端的連接。大多數的PPP方案只提供了有限的驗證方式，包括口令驗證協議（PAP），挑戰握手驗證協議（CHAP）和微軟挑戰握手驗證協議（MSCHAP）。 1.口令驗證協議（PAP） PAP是一種簡單的明文驗證方式。NAS要求用戶提供用戶名和口令，PAP以明文方式返回用戶信息。很明顯，這種驗證方式的安全性較差，第三方可以很容易的獲取被傳送的用戶名和口令，并利用這些信息與NAS建立連接獲取NAS提供的所有資源。所以，一旦用戶密碼被第三方竊取，PAP無法提供避免受到第三方攻擊的保障措施。 2.挑戰-握手驗證協議（CHAP） CHAP是一種加密的驗證方式，能夠避免建立連接時傳送用戶的真實密碼。NAS向遠程用戶發送一個挑戰口令（challenge），其中包括會話ID和一個任意生成的挑戰字串（arbitrary challengestring）。遠程客戶必須使用MD5單向哈希算法（one-wayhashingalgorithm）返回用戶名和加密的挑戰口令，會話ID以及用戶口令，其中用戶名以非哈希方式發送。 CHAP對PAP進行了改進，不再直接通過鏈路發送明文口令，而是使用挑戰口令以哈希算法對口令進行加密。因為服務器端存有客戶的明文口令，所以服務器可以重復客戶端進行的操作，并將結果與用戶返回的口令進行對照。CHAP為每一次驗證任意生成一個挑戰字串來防止受到再現攻擊（replay attack).在整個連接過程中，CHAP將不定時的向客戶端重復發送挑戰口令，從而避免第3方冒充遠程客戶（remoteclient impersonation)進行攻擊。 3.微軟挑戰-握手驗證協議（MS-CHAP） 與CHAP相類似，MS-CHAP也是一種加密驗證機制。同CHAP一樣，使用MS-CHAP時，NAS會向遠程客戶發送一個含有會話ID和任意生成的挑戰字串的挑戰口令。遠程客戶必須返回用戶名以及經過MD4哈希算法加密的挑戰字串，會話ID和用戶口令的MD4哈希值。采用這種方式服務器端將只存儲經過哈希算法加密的用戶口令而不是明文口令，這樣就能夠提供進一步的安全保障。此外，MS-CHAP同樣支持附加的錯誤編碼，包括口令過期編碼以及允許用戶自己修改口令的加密的客戶-服務器（client-server)附加信息。使用MS-CHAP，客戶端和NAS雙方各自生成一個用于隨后數據加密的起始密鑰。MS-CHAP使用基于MPPE的數據加密，這一點非常重要，可以解釋為什么啟用基于MPPE的數據加密時必須進行MS-CHAP驗證。 在第2階段PPP鏈路配置階段，NAS收集驗證數據然后對照自己的數據庫或中央驗證數據庫服務器（位于NT主域控制器或遠程驗證用戶撥入服務器）驗證數據的有效性。 階段3：PPP回叫控制（callbackcontrol) 微軟設計的PPP包括一個可選的回叫控制階段。該階段在完成驗證之后使用回叫控制協議（CBCP）如果配置使用回叫，那么在驗證之后遠程客戶和NAS之間的連接將會被斷開。然后由NAS使用特定的電話號碼回叫遠程客戶。這樣可以進一步保證撥號網絡的安全性。NAS只支持對位于特定電話號碼處的遠程客戶進行回叫。 階段4：調用網絡層協議 在以上各階段完成之后，PPP將調用在鏈路創建階段（階段1）選定的各種網絡控制協議（NCP).例如，在該階段IP控制協議（IPCP）可以向撥入用戶分配動態地址。在微軟的PPP方案中，考慮到數據壓縮和數據加密實現過程相同，所以共同使用壓縮控制協議協商數據壓縮（使用MPPC）和數據加密（使用MPPE）。 數據傳輸階段 一旦完成上述4階段的協商，PPP就開始在連接對等雙方之間轉發數據。每個被傳送的數據報都被封裝在PPP包頭內，該包頭將會在到達接收方之后被去除。如果在階段1選擇使用數據壓縮并且在階段4完成了協商，數據將會在被傳送之間進行壓縮。類似的，如果如果已經選擇使用數據加密并完成了協商，數據（或被壓縮數據）將會在傳送之前進行加密。 點對點隧道協議（PPTP） PPTP是一個第2層的協議，將PPP數據楨封裝在IP數據報內通過IP網絡，如Internet傳送。PPTP還可用于專用局域網絡之間的連接。RFC草案“點對點隧道協議”對PPTP協議進行了說明和介紹。該草案由PPTP論壇的成員公司，包括微軟，Ascend，3Com，和ECI等公司在1996年6月提交至IETF�？稍谌缦抡军chttp://www.ietf.org http://www.ietf.org參看草案的在線拷貝.PPTP使用一個TCP連接對隧道進行維護，使用通用路由封裝（GRE）技術把數據封裝成PPP數據楨通過隧道傳送。可以對封裝PPP楨中的負載數據進行加密或壓縮。圖7所示為如何在數據傳遞之前組裝一個PPTP數據包。 第2層轉發（L2F） L2F是Cisco公司提出隧道技術，作為一種傳輸協議L2F支持撥號接入服務器將撥號數據流封裝在PPP楨內通過廣域網鏈路傳送到L2F服務器（路由器）。L2F服務器把數據包解包之重新注入（inject)網絡。與PPTP和L2TP不同，L2F沒有確定的客戶方。應當注意L2F只在強制隧道中有效。（自愿和強制隧道的介紹參看“隧道類型”）。 第2層隧道協議（L2TP） L2TP結合了PPTP和L2F協議。設計者希望L2TP能夠綜合PPTP和L2F的優勢。 L2TP是一種網絡層協議，支持封裝的PPP楨在IP，X.25，楨中繼或ATM等的網絡上進行傳送。當使用IP作為L2TP的數據報傳輸協議時，可以使用L2TP作為Internet網絡上的隧道協議。L2TP還可以直接在各種WAN媒介上使用而不需要使用IP傳輸層。草案RFC“第2層隧道協議”對L2TP進行了說明和介紹。該文檔于1998年1月被提交至IETF�？梢栽谝韵戮W站http://www.ietf.org http://www.ietf.org獲得草案拷貝。 IP網上的L2TP使用UDP和一系列的L2TP消息對隧道進行維護。L2TP同樣使用UDP將L2TP協議封裝的PPP楨通過隧道發送�？梢詫Ψ庋bPPP楨中的負載數據進行加密或壓縮。圖8所示為如何在傳輸之前組裝一個L2TP數據包。 PPTP與L2TP PPTP和L2TP都使用PPP協議對數據進行封裝，然后添加附加包頭用于數據在互聯網絡上的傳輸。盡管兩個協議非常相似，但是仍存在以下幾方面的不同： 1.PPTP要求互聯網絡為IP網絡。L2TP只要求隧道媒介提供面向數據包的點對點的連接。L2TP可以在IP（使用UDP），楨中繼永久虛擬電路（PVCs),X.25虛擬電路（VCs）或ATM VCs網絡上使用。 2.PPTP只能在兩端點間建立單一隧道。L2TP支持在兩端點間使用多隧道。使用L2TP，用戶可以針對不同的服務質量創建不同的隧道。 3.L2TP可以提供包頭壓縮。當壓縮包頭時，系統開銷（overhead）占用4個字節，而PPTP協議下要占用6個字節。 4.L2TP可以提供隧道驗證，而PPTP則不支持隧道驗證。但是當L2TP或PPTP與IPSEC共同使用時，可以由IPSEC提供隧道驗證，不需要在第2層協議上驗證隧道。 IPSec隧道模式 IPSEC是第3層的協議標準，支持IP網絡上數據的安全傳輸。本文將在“高級安全”一部分中對IPSEC進行詳細的總體介紹，此處僅結合隧道協議討論IPSEC協議的一個方面。除了對IP數據流的加密機制進行了規定之外，IPSEC還制定了IPoverIP隧道模式的數據包格式，一般被稱作IPSEC隧道模式。一個IPSEC隧道由一個隧道客戶和隧道服務器組成，兩端都配置使用IPSEC隧道技術，采用協商加密機制。 為實現在專用或公共IP網絡上的安全傳輸，IPSEC隧道模式使用的安全方式封裝和加密整個IP包。然后對加密的負載再次封裝在明文IP包頭內通過網絡發送到隧道服務器端。隧道服務器對收到的數據報進行處理，在去除明文IP包頭，對內容進行解密之后，獲的最初的負載IP包。負載IP包在經過正常處理之后被路由到位于目標網絡的目的地。 IPSEC隧道模式具有以下功能和局限： 1.只能支持IP數據流 2.工作在IP棧（IPstack）的底層，因此，應用程序和高層協議可以繼承IPSEC的行為。 3.由一個安全策略（一整套過濾機制）進行控制。安全策略按照優先級的先后順序創建可供使用的加密和隧道機制以及驗證方式。當需要建立通訊時，雙方機器執行相互驗證，然后協商使用何種加密方式。此后的所有數據流都將使用雙方協商的加密機制進行加密，然后封裝在隧道包頭內。 關于IPSEC的詳細介紹參看本文稍后的“高級安全”部分。 本文出自：億恩科技【www.zuiquanben.com】 |
0371-60135900
京公網安備41019702002023號
香港服務器租用
美國服務器租用
電信骨干機房
聯通骨干機房
