1  PPP概述

　　點到點協議（Point to Point PRotocol，PPP）是IETF（Internet Engineering Task Force，因特網工程任務組）推出的點到點類型線路的數據鏈路層協議。它解決了SLip中的問題，并成為正式的因特網標準。

　　PPP協議在RFC 1661、RFC 1662和RFC 1663中進行了描述。

　　PPP支持在各種物理類型的點到點串行線路上傳輸上層協議報文。PPP有很多豐富的可選特性，如支持多協議、提供可選的身份認證服務、可以以各種方式壓縮數據、支持動態地址協商、支持多鏈路捆綁等等。這些豐富的選項增強了PPP的功能。同時，不論是異步撥號線路還是路由器之間的同步鏈路均可使用。因此，應用十分廣泛。

　　本文我們主要介紹PPP的身份認證功能。

　　2  CHAP原理

　　PPP提供了兩種可選的身份認證方法：口令驗證協議PAP（PassWord Authentication Protocol，PAP）和質詢握手協議（Challenge Handshake Authentication Protocol，CHAP）。假如雙方協商達成一致，也可以不使用任何身份認證方法。

　　CHAP認證比PAP認證更安全，因為CHAP不在線路上發送明文密碼，而是發送經過摘要算法加工過的隨機序列，也被稱為"挑戰字符串".如圖1所示。同時，身份認證可以隨時進行，包括在雙方正常通信過程中。因此，非法用戶就算截獲并成功破解了一次密碼，此密碼也將在一段時間內失效。

　　圖1   CHAP

　　CHAP對端系統要求很高，因為需要多次進行身份質詢、響應。這需要耗費較多的CPU資源，因此只用在對安全要求很高的場合。

　　3  CHAP配置

　　3.1  PPP基本配置

　　對于同步串行接口，默認的封裝格式是HDLC（Cisco私有實現）。可以使用命令encapsulation ppp將封裝格式改為PPP.如圖2所示。

　　圖2   PPP串行封裝

　　當通信雙方的某一方封裝格式為HDLC，而另一方為PPP時，雙方關于封裝協議的協商將失敗。此時，此鏈路處于協議性關閉（protocol down）狀態，通信無法進行。如圖3所示。

　　圖3   兩端路由器串行接口封裝格式不一致

　　這時，在路由器RouterA與路由器RouterB的鏈路沒有成功建立之前，路由器RouterA及RouterB的路由表將為空。

　　3.2  CHAP配置

　　3.2.1  CHAP認證過程

　　同PAP一樣，CHAP認證可以在一方進行，即由一方認證另一方身份，也可以進行雙向身份認證。這時，要求被認證的雙方都要通過對方的認證程序，否則，無法建立二者之間的鏈路。我們以單方認證為例分析CHAP配置過程及診斷方法。

　　如圖4所示。當雙方都封裝了PPP協議且要求進行CHAP身份認證，同時它們之間的鏈路在物理層已激活后，認證服務器會不停地發送身份認證要求直到身份認證成功。和PAP不同的是，這時認證服務器發送的是"挑戰"字符串。

　　圖4   CHAP驗證

　　在圖4中，當認證客戶端（被認證一端）路由器RouterB發送了對"挑戰"字符串的回應數據包后，認證服務器會按照摘要算法（md5）驗證對方的身份。假如正確，則身份認證成功，通信雙方的鏈路最終成功建立。

　　假如被認證一端路由器RouterB發送了錯誤的"挑戰"回應數據包，認證服務器將繼續不斷地發送身份認證要求直到收到正確的回應數據包為止。

　　3.2.2  CHAP認證服務器的配置

　　CHAP認證服務器的配置分為兩個步驟：建立本地口令數據庫、要求進行CHAP認證。

　　建立本地口令數據庫

　　通過全局模式下的命令username username password password來為本地口令數據庫添加記錄。這里請注重，此處的username應該是對端路由器的名稱，即routerb.如下所示：

　　RouterA（config）#username routerb password samepass

　　要求進行CHAP認證

　　這需要在相應接口配置模式下使用命令ppp authentication chap來完成。如下所示：

　　RouterA（config）#interface serial 0/0

　　RouterA（config-if）#ppp authentication chap

　　3.2.3  CHAP認證客戶端的配置

　　CHAP認證客戶端的配置只需要一個步驟（命令），即建立本地口令數據庫。請注重，此處的username應該是對端路由器的名稱，即routera，而口令應該和CHAP認證服務器口令數據庫中的口令相同。如下所示。

　　RouterB（config-if）#username routera password samepass

　　3.2.4  CHAP的診斷

　　對于CHAP身份認證中出現的問題也可以利用debug ppp authentication命令進行診斷。如圖5所示，它表明認證客戶端發送的"挑戰"回應數據包沒有通過認證服務器的認證。

　　圖5   命令debug ppp authentication 的輸出

　　圖6表明經過若干次認證要求后，認證服務器最終收到了認證客戶端發送過來的正確的"挑戰"回應數據包。此時，雙方的鏈路將成功建立。

　　圖6   命令debug ppp authentication 的輸出

　　注重：

　　1、CHAP認證過程中，口令是大小寫敏感的。

　　2、身份認證也可以雙向進行，即互相認證。配置方法同單向認證類似，只不過需要將通信雙方同時配置成為認證服務器和認證客戶端。

　　3、口令數據庫也可以存儲在路由器以外的AAA或TACACS+服務器上。限于篇幅，此處不再贅述。

　　通信認證雙方選擇的認證方法可能不一樣，如一方選擇PAP，另一方選擇CHAP，這時雙方的認證協商將失敗。為了避免身份認證協議過程中出現這樣的失敗，可以配置路由器使用兩種認證方法。當第一種認證協商失敗后，可以選擇嘗試用另一種身份認證方法。如下的命令配置路由器首先采用PAP身份認證方法。假如失敗，再采用CHAP身份認證方法。

　　RouterA（config-if）#ppp authentication pap chap

　　如下的命令則相反，首先使用CHAP認證，協商失敗后采用PAP認證。

　　RouterA（config-if）#ppp authentication chap pap