1. 程式人生 > >PPP驗證(PAP和CHAP)

PPP驗證(PAP和CHAP)

pap chap

ppp協議

PPP協議是一種點到點的鏈路協議,主要運用於在全雙工的鏈路上進行點到點的數據傳輸

特點:

-支持點到點和點到多點

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

-可同時支持多種網絡層協議

-支持驗證

-支持地址自動協商,能夠遠程分配IP地址


PPP組成:

LCP:鏈路控制協議,負責物理層和二層的協商(用來建立、拆除和監控PPP數據鏈路)

NCP:網絡控制協議,負責和三層協商(對於不同的網絡層協議進行連接建立和參數協商)

技術分享

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中的某些參數,則發送此報文並且攜帶那些本端不能認別的配置參數。

技術分享


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)

技術分享

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

被認證方將配置的用戶名和密碼信息使用Authenticate-Request報文以明文方式發送給認證方。認證方收到被認證方發送的用戶名和密碼信息之後,根據本地配置的用戶名和密碼數據庫檢查用戶名和密碼信息是否匹配,如果匹配,則返回Authenticate-Ack報文,表示認證成功。否則,返回Authenticate-Nak報文,表示認證失敗。

技術分享

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

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

2. 被認證方收到此Challenge報文之後,也皮一下,進行一次加密運算,也是MD5運算,得到一個16字節長的摘要信息,然後將此摘要信息和端口上配置的CHAP用戶名一起封裝在Response報文中發到認證方那裏去。

3. 認證方接收到被認證方發送的Response報文之後,按照Response的用戶名在認證方的本地查找相應的密碼信息,得到密碼信息之後,進行一次加密運算,運算方式和被認證方的加密運算方式相同,然後將加密運算得到的摘要信息和Response報文中封裝的摘要信息做比較,相同則認證成功,不相同則認證失敗。


本文出自 “costin” 博客,請務必保留此出處http://brighttime.blog.51cto.com/12837169/1953874

PPP驗證(PAP和CHAP)