PPP驗證（PAP和CHAP）

ppp協定

PPP協定是一種點到點的鍊路協定，主要運用于在全雙工的鍊路上進行點到點的資料傳輸

特點：

-支援點到點和點到多點

-支援同步和異步串行服務

-可同時支援多種網絡層協定

-支援驗證

-支援位址自動協商，能夠遠端配置設定IP位址

PPP組成：

LCP:鍊路控制協定，負責實體層和二層的協商（用來建立、拆除和監控PPP資料鍊路）

NCP:網絡控制協定，負責和三層協商（對于不同的網絡層協定進行連接配接建立和參數協商）

<a href="https://s5.51cto.com/wyfs02/M00/9D/C5/wKioL1mFqFayaH9mAAA8D6TTPW4904.png-wh_500x0-wm_3-wmp_4-s_471382616.png" target="_blank"></a>

PPP鍊路認證如下：

1：Dead階段是沒有進行任何連接配接的階段，為不可用階段，隻有當兩端檢測到實體接口被激活的時候，才會從Dead階段到Establish階段，也叫鍊路建立階段。

2：在Establish階段，PPP鍊路進行LCP參數協商。協商内容包括MRU、認證方式、魔術字等，LCP參數協商成功後會進入Opened狀态，表示底層鍊路已經建立。

3：接下來就是鍊路兩端的裝置需要經過認證階段（Authenticate）才能進入到網絡層協定階段，如果在這個階段再次收到了Configure-Request封包，則又會傳回到鍊路建立階段。

4：在Network階段，PPP鍊路進行NCP協商，隻有相應的網絡層協定協商成功後，該網絡層協定才可以通過這條PPP鍊路發送封包。如果在這個階段收到了Configure-Request封包，也會傳回到鍊路建立階段。

5：NCP協商成功後，PPP鍊路保持通信狀态。

6：在Terminate階段，如果所有的資源都被釋放，通信雙方将回到Dead狀态，直達通信雙方建立起一個PPP連接配接。

PS：Configure-Request（配置請求）：鍊路層協商過程中發送的第一個封包，該封包表明點對點雙方開始進行鍊路層參數的協商。

MRU：最大接受單元

認證方式：包括PAP和CHAP

魔術字：随機産生一個數值，檢測鍊路上是否有環路，如果收到的LCP封包中的魔術字和本段産生的魔術字一樣，就認為有環路。但是要保證兩端的數字都是一樣的，基本上為0

首先了解一下這些名詞，：

1. Configure-Request（配置請求）：鍊路層協商過程中發送的第一個封包，該封包表明點對點雙方開始進行鍊路層參數的協商。

2. Configure-Ack（配置響應）：收到對端發來的Configure-Request封包，如果參數取值完全接受，則以此封包響應。

3. Configure-Nak（配置不響應）：收到對端發來的Configure-Request封包，如果參數取值不被本端認可，則發送此封包并且攜帶本端可接受的配置參數。

4. Configure-Reject（配置拒絕）：收到對端發來的Configure-Request封包，如果本端不能識别對端發送的Configure-Request中的某些參數，則發送此封包并且攜帶那些本端不能認别的配置參數。

<a href="https://s1.51cto.com/wyfs02/M02/9D/C6/wKiom1mFqJGxyZWXAABVEg4r6B0520.png-wh_500x0-wm_3-wmp_4-s_2077678285.png" target="_blank"></a>

1：RTA發送一個Configure-Request封包，這個封包中包含RTA上的鍊路層上的一些參數，當RTB收到這個配置請求之後，如果RTB能夠識别，那麼就會向RTA發送Configure-Ack封包。

2：當然，RTA不會等到RTB主動回複資訊，RTA每隔3次就會發送一次，連續發10次，如果還沒有收到Configure-Ack封包，就會停止發送

3：當RTB收到RTA發送的Configure-Request封包之後，如果RTB能識别此封包中攜帶的所有鍊路層參數，但是認為部分或全部參數的取值不能接受，即參數的取值協商不成功，則RTB需要向RTA發送一個Configure-Nak封包。

4：當RTB收到RTA發送的Configure-Request封包之後，如果RTB不能識别此封包中攜帶的部分或全部鍊路層參數，則RTB需要向RTA回應一個Configure-Reject封包。在此Configure-Reject封包中，隻包含不能被識别的鍊路層參數。在收到Configure-Reject封包之後，RTA需要向RTB重新發送一個Configure-Request封包

以上隻是LCP鍊路上的一些協商配置過程，接下來是認證過程（PAP和CHAP）

<a href="https://s1.51cto.com/wyfs02/M01/9D/C6/wKiom1mFqKrg28E4AABxtH5CKNM416.png-wh_500x0-wm_3-wmp_4-s_1408433414.png" target="_blank"></a>

pap認證使用的是兩次握手協定，密碼以明文的方式在鍊路上傳輸。在LCP鍊路上寫上完成後，認證方要求被驗證方進行pap認證。

被認證方将配置的使用者名和密碼資訊使用Authenticate-Request封包以明文方式發送給認證方。認證方收到被認證方發送的使用者名和密碼資訊之後，根據本地配置的使用者名和密碼資料庫檢查使用者名和密碼資訊是否比對，如果比對，則傳回Authenticate-Ack封包，表示認證成功。否則，傳回Authenticate-Nak封包，表示認證失敗。

<a href="https://s1.51cto.com/wyfs02/M01/9D/C5/wKioL1mFqLmQJ4H8AAB0Ma-ivrc378.png-wh_500x0-wm_3-wmp_4-s_2976200182.png" target="_blank"></a>

CHAP需要三次驗證，是一種比較安全的認證方式。它有一個加密算法，這個算法叫做MD5，它是一個不可逆的過程，通常我們也會在網上看到一些解密MD5的網站，但是這些網站是依靠強大的資料庫進行碰撞得出的結果，現在還沒有一個有效的解密的手段去對他解密。

1. LCP協商完成後，認證方發送一個Challenge封包給被認證方，認證方很皮，他要挑戰一下被認證方。

2. 被認證方收到此Challenge封包之後，也皮一下，進行一次加密運算，也是MD5運算，得到一個16位元組長的摘要資訊，然後将此摘要資訊和端口上配置的CHAP使用者名一起封裝在Response封包中發到認證方那裡去。

3. 認證方接收到被認證方發送的Response封包之後，按照Response的使用者名在認證方的本地查找相應的密碼資訊，得到密碼資訊之後，進行一次加密運算，運算方式和被認證方的加密運算方式相同，然後将加密運算得到的摘要資訊和Response封包中封裝的摘要資訊做比較，相同則認證成功，不相同則認證失敗。

本文轉自 towardly 51CTO部落格，原文連結:http://blog.51cto.com/brighttime/1953874