PPP協(xié)議是網(wǎng)絡中最為基礎的協(xié)議之一。PPP協(xié)議詳解就是我們本篇文章的主要內(nèi)容。那么首先還是簡單認識一下PPP協(xié)議的基本概念吧。PPP協(xié)議(Point-to-Point Protocol)是一種數(shù)據(jù)鏈路層協(xié)議，它是為在同等單元之間傳輸數(shù)據(jù)包這樣的簡單鏈路而設計的。這種鏈路提供全雙工操作，并按照順序傳遞數(shù)據(jù)包。PPP為基于各種主機、網(wǎng)橋和路由器的簡單連接提供一種共通的解決方案。

PPP協(xié)議包括以下三個部分：

1． 數(shù)據(jù)幀封裝方法。

2． 鏈路控制協(xié)議LCP（Link Control Protocol）:它用于對封裝格式選項的自動協(xié)商，建立和終止連接，探測鏈路錯誤和配置錯誤。

3． 針對不同網(wǎng)絡層協(xié)議的一族網(wǎng)絡控制協(xié)議NCP(Network Control Protocol): PPP協(xié)議規(guī)定了針對每一種網(wǎng)絡層協(xié)議都有相應的網(wǎng)絡控制協(xié)議，并用它們來管理各個協(xié)議不同的需求。

PPP協(xié)議詳解

1． PPP數(shù)據(jù)幀封裝

PPP協(xié)議為串行鏈路上傳輸?shù)臄?shù)據(jù)報定義了一種封裝方法，它基于高層數(shù)據(jù)鏈路控制（HDLC）標準。PPP數(shù)據(jù)幀的格式如圖1所示。

PPP幀以標志字符01111110開始和結束，地址字段長度為1字節(jié)，內(nèi)容為標準廣播地址11111111，控制字段為00000011。協(xié)議字段長度為2個字節(jié)，其值代表其后的數(shù)據(jù)字段所屬的網(wǎng)絡層協(xié)議，如：0x0021代表IP協(xié)議，0xC021代表LCP數(shù)據(jù)，0x8021代表NCP數(shù)據(jù)等。數(shù)據(jù)字段包含協(xié)議字段中指定的協(xié)議的數(shù)據(jù)報，長度為0～1500字節(jié)。CRC字段為整個幀的循環(huán)冗余校驗碼，用來檢測傳輸中可能出現(xiàn)的數(shù)據(jù)錯誤。

即使使用所有的幀頭字段，PPP協(xié)議幀也只需要8個字節(jié)就可以形成封裝。如果在低速鏈路上或者帶寬需要付費的情況下，PPP協(xié)議允許只使用最基本的字段，將幀頭的開銷壓縮到2或4個字節(jié)的長度，這就是所謂的PPP幀頭壓縮。

2． PPP回話的四個階段

既然要對PPP協(xié)議詳解，那么肯定需要對PPP協(xié)議的四個階段進行了解了。一次完整的PPP回話過程包括四個階段: 鏈路建立階段、確定鏈路質量階段、網(wǎng)絡層控制協(xié)議階段和鏈路終止階段（如圖2所示）。

(1) 鏈路建立階段：PPP通信雙方用鏈路控制協(xié)議交換配置信息，一旦配置信息交換成功，鏈路即宣告建立。配置信息通常都使用默認值，只有不依賴于網(wǎng)絡控制協(xié)議的配置選項才在此時由鏈路控制協(xié)議配置。值得注意的是，在鏈路建立的過程中，任何非鏈路控制協(xié)議的包都會被沒有任何通告地丟棄。

(2) 鏈路質量確定階段：這個階段在某些文獻中也稱為鏈路認證階段。鏈路控制協(xié)議負責測試鏈路的質量是否能承載網(wǎng)絡層的協(xié)議。在這個階段中，鏈路質量測試是PPP協(xié)議提供的一個可選項，也可不執(zhí)行。同時，如果用戶選擇了驗證協(xié)議，驗證的過程將在這個階段完成。PPP支持兩種驗證協(xié)議：密碼驗證協(xié)議（PAP）和握手鑒權協(xié)議(CHAP)。

(3) 網(wǎng)絡層控制協(xié)議階段：PPP會話雙方完成上述兩個階段的操作后，開始使用相應的網(wǎng)絡層控制協(xié)議配置網(wǎng)絡層的協(xié)議，如：IP、IPX等。

