立你斯學習記錄

https://blog.csdn.net/sky619351517/article/details/84797605

PPPoE協議交互過程

1、發現階段（PPPoED：PPPoE Discovery）
1.1 PADI（PPPoE Active Discovery Initiation）
1.2 PADO（PPPoE Active Discovery Offer）
1.3 PADR（PPPoE Active Discovery Request）
1.4 PADS（PPPoE Active Discovery Session-confirmation）
2、會話階段（PPPoES：PPPoE Session）
2.1 LCP協商階段（LCP：Link Control Protocol）
（1）LCP協議數據報文分類
（2）LCP協商過程
2.2 認證階段（PPP Authentication：PAP/CHAP）
2.2.1 PAP（Password Authentication Protocol，口令認證協議）認證
2.3 NCP協商階段（NCP：Network Control Protocol）
2.4 會話維持（Session Keep-alive）
2.5 會話結束（Session Termination）
3、抓包分析PPPoE連接過程
PPPoE（Point to Point Protocol over Ethernet，基於以太網的點對點協議）的工作流程包含發現（Discovery）和會話（Session）兩個階段，發現階段是無狀態的，目的是獲得 PPPoE 終端（在局端的ADSL設備上）的以太網 MAC 地址，並建立一個惟一的 PPPoE SESSION-ID。發現階段結束後，就進入標準的PPP會話階段。

1、發現階段（PPPoED：PPPoE Discovery）

1. Discovery stage
在這個階段主要有4個步驟,當所有步驟都完成後則 Host(Client) 與 Access Concentrator(Service) 可以知道彼此的 MAC address 以及獲得一個唯一的 SESSION_Id. Host 會先 broadcasting 一個 PAID 的封包來尋找 AC ,收到 PADO 封包的 AC　會利用unicast回傳一個 PADO,當 Host 接收到則會回傳　PADS　封包,而被選擇到AC 則會回傳　PADR,當這些步驟完成後則可以進入 ppp session 階段.

下面是簡單的流程圖



PPPoE 封包格式


Ethernet frame


PPPoE Playout

version:0x1 Type:0x1，Length欄寬為16 bits，其值代表為data payload的長度(單位：byte)

code所代表的意義


在Discovery Stage，Data payload 內容為TAGs；而在PPPoE Session Stage，Data payload內容則為PPP協定和其資料。在Discovery Stage，PPPoE payload可包含一個以上的標籤(TAGs)，標籤的格式為TLV(type-length-value)。


TAG_TYPE:

1.1 PADI（PPPoE Active Discovery Initiation）

主機廣播發起分組，分組的目的地址為以太網的廣播地址 0xffffffffffff，CODE（代碼）字段值為0×09（PADI Code），SESSION-ID（會話ID）字段值為0x0000。PADI分組必須至少包含一個服務名稱類型的標簽（Service Name Tag，字段值為0x0101），向接入集中器提出所要求提供的服務。

1.2 PADO（PPPoE Active Discovery Offer）

接入集中器收到在服務範圍內的PADI分組，發送PPPoE有效發現提供包分組，以響應請求。其中CODE字段值為0×07（PADO Code），SESSION-ID字段值仍為0x0000。PADO分組必須包含一個接入集中器名稱類型的標簽（Access Concentrator Name Tag，字段值為0x0102），以及一個或多個服務名稱類型標簽，表明可向主機提供的服務種類。PADO和PADI的Host-Uniq Tag值相同。

1.3 PADR（PPPoE Active Discovery Request）

主機在可能收到的多個PADO分組中選擇一個合適的PADO分組，然後向所選擇的接入集中器發送PPPoE有效發現請求分組。其中CODE字段為0x19（PADR Code），SESSION_ID字段值仍為0x0000。PADR分組必須包含一個服務名稱類型標簽，確定向接入集線器（或交換機）請求的服務種類。當主機在指定的時間內沒有接收到PADO，它應該重新發送它的PADI分組，並且加倍等待時間，這個過程會被重復期望的次數。

1.4 PADS（PPPoE Active Discovery Session-confirmation）

接入集中器收到PADR分組後準備開始PPP會話，它發送一個PPPoE有效發現會話確認PADS分組。其中CODE字段值為0×65（PADS Code），SESSION-ID字段值為接入集中器所產生的一個惟一的PPPoE會話標識號碼。PADS分組也必須包含一個接入集中器名稱類型的標簽以確認向主機提供的服務。當主機收到PADS 分組確認後，雙方就進入PPP會話階段。PADS和PADR的Host-Uniq Tag值相同。

