【文章內(nèi)容簡(jiǎn)介】 般在兩端設(shè)備使用PAP協(xié)議之前，均會(huì)設(shè)備上進(jìn)行一些相應(yīng)的配置，對(duì)于MA5200IP接入設(shè)備，它默認(rèn)就作為驗(yàn)證方，但可通過使用命令PAP Authentication PAP/CHAP來更改認(rèn)證方式，而對(duì)于被驗(yàn)證方而言只需設(shè)置用戶名和密碼即可。PAP認(rèn)證是兩次握手，在鏈路建立階段，依據(jù)設(shè)備上的配置情況，如果是使用PAP認(rèn)證，則驗(yàn)證方在發(fā)送ConfigRequest報(bào)文時(shí)會(huì)攜帶認(rèn)證配置參數(shù)選項(xiàng)，而對(duì)于被驗(yàn)證方而言則是不需要，它只需要收到該配置請(qǐng)求報(bào)文后根據(jù)自身的情況給對(duì)端返回相應(yīng)的報(bào)文。如果點(diǎn)對(duì)點(diǎn)的兩端設(shè)備采用的是PAP雙向認(rèn)證時(shí)，也即是它同時(shí)也作為驗(yàn)證方，則此時(shí)需要在配置請(qǐng)求報(bào)文中攜帶認(rèn)證配置參數(shù)選項(xiàng)。因此，我們可以總結(jié)一下，如果對(duì)于點(diǎn)對(duì)點(diǎn)的兩個(gè)設(shè)備在PPP鏈路建立的過程中使用的認(rèn)證方式為PAP的話，那么驗(yàn)證方在其ConfigRequest報(bào)文中必須含有認(rèn)證配置參數(shù)選項(xiàng)，且該認(rèn)證配置參數(shù)選項(xiàng)的數(shù)據(jù)域?yàn)?xC023 。當(dāng)通信設(shè)備的兩端在收到對(duì)方返回的ConfigAck報(bào)文時(shí)，就從各自的鏈路建立階段進(jìn)入到認(rèn)證階段，那么作為被驗(yàn)證方此時(shí)需要向驗(yàn)證方發(fā)送PAP認(rèn)證的請(qǐng)求報(bào)文，該請(qǐng)求報(bào)文攜帶了用戶名和密碼，當(dāng)驗(yàn)證方收到該認(rèn)證請(qǐng)求報(bào)文后，則會(huì)根據(jù)報(bào)文中的實(shí)際內(nèi)容查找本地的數(shù)據(jù)庫，如果該數(shù)據(jù)庫中有與用戶名和密碼一致的選項(xiàng)時(shí)，則回向?qū)Ψ椒祷匾粋€(gè)認(rèn)證請(qǐng)求響應(yīng)，告訴對(duì)方認(rèn)證已通過。反之，如果用戶名與密碼不符，則向?qū)Ψ椒祷仳?yàn)證不通過的響應(yīng)報(bào)文。如果雙方都配置為驗(yàn)證方，則需要雙方的兩個(gè)單向驗(yàn)證過程都完成后，方可進(jìn)入到網(wǎng)絡(luò)層協(xié)議階段，否則在一定次的認(rèn)證失敗后，則會(huì)從當(dāng)前狀態(tài)返回鏈路不可用狀態(tài)。例如：當(dāng)路由器A（被驗(yàn)證方）收到了路由器B 的ConfigAck報(bào)文后，因?yàn)槭鞘褂肞AP認(rèn)證，所以作為被驗(yàn)證方的路由器A應(yīng)主動(dòng)向驗(yàn)證方（路由器B）發(fā)送認(rèn)證請(qǐng)求報(bào)文（PAP Authenticate），用戶名和密碼均為163，報(bào)文的內(nèi)容如下：7E FF 03 C0 23 01 01 00 0C 03 31 36 33 03 31 36 33 7E下劃線的前四個(gè)字節(jié)是用戶名，后四個(gè)字節(jié)是密碼。當(dāng)路由器B收到了該報(bào)文后，會(huì)向路由器A回應(yīng)一個(gè)PAP Authenticate Ack報(bào)文，報(bào)文內(nèi)容如下：7E FF 03 80 21 02 01 00 05 00 7E此時(shí)所回應(yīng)的報(bào)文中，并未攜帶任何數(shù)據(jù)，如果是認(rèn)證不通過，則會(huì)在返回的報(bào)文中指是因何原因無法認(rèn)證通過，可能是無此用戶名或密碼不匹配。 與PAP認(rèn)證比起來，CHAP認(rèn)證更具有安全性，從前面認(rèn)證過程的數(shù)據(jù)包交換過程中不難發(fā)現(xiàn)，采用PAP認(rèn)證時(shí)，被驗(yàn)證是采用明文的方式直接將用戶名和密碼發(fā)送給驗(yàn)證方的，而對(duì)于PAP認(rèn)證則不一樣。CHAP為三次握手協(xié)議，它只在網(wǎng)絡(luò)上傳送用戶名而不傳送口令，因此安全性比PAP高。在驗(yàn)證一開始，不像PAP一樣是由被驗(yàn)證方發(fā)送認(rèn)證請(qǐng)求報(bào)文了，而是由驗(yàn)證方向被驗(yàn)證方發(fā)送一段隨機(jī)的報(bào)文，并加上自己的主機(jī)名，我們通稱這個(gè)過程叫做挑戰(zhàn)。當(dāng)被驗(yàn)證方收到驗(yàn)證方的驗(yàn)證請(qǐng)求，從中提取出驗(yàn)證方所發(fā)送過來的主機(jī)名，然后根據(jù)該主機(jī)名在被驗(yàn)證方設(shè)備的后臺(tái)數(shù)據(jù)庫中去查找相同的用戶名的記錄，當(dāng)查找到后就使用該用戶名所對(duì)應(yīng)的密鑰，然后根據(jù)這個(gè)密鑰、報(bào)文ID和驗(yàn)證方發(fā)送的隨機(jī)報(bào)文用Md5加密算法生成應(yīng)答，隨后將應(yīng)答和自己的主機(jī)名送回，同樣驗(yàn)證方收到被驗(yàn)證方發(fā)送回應(yīng)后，提取被驗(yàn)證方的用戶名，然后去查找本地的數(shù)據(jù)庫，當(dāng)找到與被驗(yàn)證方一致用戶名后，根據(jù)該用戶名所對(duì)應(yīng)的密鑰、保留報(bào)文ID和隨機(jī)報(bào)文用Md5加密算法生成結(jié)果，和剛剛被驗(yàn)證方所返回的應(yīng)答進(jìn)行比較，相同則返回Ack，否則返回Nak。例11： 如圖42所示，當(dāng)路由器A（被驗(yàn)證方）收到了路由器B 的Challenge報(bào)文后，報(bào)文內(nèi)容如下：7E FF 03 C2 23 01 01 00 1C 10 FF 41 CF 22 AA 8E F1 B9 99 9A 79 A7 56 78 C4 A7 4d 41 35 32 30 30 417E下劃線的前16個(gè)字節(jié)是驗(yàn)證方隨機(jī)產(chǎn)生的一段報(bào)文，后7個(gè)字節(jié)是驗(yàn)證方的主機(jī)名（MA5200A），而且單個(gè)字節(jié)10表示隨機(jī)報(bào)文的長(zhǎng)度。而此時(shí)路由器A會(huì)根據(jù)用戶名所對(duì)應(yīng)的密鑰使用報(bào)文的ID和該報(bào)文的內(nèi)容生成一個(gè)回應(yīng)報(bào)文，報(bào)文內(nèi)容如下：7E FF 03 C2 23 02 01 00 1F 10 18 86 22 FF CE 81 D0 68 FF 80 85 00 A7 E3 85 35 70 70 6B 69 73 73 40 68 75 61 7E我們將這個(gè)回應(yīng)報(bào)文與驗(yàn)證方發(fā)送的挑戰(zhàn)報(bào)文進(jìn)行比較，報(bào)文的代碼域已由原01改為02，總報(bào)文的長(zhǎng)度有變化，主要后而一個(gè)下劃線的內(nèi)容是被驗(yàn)證方的主機(jī)名（ppkiss@hua），而且此時(shí)回應(yīng)的16個(gè)字節(jié)的報(bào)文已經(jīng)是經(jīng)過MD5算法加密過的。當(dāng)驗(yàn)證方收到了這個(gè)回應(yīng)報(bào)文后，會(huì)根據(jù)報(bào)文中被驗(yàn)證方的主機(jī)名（ppkiss@hua）在本地的數(shù)據(jù)庫中去查找密鑰，然后再對(duì)原發(fā)先發(fā)送的那段挑戰(zhàn)報(bào)文進(jìn)行MD5的算法加密，如果所得的結(jié)果與對(duì)方剛發(fā)過來的16個(gè)字節(jié)的加密值一樣的話，則就會(huì)發(fā)送一個(gè)報(bào)文通知被驗(yàn)證方，你的認(rèn)證已經(jīng)通過，我們可以進(jìn)入到下一個(gè)階段了。在實(shí)際應(yīng)用當(dāng)中，我們很多都是使用PC機(jī)來進(jìn)行撥號(hào)這個(gè)過程，實(shí)際中當(dāng)驗(yàn)證方發(fā)送挑戰(zhàn)后，PC機(jī)只接收而并不去查本地?cái)?shù)據(jù)庫，而直接使用在撥號(hào)對(duì)話框中所輸入的密碼和報(bào)文的ID及報(bào)報(bào)文的內(nèi)容進(jìn)行MD5算法加密（這個(gè)在PC機(jī)采用PPPOE軟件撥入到MA5200時(shí)就是這樣的）。下面來看一下驗(yàn)證通過時(shí)，驗(yàn)證方給被驗(yàn)證方所發(fā)送的一段報(bào)文內(nèi)容：7E FF 03 C2 23 03 01 00 17 57 65 6C 63 6F 6D 65 20 74 6F20 4D 41 35 32 30 30 41 2E 7E此時(shí)所回應(yīng)的報(bào)文的代碼域?yàn)?3，且報(bào)文的實(shí)際內(nèi)容是，Wel to MA5200A。 NCP協(xié)議的數(shù)據(jù)報(bào)文是在網(wǎng)絡(luò)層協(xié)議階段被交換的，在這個(gè)階段所需的一些配置參數(shù)選項(xiàng)協(xié)商完后，就可以進(jìn)行網(wǎng)絡(luò)層的通信，也即是在點(diǎn)對(duì)點(diǎn)的鏈路上可以開始傳送網(wǎng)絡(luò)層的數(shù)據(jù)報(bào)文了。NCP協(xié)議主要包括IPCP、IPXCP等，但我們?cè)趯?shí)際當(dāng)中最常遇見的也只有IPCP協(xié)議了，如果對(duì)IPXCP或其它的一些網(wǎng)絡(luò)控制協(xié)議有興趣，則可參見RFC1552。 IPCP控制協(xié)議主要是負(fù)責(zé)完成IP網(wǎng)絡(luò)層協(xié)議通信所需配置參數(shù)的選項(xiàng)協(xié)商的。IPCP在運(yùn)行的過程當(dāng)中，主要是完成點(diǎn)對(duì)點(diǎn)通信設(shè)備的兩端動(dòng)態(tài)的協(xié)商IP地址。我們依據(jù)兩端設(shè)備的配置選項(xiàng)可將IPCP的協(xié)商過程分為靜態(tài)和動(dòng)態(tài)。何為靜態(tài)，何為動(dòng)態(tài)，這是一個(gè)相對(duì)的概念，可能不太準(zhǔn)確，只作為參考使用。我們?cè)谙旅鏁?huì)具體描述這兩個(gè)過程。IPCP的數(shù)據(jù)的文同LCP的數(shù)據(jù)報(bào)文非常類似，只不過NCP是在網(wǎng)絡(luò)層協(xié)議階段協(xié)商配置參數(shù)選項(xiàng)，而LCP協(xié)議則是在鏈路建立階段協(xié)商配置參數(shù)選項(xiàng)的。除此之外是兩者在所使用報(bào)文上的相似之處，我們知道LCP共包括十幾種報(bào)文，而IPCP也包括多種報(bào)文，但它的報(bào)文類型只是LCP數(shù)據(jù)報(bào)文的一個(gè)子集（只有LCP代碼域從1到7這七種報(bào)文），而且實(shí)際的數(shù)據(jù)報(bào)文交換過程中也僅涉及以下幾種：ConfigRequest、ConfigAck、ConfigNak和ConfigReject（代碼域從1到4，而鏈路終止報(bào)文一般而言是不在網(wǎng)絡(luò)協(xié)議階段使用的，而且也是不需要的）。以下就具體介紹一下IPCP控制協(xié)議的靜態(tài)和動(dòng)態(tài)的兩個(gè)過程，實(shí)際上兩者的區(qū)分是在于互連設(shè)備IP地址的獲取過程。靜態(tài)協(xié)商，也即是不協(xié)商。點(diǎn)對(duì)點(diǎn)的通信設(shè)備兩端在PPP協(xié)商之前已配置好了IP地址，所以就無須在網(wǎng)絡(luò)層協(xié)議階段協(xié)商IP地址，而雙方唯一要做的就是告訴對(duì)方自身的IP地址。在IPCP控制協(xié)議完成整個(gè)配置的過程時(shí)，最理想的情況將會(huì)看到如圖所示的四種報(bào)文，而無其它報(bào)文再被發(fā)送。如果當(dāng)配置請(qǐng)求中所攜帶的網(wǎng)絡(luò)層配置參數(shù)選項(xiàng)類似于LCP配置參數(shù)選項(xiàng)協(xié)商過程一樣，可能會(huì)有對(duì)方不識(shí)別的配置參數(shù)選項(xiàng)或不被對(duì)方所認(rèn)可的配置參數(shù)選項(xiàng)的內(nèi)容。這樣在這個(gè)階段的協(xié)商過程中可能還會(huì)看到其它的一些報(bào)文。 在靜態(tài)協(xié)商時(shí)，如果IPCP的ConfigRequest報(bào)文中只含有地址配置參數(shù)選項(xiàng)時(shí)（實(shí)際中可能還會(huì)附帶其它配置參數(shù)選項(xiàng)，這些配置參數(shù)選項(xiàng)的協(xié)商與LCP階段的一樣，而我這里只提到了IP地址配置參數(shù)選項(xiàng)），無論是發(fā)送方還是接收方都同時(shí)發(fā)送ConfigRequest報(bào)文，其中配置選項(xiàng)中只含有各自的IP地址。當(dāng)對(duì)端收到該報(bào)文后，會(huì)發(fā)送一個(gè)ConfigAck報(bào)文，這個(gè)目的是告訴對(duì)端我已經(jīng)知道了你的IP地址，對(duì)路由器而言會(huì)增加一條到對(duì)端接口的主機(jī)路由。 剛進(jìn)入網(wǎng)絡(luò)層協(xié)議階段時(shí)，IPCP的狀態(tài)機(jī)是initial的，但當(dāng)完成了上述的整個(gè)過程后，IPCP的狀態(tài)機(jī)改變?yōu)镺pened，雙方也就可以開始網(wǎng)絡(luò)層數(shù)據(jù)網(wǎng)的傳送了。當(dāng)一端接收到ConfigRequest報(bào)文后，它從報(bào)文的配置參數(shù)選項(xiàng)中可獲知對(duì)端的IP地址，但并不與本端的IP地址進(jìn)行比較。我們也知道，一般而言點(diǎn)對(duì)點(diǎn)的兩端應(yīng)該是在一個(gè)網(wǎng)段。但如果雙方的地址不在一個(gè)網(wǎng)段，IPCP協(xié)議中并未規(guī)定，此時(shí)不給對(duì)方回應(yīng)ConfigAck報(bào)文，而是無條件的回送。因此說點(diǎn)對(duì)點(diǎn)通信的兩端如果是手動(dòng)設(shè)置每一端的IP地址時(shí)，無須雙方地址在同一網(wǎng)段。例8：假設(shè)IPCP在網(wǎng)絡(luò)層協(xié)議階段開始協(xié)商配置參數(shù)選項(xiàng)（這里只舉協(xié)商IP地址的配置參數(shù)選項(xiàng)地的過程），，發(fā)送方發(fā)送給ConfigRequest報(bào)文內(nèi)容如下：7E FF 03 80 21 01 01 00 0A 03 06 C0 A8 00 01 7E在這個(gè)例子中我們能看見明顯的改變之處再于PPP協(xié)議域字段由原先的0xC021改變?yōu)?x8021，下劃線的部分表示本端的IP地址。當(dāng)對(duì)端正確接收到了該報(bào)文后，應(yīng)該回應(yīng)一個(gè)ConfigAck報(bào)文，報(bào)文內(nèi)容如下：7E FF 03 80 21 02 01 00 0A 03 06 C0 A8 00 01 7E同樣的接收方給發(fā)送方也發(fā)送一個(gè)ConfigRequest報(bào)文內(nèi)容如下，但此時(shí)報(bào)文中IP地址配置參數(shù)選項(xiàng)的值為本端的IP地址（）：7E FF 03 80 21 01 01 00 0A 03 06 C0 A8 00 02 7E發(fā)送方回應(yīng)一個(gè)ConfigAck報(bào)文給接收方，報(bào)文內(nèi)容如下：7E FF 03 80 21 02 01 00 0A 03 06 C0 A8 00 02 7E動(dòng)態(tài)協(xié)商，也即是一端配置為動(dòng)態(tài)獲取IP地址，另一端通過手動(dòng)方式配置IP地址，且允許給對(duì)端分配IP地址，這個(gè)過程實(shí)際上可與窄帶撥號(hào)上網(wǎng)的過程相一致，如果我們想用計(jì)算機(jī)上網(wǎng)，均會(huì)安裝一個(gè)撥號(hào)適配器，而且計(jì)算機(jī)中的撥號(hào)網(wǎng)絡(luò)適配器是采用動(dòng)態(tài)獲取IP地址的方式，也就是在IPCP的ConfigRequest報(bào)文中只攜帶IP地址的配置參數(shù)選項(xiàng)。 這個(gè)例子與一個(gè)例子相似如果是配置參數(shù)選項(xiàng)中含有其它配置參數(shù)選項(xiàng)，則可能會(huì)遇到其它的一些情況（如不識(shí)別配置參數(shù)選項(xiàng)的代碼域或不認(rèn)可配置參數(shù)選項(xiàng)的內(nèi)容，但對(duì)于這些情況的處理方法和LCP配置參數(shù)選項(xiàng)