(4) 鏈路終止階段：鏈路控制協(xié)議用交換鏈路終止包的方法終止鏈路。引起鏈路終止的原因很多：載波丟失、認證失敗、鏈路質量失敗、空閑周期定時器期滿或管理員關閉鏈路等。

3． PPP協(xié)議中的驗證機制

驗證過程在PPP協(xié)議中為可選項。在連接建立后進行連接者身份驗證的目的是為了防止有人在未經(jīng)授權的情況下成功連接，從而導致泄密。PPP協(xié)議支持兩種驗證協(xié)議：

(1) 口令驗證協(xié)議(PAP): 口令驗證協(xié)議的原理是由發(fā)起連接的一端反復向認證端發(fā)送用戶名/口令對，直到認證端響應以驗證確認信息或者拒絕信息。

(2) 握手鑒權協(xié)議（CHAP）：CHAP用三次握手的方法周期性地檢驗對端的節(jié)點。其原理是：認證端向對端發(fā)送“挑戰(zhàn)”信息，對端接到“挑戰(zhàn)”信息后用指定的算法計算出應答信息然后發(fā)送給認證端，認證端比較應答信息是否正確從而判斷驗證的過程是否成功。如果使用CHAP協(xié)議，認證端在連接的過程中每隔一段時間就會發(fā)出一個新的“挑戰(zhàn)”信息，以確認對端連接是否經(jīng)過授權。

這兩種驗證機制共同的特點就是簡單，比較適合于在低速率鏈路中應用。但簡單的協(xié)議通常都有其他方面的不足，最突出的便是安全性較差。一方面，口令驗證協(xié)議的用戶名/口令以明文傳送，很容易被竊取；另一方面，如果一次驗證沒有通過，PAP并不能阻止對端不斷地發(fā)送驗證信息，因此容易遭到強制攻擊。

挑戰(zhàn)握手協(xié)議的優(yōu)點在于密鑰不在網(wǎng)絡中傳送，不會被竊聽。由于使用三次握手的方法，發(fā)起連接的一方如果沒有收到“挑戰(zhàn)信息”就不能進行驗證，因此在某種程度上挑戰(zhàn)握手協(xié)議不容易被強制攻擊。但是，CHAP中的密鑰必須以明文形式存在，不允許被加密，安全性無法得到保障。密鑰的保管和分發(fā)也是CHAP的一個難點，在大型網(wǎng)絡中通常需要專門的服務器來管理密鑰。

PPP的配置

PPP協(xié)議詳解中當然也包括了配置內(nèi)容，PPP協(xié)議在很多領域中都有廣泛的應用，典型的是遠程Internet的連接，其中使用較多的是路由器與路由器互聯(lián)。

兩個路由器之間有兩條鏈路，分別運行PPP協(xié)議，其中一條鏈路使用CHAP認證，另一條采用PAP認證。

1．路由器PPP封裝配置

在端口模式下：

A(config-if)# encapsulation ppp //在路由器A的S0、S1端口分別啟動PPP協(xié)議。

B(config-if)# encapsulation ppp //在路由器B的S0、S1端口分別啟動PPP協(xié)議。

2．配置PPP認證使用的用戶名和密碼

A(config)#username B password cisco //為路由器B設置一個用戶名和口令。

B(config)#username A password cisco //為路由器A設置一個用戶名和口令。

3． 配置PAP認證

在路由器A、B的S1端口上：

A(config-if)#ppp authentication pap

B(config-if)#ppp authentication pap

需要說明的是，在Cisco IOS 11.1或更高的版本中，如果路由器發(fā)送（或響應）PAP消息（或請求），則必須在指定接口上使用PAP協(xié)議。

單向認證：比如A向B發(fā)出認證請求，那么只在A上配置即可，B不用額外配置。

A(config-if)#ppp pap sent-username B password cisco

雙向認證：A和B雙方要互相認證，那么A、B都要配置。

A(config-if)#ppp pap sent-username B password cisco

B(config-if)#ppp pap sent-username A password cisco

4． 配置CHAP認證

在路由器A、B的S0端口上：

A(config-if)#ppp authentication chap

B(config-if)#ppp authentication chap