ppp的兩種認證方式（ppp專案的要求和條件）

點到點鏈路層協議PPP（PPPoE） 主要用於在全雙工的同非同步鏈路上進行點到點的資料傳輸，PPP是一款公有標準協議，相容性好。

PPP協議的特點：

1、PPP支援在全雙工的同非同步鏈路上進行點到點的資料傳輸。

2、PPP具有很好的擴充套件性；PPPoE就是承載在乙太網鏈路上的PPP協議。

3、PPP支援地址資訊的自動協商；LCP協議用於各種鏈路層引數的協商；NCP協議用於各網路層引數的協商，更好地支援了網路層協議（peer neighbor-route）。

4、PPP支援PAP、CHAP認證（可以基於介面的密碼認證；也可以基於本地資料庫AAA認證，提供認證、授權和審計），更好的保證了網路的安全性。

5、PPP支援將多根鏈路進行捆綁（Multilink）；支援對所有型別的報文/報頭進行壓縮；無重傳機制，網路開銷小，速度快。

PPP協議的組成：協議傘

步驟一：鏈路控制協議LCP；用來建立、拆除和監控PPP資料鏈路

步驟二：認證協議；PAP（密碼認證協議）和CHAP（挑戰握手認證協議）；用於鏈路認證，支援單向認證和雙向認證。

步驟三：網路層控制協議NCP（協議傘）；用於對不同的網路層協議進行連線建立和引數協商；協議包含了IPV4CP（IPCP）、IPV6CP、IPXCP等。

PPP鏈路的建立過程：

1、Dead階段也稱為物理層不可用階段。當通訊雙方的兩端檢測到物理線路啟用時，就會從Dead階段遷移至Establish階段，即鏈路建立階段。

2、Establish階段，PPP鏈路會進行LCP引數協商。協商內容包括最大接收單元MRU、認證方式、魔術字（Magic Number）等選項。LCP引數協商成功後會進入Opened狀態，表示底層鏈路已經建立。

3、多數情況下,鏈路兩端的裝置是需要經過認證階段（Authenticate）後才能夠進入到網路層協議協商階段。PPP鏈路在預設情況下是不要求進行認證的。如果要求認證，則在鏈路建立階段必須指定認證協議。認證方式是在鏈路建立階段雙方進行協商的。如果在這個階段再次收到了Configure-Request報文，則又會返回到鏈路建立階段。

4、Network階段，PPP鏈路進行NCP協商。通過NCP協商來選擇和配置一個網路層協議並進行網路層引數協商。只有相應的網路層協議協商成功後，網路層協議才可以通過這條PPP鏈路傳送報文。如果在這個階段收到了Configure-Request報文，也會返回到鏈路建立階段。

5、NCP協商成功後，PPP鏈路將保持通訊狀態。PPP執行過程中，可以隨時中斷連線，例如物理鏈路斷開、認證失敗、超時定時器時間、管理員通過配置關閉連線等動作都可能導致鏈路進入Terminate階段。

6、在Terminate階段，如果所有的資源都被釋放，通訊雙方將回到Dead階段，直到通訊雙方重新建立PPP連線。

PPP協議的幀格式：

1、Flag欄位標識一個物理幀的起始和結束，為二進位制序列01111110（0X7E）。

2、address欄位，固定為11111111 （0XFF），是一個廣播地址。

3、control欄位預設為00000011(0X03)，表明為無序號幀。

4、protocol欄位用來說明PPP所封裝的協議報文型別，0XC021代表LCP報文，0XC023代表PAP報文，0XC223代表CHAP報文，0X0021代表IPV4報文。

5、FCS欄位是個16位的校驗和，用於檢查PPP資料幀的完整性。

Information欄位包含協議欄位中指定協議的資料包。資料欄位的預設最大長度（不包括協議欄位）稱為最大接收單元MRU（Maximum Receive Unit），MRU的預設值為1500位元組。如果協議欄位被設為0XC021，則說明通訊雙方正通過LCP報文進行PPP鏈路的協商和建立：

1、Code欄位主要是用來標識LCP資料包文的型別。配置資訊報文（Configure Packets: 0x01)，配置成功資訊報文(Configure-Ack: 0X02)，終止請求報文(Terminate-Request：0X05)。

2、Identifier欄位表示用來匹配請求和響應報文。

3、length欄位表示LCP的報文長度

Data欄位為資料載荷，包含了多個TLV為可選項欄位，包含型別、長度和數值

LCP報文型別和工作過程：

1、Configure-Request配置請求報文：鏈路層協商過程中傳送的第一個報文，該報文表明點對點雙方開始進行鏈路層引數的協商。可以協商的內容如下：

---最大接收單元MRU，表示PPP資料幀中資訊欄位和填充欄位的總長度；預設值為1500位元組。

