校園有線寬帶常見個性化認證需求及解決方案

王翱翔

摘 要：在校園網有線寬帶發展的過程中，越來越多的校方提出了個性化認證需求。本文列舉了3個常見的個性化認證需求（多運營商共享接入網場景下PPPoE一次認證需求、二次認證需求以及單運營商接入場景下一次認證實現內外網同時訪問需求），并重點介紹了如何綜合應用PPPoE、L2TP以及策略路由等技術制定相應解決方案以滿足上述個性化需求。

關鍵詞：校園網 PPPoE L2TP 策略路由

中圖分類號：TP393.18 文獻標識碼：A 文章編號：1672-3791（2017）10（b）-0095-02

隨著信息技術的發展和互聯網應用的普及，有線寬帶接入目前已成為了每個高校的必然需求。在校園網有線寬帶發展的初期，校方對于校園網的需求通常簡單地局限在“能上網”即可，需求模型較為單一；但隨著校園網有線寬帶的普及，以及日常業務模型不斷復雜，越來越多的校方提出了個性化認證需求。

1 多運營商共享接入網場景下PPPoE一次認證

1.1 需求描述

前期校方已經通過某家運營商代建的方式建設了一張校園有線寬帶網絡，采用PPPoE方式進行撥號認證，認證通過后可進行公網訪問。

后期，為了讓學生有更多的自主選擇權利，校方擬引入多家運營商；考慮到接入網的建設及運營成本，多家運營商需共享原接入網（即各運營商無需重新布線，用戶使用原接入網）；鑒于PPPoE撥號較好的安全性、兼容性，以及用戶使用習慣的延續性，要求撥號方式保持不變。上述需求可以歸納為多運營商共享接入網場景下PPPoE一次認證需求。

1.2 PPPoE撥號認證簡介

PPP協議在撥號上網方面具有豐富的訪問控制、計費功能，同時具備良好的可擴展性和優秀的管理機制；另一方面，以太網技術已經成為了最為流行的局域網技術。PPPoE協議（Point to Point Protocol over Ethernet）將PPP協議和以太網協議兩者進行了緊密地銜接，成為了運營商廣為采用的撥號認證協議[1]。

PPPoE使用Client/Server模型，分為Discovery、Session和Terminate3個階段。其中Discovery階段主要用來建立主機端與服務器端的會話連接，常規情況下由PADI、PADO、PADR、PADS構成[2]：（1）PPPoE Client廣播發送一個PADI報文，在此報文中包含PPPoE Client想要得到的服務類型信息。（2）所有的PPPoE Server收到PADI報文之后，將其中請求的服務與自己能夠提供的服務進行比較，如果可以提供，則單播回復一個PADO報文。（3）根據網絡的拓撲結構，PPPoE Client可能收到多個PPPoE Server發送的PADO報文，PPPoE Client選擇最先收到的PADO報文對應的PPPoE Server做為自己的PPPoE Server，并單播發送一個PADR報文。（4）PPPoE Server產生一個唯一的會話ID（SESSION ID），標識和PPPoE Client的這個會話，通過發送一個PADS報文把會話ID發送給PPPoE Client，如果沒有錯誤，會話建立后便進入PPPoE Session階段。

1.3 解決方案

1.3.1 組網設計

該場景下的組網如圖所示：各家新接入的運營商在局端BRAS設備和校園匯聚交換機之間搭建光路，帶寬根據實際業務需求而定。為保證鏈路可靠性，建議進行鏈路匯聚，啟用LACP協議。

1.3.2 撥號軟件設計

為實現多運營商在共享接入網場景下同時使用PPPoE撥號認證，必須修改前文中所述的PPPoE Discovery階段常規流程：在PADI和PADO報文中設置相關參數，便于PPPoE Client和Server相互識別，確保PPPoE Client能夠和指定的PPPoE Server進行通信，建立起會話。

為此，需要開發一款特定的撥號客戶端。該撥號客戶端軟件除了普通PPPoE撥號功能外，還可以設置Service NAME字段，該字段用于在PPPoE的PADI報文中攜帶Service-NAME參數，與BRAS設備上設置的AC-NAME參數進行匹配。如果BRAS設備判斷客戶端發送的PADI報文中的Service-NAME與自身配置的AC-NAME參數一致，則向終端回復PADO；如果不一致，則回復PADT終止PPPoE協商。

1.3.3 業務流程

（1）校園匯聚設備與不同運營商局端BRAS互聯。（2）運營商局端BRAS創建PPPoE局數據，特別要注意配置AC-NAME參數。（3）用戶電腦安裝撥號軟件客戶端。用戶啟動客戶端軟件后，填寫運營商分配的用戶名和密碼，選擇運營商后點擊登錄按鈕。（4）客戶端發送PPPoE PADI請求，請求中攜帶Service-NAME參數（依據第3步中客戶選擇的運營商）。（5）BRAS收到校驗PADI報文后進行解析。如報文中Service-NAME參數與自身配置的參數一致，則校驗通過，回復PADO報文；客戶端收到PADO報文后，檢查里面的AC-Name參數與自身配置是否一致，如果一致，繼續發送PADR報文，進行接下來的PPPoE Discovery過程。（6）運營商BRAS聯動AAA系統進行用戶認證，通過后即可訪問公網。