圖1 PPPoE的協商流程
2、會話階段（PPPoES：PPPoE Session）

PPP會話的建立，需要兩端的設備都發送LCP數據包來配置和測試數據通信鏈路。
用戶主機與接入集中器根據在發現階段所協商的PPP會話連接參數進行PPP會話。一旦PPPoE會話開始，PPP數據就可以以任何其他的PPP封裝形式發送。所有的以太網幀都是單播的。PPPoE會話的SESSION-ID一定不能改變，並且必須是發現階段分配的值。

2.1 LCP協商階段（LCP：Link Control Protocol）

LCP的Request主機和AC都要給對方發送，LCP協商階段完成最大傳輸單元（MTU），是否進行認證和采用何種認證方式（Authentication Type）的協商。

（1）LCP協議數據報文分類

鏈路配置報文：用來建立和配置一條鏈路，主要包括Configure-Request、Configure-Ack、Configure-Nak和Configure-Reject報文
鏈路維護報文：用來管理和調試鏈路，主要包括Code-Reject、Protocol-Reject、Echo-Request、Echo-Reply和Discard-Request報文
鏈路終止報文：用來終止一條鏈路，主要包括Terminate-Request和Terminate-Reply報文

（2）LCP協商過程

LCP協商的過程如下：協商雙方互相發送一個LCP Config-Request報文，確認收到的Config-Request報文中的協商選項，根據這些選項的支持與接受情況，做出適當的回應。若兩端都回應了Config-ACK，則標誌LCP鏈路建立成功，否則會繼續發送Request報文，直到對端回應了ACK報文為止。

圖2 LCP協商的基本過程
說明：
（1）Config-ACK：若完全支持對端的LCP選項，則回應Config-ACK報文，報文中必須完全協帶對端Request報文中的選項。
（2）Config-NAK：若支持對端的協商選項，但不認可該項協商的內容，則回應Config-NAK報文，在Config-NAK的選項中填上自己期望的內容，如:對端MRU值為1500，而自己期望MRU值為1492，則在Config-NAK報文中埴上自己的期望值1492。
（3）Config-Reject：若不能支持對端的協商選項，則回應Config-Reject報文，報文中帶上不能支持的選項，如Windows撥號器會協商CBCP（被叫回呼），而ME60不支持CBCP功能，則回將此選項拒絕掉。

需要指出的是PPP協商是雙向的，也就是說雙方都會發出Configure-Request請求，並且有可能協商多次才能成功，最理想的就是一對Configure-Request&Configure-Ack就協商成功，下面是幾種常見的協商過程。

一次交互

兩次交互--Nak情況

兩次交互--Reject情況

多次交互

2.2 認證階段（PPP Authentication：PAP/CHAP）

會話雙方通過LCP協商好的認證方法進行認證，如果認證通過了，才可以進行下面的網絡層的協商。認證過程在鏈路協商結束後就進行。

2.2.1 PAP（Password Authentication Protocol，口令認證協議）認證

PAP為兩次握手協議，它通過用戶名及口令來對用戶進行驗證。PAP驗證過程如下：
當兩端鏈路可相互傳輸數據時，被驗證方發送本端的用戶名及口令到驗證方，驗證方根據本端的用戶表（或Radius服務器）查看是否有此用戶，口令是否正確。如正確則會給對端發送Authenticate-ACK報文，通告對端已被允許進入下一階段協商；否則發送NAK報文，通告對端驗證失敗。此時，並不會直接將鏈路關閉。只有當驗證不過次數達到一定值（缺省為10）時，才會關閉鏈路。

PAP的特點是在網絡上以明文的方式傳遞用戶名及口令，如在傳輸過程中被截獲，便有可能對網絡安全造成極大的威脅。因此，它適用於對網絡安全要求相對較低的環境。