---認證協議，PAP協議和CHAP協議，一條PPP鏈路的兩端可以使用不同的認證協議認證對端，但是被認證方必須支援認證方要求使用的認證協議並正確配置使用者名稱和密碼等認證資訊。

---魔術字，用來檢測鏈路環路和其它異常情況；魔術字為隨機產生的一個數字，隨機機制需要保證兩端產生相同魔術字的可能性幾乎為0。

---質量協議，用來做QOS，設定資料轉發的優先順序。

---MP多鏈路引數，用於做多根鏈路的捆綁。

---報頭/報文壓縮，是否需要做報文、報頭壓縮。

2、Configure-Ack配置響應報文：收到對端發來的Configure-Request報文，如果引數取值完全接受，則以此報文響應。

3、Configure-Nak配置不響應報文：收到對端發來的Configure-Request報文，如果引數取值不被本端認可，則傳送此報文並且攜帶本端可接受的配置引數。

4、Configure-Reject配置拒絕報文：收到對端發來的Configure-Request報文，如果本端不能識別對端傳送的Configure-Request中的某些引數，則傳送此報文並且攜帶那些本端不能認別的配置引數。

PPP認證模式一：PAP認證

PAP認證協議被稱為密碼認證/兩次握手認證協議，當LCP協商完成後，認證方要求被認證方使用PAP進行認證；被認證方將配置的使用者名稱和密碼資訊使用Authenticate-Request報文以明文方式傳送給認證方；認證方收到被認證方傳送的使用者名稱和密碼資訊之後，根據本地配置的使用者名稱和密碼資料庫檢查使用者名稱和密碼資訊是否匹配，如果匹配，則返回Authenticate-Ack報文，表示認證成功。否則返回Authenticate-Nak報文，認證失敗；認證過程由被認證方主動發起。

PPP認證模式二：CHAP認證

CHAP認證被稱為挑戰握手認證協議/三次握手認證協議；為了匹配請求報文和迴應報文，報文中含有Identifier欄位，一次認證過程所使用的報文均使用相同的Identifier資訊（報文ID）。

當LCP協商完成後，認證方會傳送一個Challenge報文給被認證方，Challenge報文中含有Identifier資訊（報文ID）和一個隨機產生的Challenge字串（可防止重放攻擊），此Identifier即為後續報文所使用的Identifier。思科裝置中，challenge報文中使用者名稱是一定新增的，如果介面配置了使用者名稱就傳送，沒有配置就使用主機名傳送；當被認證方收到此Challenge報文之後，進行一次加密運算，運算公式為MD5{ Identifier＋密碼＋Challenge }，意思是將Identifier、密碼和Challenge三部分連成一個字串，然後對此字串做MD5運算，得到一個16位元組長的摘要資訊，然後將此摘要資訊和埠上配置的CHAP使用者名稱一起封裝在Response報文中發回認證方。

認證方接收到被認證方傳送的Response報文之後，按照其中的使用者名稱在本地查詢相應的密碼資訊，得到密碼資訊之後，進行一次加密運算，運算方式和被認證方的加密運算方式相同，然後將加密運算得到的摘要資訊和Response報文中封裝的摘要資訊做比較，相同則認證成功，不相同則認證失敗；使用CHAP認證方式時，被認證方的密碼是被加密後才進行傳輸的，這樣就極大的提高了安全性。

思科裝置上CHAP認證規則：

1、 如果被認證方收到的challenge報文中一定包含使用者名稱，被認證方必須出示介面所配置的使用者名稱和密碼，被認證方會根據使用者名稱在本地AAA認證資料庫裡面找有沒有對應的使用者名稱、密碼條目；AAA認證資料庫裡密碼出示優先順序高於被認證方介面的配置密碼，會使用AAA認證資料庫裡使用者名稱和密碼進行認證。

NCP：網路控制協議，用於對兩端裝置IP地址資訊進行確認（以IPV4CP為例）。

1. 每一端都要傳送Configure-Request報文，在此報文中包含本地配置的IP地址；

2. 每一端接收到此Configure-Request報文之後，檢查其中的IP地址，如果IP地址是一個合法的單播IP地址，而且和本地配置的IP地址不同（沒有IP衝突），則認為對端可以使用該地址，迴應一個Configure-Ack報文。

1、RTA向RTB傳送一個Configure-Request報文，此報文中會包含一個IP地址0.0.0.0，表示向對端請求IP地址；

2、RTB收到上述Configure-Request報文後，認為其中包含的地址（0.0.0.0）不合法，使用Configure-Nak迴應一個新的IP地址10.1.1.1；

3、RTA收到此Configure-Nak報文之後，更新本地IP地址，並重新傳送一個Configure-Request報文，包含新的IP地址10.1.1.1；

4、RTB收到Configure-Request報文後，認為其中包含的IP地址為合法地址，迴應一個Configure-Ack報文；RTB也要向RTA傳送Configure-Request報文請求使用地址10.1.1.2，RTA認為此地址合法，迴應Configure-Ack報文。