關於LCP協商

著作權聲明
：轉載時請以超連結形式標明文章原始出處和作者資訊及本聲明

http://tianyunxing.blogbus.com/logs/61114327.html

 

PPP協議在進行LCP協商的時候，雙方是互相發送configure-request，然後向對方回應configure-ack，也可以只有一
方發送，另一方回應。

PAP驗證過程：
兩次握手協議，當兩端鏈路可以相互傳輸資料時，被驗證方發送本端的使用者名稱以及口令到驗證方，驗證方根據本端的使用者表（或
者radius伺服器）查看是否正確，如果正確發送ACK報文給對方，否則發送NAK報文。驗證失敗也並不會直接關閉鏈路，而是只有驗證次數達到一定值時
才關閉鏈路。

CHAP驗證過程：
三向交握協議，只在網路中傳輸使用者名稱而不傳輸使用者口令。首先驗證方向被驗證方發送隨機產生的
報文，並同時將本端主機名稱附帶上一起發給被驗證方，被驗證方接到報文後，則根據報文中驗證方的主機名稱和本端的使用者表尋找使用者口令字。找到，則利用報文
id，此使用者的密鑰用MD5演算法產生應答，隨後將應答和自己的主機名稱送回驗證方接到此應答後用報文ID
本方保留的口令字密鑰和隨機報文用Md5演算法得出結果與被驗證方應答比較根據比較結果返回相應的結果。

PAP與CHAP最大的不同點
是：
PAP是首先由被驗證方將自己的使用者名稱及密碼送給驗證方而CHAP驗證是首先由驗證方發起驗證過程的主要區別為PAP為明文傳送密碼而在
CHAP驗證過程中密碼是不線上傳送的。

MP多鏈路捆綁
MP為PPP功能擴充協議，只有兩個鏈路的
Discriminator和驗證方式使用者完全相符時才能對兩個鏈路進行捆綁，這就意味著只有當驗證完成後才能真正完成MP的協商過程，MP不會導致鏈路
的拆除， 如果配置了MP
兩個鏈路不符合MP條件則會建立一條新的MP通道，這同時也表明允許MP為單鏈路。MP的捆綁是完全依照使用者進行的，只有相同使用者才能進行捆綁，如一端配
置了MP 另一端不支援或未配MP 則建立起來的鏈路為非MP鏈路。

PPP協議簡介

PPP
協議，其全稱為（Point-To-Point
Protocol）點到點協議，它作為一種提供在點到點鏈路上傳輸封裝網路層資料包的資料連結層協議，處於TCP/IP協議棧的第二層，主要被設計用來在
支援全雙工系統的同非同步鏈路上進行點到點之間的資料轉送。
PPP主要由三類協議組成，鏈路控制協議族（LCP）網路層控制協議族（NCP）和PPP擴
展協議族，其中鏈路控制協議主要用於建立拆除和監控PPP資料鏈路，網路層控制協議族主要用於協商在該資料鏈路上所傳輸的資料包的格式與類型，PPP擴充
協議族主要用於提供對PPP功能的進一步支援，同時 PPP還提供了用於網路安全方面的驗證協議族（PAP和CHAP）。
PPP
協議的特點

        PPP協議與其他鏈路層協議不同 既支援同步鏈路又支援非同步鏈路，而如X25
framerelay等資料連結層協議只對同步鏈路提供支援；
        具有各種NCP協議 如IPCP,
IPXCP更好地支援了網路層協議；
        具有驗證協議CHAP PAP 更好了保證了網路的安全性；
    
   易擴充；
PPP的協商過程

PPP在建立鏈路之前要進行一系列的協商過程，過程如下：PPP首先
進行LCP協商，協商內容包括：MTU(傳輸單元最大值)、魔術字(magic number)、驗證方式、非同步字元對應表等選項(詳見RFC1661)
LCP協商成功後，進入Establish(鏈路建立)階段，如配置了CHAP或PAP驗證，便進入CHAP或PAP驗證階段，驗證通過後才會進入網路階
段協商(NCP)，如IPCPIPXCP、BCP的協商，任何階段的協商失敗都將導致鏈路的拆除，魔術字，主要用於檢測鏈路自環，PPP靠發送Echo
Request、Echo Reply報文來檢測自環和維護鏈路狀態，如連續發現有超過最大自環允許數目Echo
Request報文中魔術字與上次發送魔術字相同，則判定網路發生自環現象，如鏈路發生自環，則就需採取相應措施對鏈路複位
另外，LCP發送config request時也可以檢測自環，LCP發現自環後，在發送一定數目的報文後也會複位鏈路，如果PPP發送的Echo
Request 報文產生丟失，則在連續丟失最大允許丟失的個數之後，將鏈路複位，以免過多的無效資料轉送，非同步字元對應表用於同非同步轉換。

PAP的驗證過程

PAP為兩次握手協議，它通過使用者名稱及口令來對使用者進行驗證。PAP驗證過程如下：當
兩端鏈路可相互傳輸資料時，被驗證方發送本端的使用者名稱及口令到驗證方，驗證方根據本端的使用者表或radius伺服器，查看是否有此使用者，口令是否正確，如
正確則會給對端發送ACK報文，通告對端已被允許進入下一階段協商，否則發送NAK報文，通告對端驗證失敗，此時並不會直接將鏈路關閉，只有當驗證不過次
數達到一定值時，才會關閉鏈路，來防止因誤傳、網路幹擾等造成不必要的LCP重新協商過程。PAP的特點是在網路上以明文的方式傳遞使用者名稱及口令，如在傳
輸過程中被截獲便有可能對網路安全造成極大的威脅。因此，它適用於對網路安全要求相對較低的環境。
CHAP的驗證過程

CHAP
為三向交握協議，它的特點是：只在網路上傳輸使用者名稱，而並不傳輸使用者口令，因此，它的安全性要比PAP高。CHAP的驗證過程為：首先由驗證方向被驗證方
發送一些隨機產生的報文，並同時將本端的主機名稱附帶上一起發送給被驗證方，被驗證方接到對端對本端的驗證請求(Challenge)時，便根據此報文中驗
證方的主機名稱和本端的使用者表尋找使用者口令字，如找到使用者表中與驗證方主機名稱相同的使用者，便利用報文ID，此使用者的密鑰用Md5演算法產生應
答，Response
隨後將應答和自己的主機名稱送回，驗證方接到此應答後，用報文ID、本方保留的口令字（密鑰）和隨機報文用Md5演算法得出結果，與被驗證方應答比較，根據比
較結果返回相應的結果。
比較

PAP是首先由被驗證方將自己的使用者名稱及密碼送給驗證方，而CHAP驗證是首先由驗證方發起驗證過程的，主要區別為PAP為明文傳送密碼，而在
CHAP驗證過程中，密碼是不線上傳送的。

所以，這
就是我們在用協議分析軟體捕獲資料包時看不到密碼的原因所在，是由於驗證方式採用了CHAP驗證，密碼不是線上明文傳輸。

http://www.bbfish.net/vpn/vpn_7551.html