PAP認證流程
##### 2.2.2 CHAP（Challenge Handshake Authentication Protocol，質詢握手認證協議）認證 CHAP為三次握手協議。只在網絡上傳輸用戶名，並不傳輸用戶口令，因此它的安全性要比PAP高。CHAP的驗證過程為： 首先由驗證方（Server）向被驗證方（Client）發送一些隨機產生的報文，並同時將本端的主機名附帶上一起發送給被驗證方。被驗證方接到對端對本端的驗證請求（Challenge）時，便根據此報文中驗證方的主機名和本端的用戶表查找用戶口令字，如找到用戶表中與驗證方主機名相同的用戶，便利用報文ID、此用戶的密鑰用Md5算法生成應答（Response），隨後將應答和自己的主機名送回。驗證方接到此應答後，用報文ID、本方保留的口令字（密鑰）和隨機報文用Md5算法得出結果，與被驗證方應答比較，根據比較結果返回相應的結果（ACK or NAK）
（1）接受認證端發送Challenge
（2）申請認證端發驗證請求報文
（3）接受認證端回應認證接受報文
經過以上三次報文交互後，CHAP認證完成。

CHAP認證流程
2.3 NCP協商階段（NCP：Network Control Protocol）

NCP有很多種，如IPCP、BCP、IPv6CP，最為常用的是IPCP（Internet Protocol Control Protocol）協議。NCP的主要功能是協商PPP報文的網絡層參數，如IP地址，DNS Server IP地址，WINS Server IP地址等。PPPoE用戶主要通過IPCP來獲取訪問網絡的IP地址或IP地址段。

NCP流程與LCP流程類似，用戶與ME設備之間互相發送NCP Config-Request報文並且互相回應NCP Config-Ack報文後，標誌NCP己協商完，用戶上線成功，可以正常訪問網絡了。

IPCP的協商過程是基於PPP狀態機進行協商的。經過雙方協商，通過配置請求、配置確認、配置否認等包文交換配置信息，最終由initial (或closed)狀態變為Opened狀態。IPCP狀態變為Opened的條件必須是發送方和接收方都發送和接收過確認包文。

IPCP協商過程中，協商包文可包含多個選項，即參數。各個選項的拒絕或否認都不能影響IPCP的UP，IPCP可以無選項協商，無選項協商也同樣能夠UP。選項有IP Address、網關、掩碼等，其中IP Address是最重要的一個選項，有些廠家的實現必須這個選項得到確認，大多數廠家的實現允許這個選項為空。

NCP的基本協商流程見下圖：

NCP的基本協商流程
用戶和接入設備對IP服務階段的一些要求進行多次協商，以決定雙方都能夠接收的約定。
如：IP業務階段使用的IP壓縮協議等。雙方的協議是通過報文中包含的Option項進行協商的，每一個Option都是一個需要協商的問題。

最後雙方都需要對方答復Configure_Ack的同意報文。

2.4 會話維持（Session Keep-alive）

設備主動發送Echo Request進行PPPoE心跳保活，若3次未得到服務器的響應，則設備主動釋放地址。發LCP Echo Request 的時候，魔術字字段要和之前通信的Configure_Request使用的魔術字字段保持一致。

有些設備或終端不支持主動發送 Echo-Request 報文, 只能支持回應Echo-Reply報文。

2.5 會話結束（Session Termination）

PPPoE 還有一個PADT（PPPOE Active Discovery Terminate）分組，它可以在會話建立後的任何時候發送，來終止PPPoE會話，也就是會話釋放。它可以由主機或者接入集中器發送，目的地址填充為對端的以太網的MAC地址。

當對方接收到一個 PADT（PPPOE Active Discovery Terminate）分組，就不再允許使用這個會話來發送PPP業務。PADT分組不需要任何標簽，其CODE字段值為0xa7（PADT Code），SESSION-ID字段值為需要終止的PPP會話的會話標識號碼。在發送或接收PADT後，即使正常的PPP終止分組也不必發送。PPP對端應該使用PPP協議自身來終止PPPoE會話，但是當PPP不能使用時，可以使用PADT。

3、抓包分析PPPoE連接過程

從上述過程可以分析出，在進行PPPoE撥號過程中，前5個包是PPPoE發現階段，該過程正常完成了PADI、PADO、PADR、PADS；接著是會話階段中的雙向LCP協商過程，第8個包為Configuration Reject包，兩次交互後，最終完成了Configuration Ack報文的交互，完成了LCP協商過程。第15個包發起身份認證請求，但是服務器回復Authenticate-Nak報文，服務器發出終止請求，後續相關交互終止了該次會話過程。
從上述抓包分析來看，我們可以根據PPPoE抓包來分析該協議的交互流程，進而定位PPPoE的相關bug。