2 多運營商共享接入網場景下二次認證

2.1 需求描述

部分高校為了自主掌握學生內網認證、計費信息，要求學生在撥號接入運營商出口之前，先通過PPPoE進行內網認證。內網認證通過后，方可采用L2TP進行運營商網絡認證。

2.2 L2TP撥號協議簡介

L2TP（Layer 2 Tunnel Protocol）是由IETF起草，微軟，思科等多家公司共同參與制定的第二層隧道協議。與PPPoE類似，L2TP一般也采用Client/Server模型，由L2TP訪問集中器LAC和L2TP網絡服務器LNS這2個基本構件組成。其中，LAC用于發起呼叫和建立隧道，將撥號用戶的PPP幀進行封裝后傳送至LNS；LNS為隧道終點，去掉封裝包頭，去掉PPP幀頭，獲得網絡層數據包[3]。隧道的建立是一個3次握手的過程，首先由LAC發起隧道建立請求SCCRQ，LNS收到請求后進行應答SCCRP，LAC在收到應答后返回確認SCCCN，隧道建立；會話建立的過程與隧道類似：首先由LAC發起會話建立請求ICRQ，LNS收到請求后返回應答ICRP，LAC收到應答后返回確認ICCN，會話建立[4]。endprint

2.3 解決方案

2.3.1 組網設計

各家新接入的運營商在局端BRAS設備和校園BRAS之間搭建光路，帶寬根據實際業務需求而定。為保證鏈路可靠性，建議進行鏈路匯聚，啟用LACP協議；校園BRAS設備和校方認證系統使用千兆光路互聯。

2.3.2 業務實現流程

（1）校園BRAS與運營商局端BRAS及內網認證平臺互聯。（2）校園BRAS針對不同運營商創建相應的用戶域，將校園BRAS與不同運營商互聯的接口綁定至對應的域中；創建其他PPPoE相關局數據。（3）校園BRAS為不同的域分配特定的IP地址池資源，打通地址池中IP與認證平臺的路由，使得地址池中的IP至對應運營商LNS路由可達；運營商BRAS創建L2TP相關局數據，以及至校園BRAS用戶地址池的回程路由。（4）用戶使用校方分配的賬號/密碼進行PPPoE撥號，校園BRAS聯動內網認證平臺進行用戶認證。認證通過后，用戶從所在域中獲取特定IP地址，并且至對應運營商LNS路由可達。（5）用戶使用對應運營商分配的賬號/密碼進行L2TP撥號，運營商BRAS聯動AAA系統進行用戶認證，通過后即可訪問公網。

3 單運營商接入場景下一次認證實現內外網同時訪問

3.1 需求描述

目前，部分校園在學生宿舍內同時開通了公網及校園內網。為了對學生上網進行認證審計，同時提升學生用戶使用感知，要求學生進行一次認證后便可同時訪問外網及校園內網。

3.2 策略路由

策略路由是一種數據包路由轉發機制，比基于目標網絡進行路由更加靈活。通常情況下，路由器根據所接收數據包的目的地址查找路由表，進而做出路由轉發決策，路由表決定了一個數據包的下一跳。

但特殊場景下，如果希望某些數據包通過其他路徑，而非根據路由表路徑進行轉發時，就需要使用策略路由。在此場景下，路由器轉發一個數據報文時，首先根據配置的規則對報文進行過濾，匹配成功則按照一定的轉發策略進行報文轉發。配置的規則可以基于源/目IP地址，可以基于訪問控制列表（ACL），可以基于報文長度等，使用起來極為靈活[5]。

正是因為這個靈活性，使得策略路由成為了傳統IP路由機制的有效增強。

3.3 解決方案

運營商局端BRAS設備分別與校園網匯聚設備和校園網內網出口設備建立物理光路，帶寬根據實際需求而定。為保證鏈路可靠性，建議進行鏈路匯聚，啟用LACP協議。

每個用戶在物理上具備公網、內網兩個出口。

4 結語

在筆者參與的65所高校互聯網建設過程中，發現每個學校對于其校園有線寬帶網絡均有其特定的個性化需求，但大的個性化需求不外乎前文所述的3類。綜合運用PPPoE、L2TP、策略路由技術可以滿足絕大部分應用場景。

參考文獻

[1] 謝希仁.計算機網絡[M].6版.北京：電子工業出版社，2013.

[2] L Mamakos，K Lidl，J Evarts，et al.A Method for Transmitting PPP Over Ethernet（PPPoE）[Z]. RFC 2516，1999.

[3] 佘堃，譚興烈，周明天.L2TP虛擬專用網[J].電子科技大學學報，2002（31）：383-386.

[4] W Townsley，A Valencia，A Rubens，et al.Layer 2 Tunneling Protocol（L2TP）[Z].RFC2661，1999.

[5] 李金平，高東杰.策略路由技術[Z].計算機科學，2002，29（4）：84-85.endprint