- 產品與解決方案
- 行業解決方案
- 服務
- 支持
- 合作夥伴
- BOB登陆 人才研學中心
- 關於我們
目 錄
IEEE802 LAN/WAN委員會為解決無線局域網網絡安全問題，提出了802.1X協議。後來，802.1X協議作為局域網端口的一個普通接入控製機製在以太網中被廣泛應用，主要解決以太網內認證和安全方麵的問題。
802.1X協議是一種基於端口的網絡接入控製協議（port based network access control protocol）。“基於端口的網絡接入控製”是指在局域網接入設備的端口這一級對所接入的用戶設備進行認證和控製。連接在端口上的用戶設備如果能通過認證，就可以訪問局域網中的資源；如果不能通過認證，則無法訪問局域網中的資源。
802.1X係統為典型的Client/Server結構，如圖 1所示，包括三個實體：客戶端（Client）、設備端（Device）和認證服務器（Server）。
圖 1 802.1X認證係統的體係結構
l 客戶端是位於局域網段一端的一個實體，由該鏈路另一端的設備端對其進行認證。客戶端一般為一個用戶終端設備，用戶可以通過啟動客戶端軟件發起802.1X認證。客戶端必須支持EAPOL（Extensible Authentication Protocol over LAN，局域網上的可擴展認證協議）。
l 設備端是位於局域網段一端的另一個實體，對所連接的客戶端進行認證。設備端通常為支持802.1X協議的網絡設備，它為客戶端提供接入局域網的端口，該端口可以是物理端口，也可以是邏輯端口。
l 認證服務器是為設備端提供認證服務的實體。認證服務器用於實現對用戶進行認證、授權和計費，通常為RADIUS（Remote Authentication Dial-In User Service，遠程認證撥號用戶服務）服務器。
802.1X認證係統使用EAP（Extensible Authentication Protocol，可擴展認證協議），來實現客戶端、設備端和認證服務器之間認證信息的交換。
l 在客戶端與設備端之間，EAP協議報文使用EAPOL封裝格式，直接承載於LAN環境中。
l 在設備端與RADIUS服務器之間，可以使用兩種方式來交換信息。一種是EAP協議報文由設備端進行中繼，使用EAPOR（EAP over RADIUS）封裝格式承載於RADIUS協議中；另一種是EAP協議報文由設備端進行終結，采用包含PAP（Password Authentication Protocol，密碼驗證協議）或CHAP（Challenge Handshake Authentication Protocal，質詢握手驗證協議）屬性的報文與RADIUS服務器進行認證交互。
設備端為客戶端提供接入局域網的端口，這個端口被劃分為兩個邏輯端口：受控端口和非受控端口。任何到達該端口的幀，在受控端口與非受控端口上均可見。
l 非受控端口始終處於雙向連通狀態，主要用來傳遞EAPOL協議幀，保證客戶端始終能夠發出或接收認證報文。
l 受控端口在授權狀態下處於雙向連通狀態，用於傳遞業務報文；在非授權狀態下禁止從客戶端接收任何報文。
設備端利用認證服務器對需要接入局域網的客戶端執行認證，並根據認證結果（Accept或Reject）對受控端口的授權/非授權狀態進行相應地控製。
圖 2顯示了受控端口上不同的授權狀態對通過該端口報文的影響。圖中對比了兩個802.1X認證係統的端口狀態。係統1的受控端口處於非授權狀態（相當於端口開關打開），係統2的受控端口處於授權狀態（相當於端口開關關閉）。
用戶可以通過在端口下配置的接入控製的模式來控製端口的授權狀態。端口支持以下三種接入控製模式：
l 強製授權模式（authorized-force）：表示端口始終處於授權狀態，允許用戶不經認證授權即可訪問網絡資源。
l 強製非授權模式（unauthorized-force）：表示端口始終處於非授權狀態，不允許用戶進行認證。設備端不對通過該端口接入的客戶端提供認證服務。
l 自動識別模式（auto）：表示端口初始狀態為非授權狀態，僅允許EAPOL報文收發，不允許用戶訪問網絡資源；如果認證通過，則端口切換到授權狀態，允許用戶訪問網絡資源。這也是最常見的情況。
在非授權狀態下，受控端口可以被設置成單向受控和雙向受控。
l 實行雙向受控時，禁止幀的發送和接收；
l 實行單向受控時，禁止從客戶端接收幀，但允許向客戶端發送幀。
EAPOL是802.1X協議定義的一種報文封裝格式，主要用於在客戶端和設備端之間傳送EAP協議報文，以允許EAP協議報文在LAN上傳送。EAPOL數據包的格式如圖 3所示。
圖 3 EAPOL數據包格式
PAE Ethernet Type：表示協議類型，為0x888E。
Protocol Version：表示EAPOL幀的發送方所支持的協議版本號。
Type：表示EAPOL數據幀類型，目前設備上支持的數據類型見表 1。
表 1 EAPOL數據類型
類型 | 說明 |
EAP-Packet（值為0x00）：認證信息幀，用於承載認證信息 | 該幀在設備端重新封裝並承載於RADIUS協議上，便於穿越複雜的網絡到達認證服務器 |
EAPOL-Start（值為0x01）：認證發起幀 | 這兩種類型的幀僅在客戶端和設備端之間存在 |
EAPOL-Logoff（值為0x02）：退出請求幀 |
Length：表示數據長度，也就是“Packet Body”字段的長度，單位為字節。如果為0，則表示沒有後麵的數據域。
Packet Body：表示數據內容，根據不同的Type有不同的格式。
當EAPOL數據包格式Type域為EAP-Packet時，Packet Body為EAP數據包結構，如圖 4所示。
圖 4 EAP數據包格式
Code：指明EAP包的類型，共有4種：Request、Response、Success、Failure。
l Success和Failure類型的包沒有Data域，相應的Length域的值為4。
l Request和Response類型數據包的Data域的格式如圖 5所示。Type為EAP的認證類型，Type data的內容由類型決定。例如，Type值為1時代表Identity，用來查詢對方的身份；Type值為4時，代表MD5-Challenge，類似於PPP CHAP協議，包含質詢消息。
圖 5 Request和Response類型數據包的Data域的格式
Identifier：用於匹配Request消息和Response消息。
Length：EAP包的長度，包含Code、Identifier、Length和Data域，單位為字節。
Data：EAP包的內容，由Code類型決定。
RADIUS為支持EAP認證增加了兩個屬性：EAP-Message（EAP消息）和Message-Authenticator（消息認證碼）。
如圖 6所示，這個屬性用來封裝EAP數據包，類型代碼為79，String域最長253字節，如果EAP數據包長度大於253字節，可以對其進行分片，依次封裝在多個EAP-Message屬性中。
圖 6 EAP-Message屬性封裝
如圖 7所示，這個屬性用於在使用EAP、CHAP等認證方法的過程中，避免接入請求包被竊聽。在含有EAP-Message屬性的數據包中，必須同時也包含Message-Authenticator，否則該數據包會被認為無效而被丟棄。
802.1X的認證過程可以由客戶端主動發起，也可以由設備端發起。設備支持的認證觸發方式包括以下兩種：
客戶端主動向設備端發送EAPOL-Start報文來觸發認證，該報文目的地址為IEEE 802.1X協議分配的一個組播MAC地址：01-80-C2-00-00-03。
另外，由於網絡中有些設備不支持上述的組播報文，使得認證設備無法收到客戶端的認證請求，因此設備端還支持廣播觸發方式，即，可以接收客戶端發送的目的地址為廣播MAC地址的EAPOL-Start報文。這種觸發方式需要H3C iNode的802.1X客戶端的配合。
設備會每隔N秒（例如30秒）主動向客戶端發送EAP-Request/Identity報文來觸發認證，這種觸發方式用於支持不能主動發送EAPOL-Start報文的客戶端，例如Windows XP自帶的802.1X客戶端。
802.1X係統支持EAP中繼方式和EAP終結方式與遠端RADIUS服務器交互完成認證。以下關於兩種認證方式的過程描述，都以客戶端主動發起認證為例。
這種方式是IEEE 802.1X標準規定的，將EAP（可擴展認證協議）承載在其它高層協議中，如EAP over RADIUS，以便擴展認證協議報文穿越複雜的網絡到達認證服務器。一般來說，EAP中繼方式需要RADIUS服務器支持EAP屬性：EAP-Message和Message-Authenticator，分別用來封裝EAP報文及對攜帶EAP-Message的RADIUS報文進行保護。
下麵以EAP-MD5方式為例介紹基本業務流程，如圖 8所示。
圖 8 IEEE 802.1X認證係統的EAP中繼方式業務流程
認證過程如下：
(1) 當用戶有訪問網絡需求時打開802.1X客戶端程序，輸入已經申請、登記過的用戶名和密碼，發起連接請求（EAPOL-Start報文）。此時，客戶端程序將發出請求認證的報文給設備端，開始啟動一次認證過程。
(2) 設備端收到請求認證的數據幀後，將發出一個請求幀（EAP-Request/Identity報文）要求用戶的客戶端程序發送輸入的用戶名。
(3) 客戶端程序響應設備端發出的請求，將用戶名信息通過數據幀（EAP-Response/Identity報文）發送給設備端。設備端將客戶端發送的數據幀經過封包處理後（RADIUS Access-Request報文）送給認證服務器進行處理。
(4) RADIUS服務器收到設備端轉發的用戶名信息後，將該信息與數據庫中的用戶名表對比，找到該用戶名對應的密碼信息，用隨機生成的一個加密字對它進行加密處理，同時也將此加密字通過RADIUS Access-Challenge報文發送給設備端，由設備端轉發給客戶端程序。
(5) 客戶端程序收到由設備端傳來的加密字（EAP-Request/MD5 Challenge報文）後，用該加密字對密碼部分進行加密處理（此種加密算法通常是不可逆的），生成EAP-Response/MD5 Challenge報文，並通過設備端傳給認證服務器。
(6) RADIUS服務器將收到的已加密的密碼信息（RADIUS Access-Request報文）和本地經過加密運算後的密碼信息進行對比，如果相同，則認為該用戶為合法用戶，反饋認證通過的消息（RADIUS Access-Accept報文和EAP-Success報文）。
(7) 設備收到認證通過消息後將端口改為授權狀態，允許用戶通過端口訪問網絡。在此期間，設備端會通過向客戶端定期發送握手報文的方法，對用戶的在線情況進行監測。缺省情況下，兩次握手請求報文都得不到客戶端應答，設備端就會讓用戶下線，防止用戶因為異常原因下線而設備無法感知。
(8) 客戶端也可以發送EAPOL-Logoff報文給設備端，主動要求下線。設備端把端口狀態從授權狀態改變成未授權狀態，並向客戶端發送EAP-Failure報文。
這種方式將EAP報文在設備端終結並映射到RADIUS報文中，利用標準RADIUS協議完成認證、授權和計費。設備端與RADIUS服務器之間可以采用PAP或者CHAP認證方法。以下以CHAP認證方法為例介紹基本業務流程，如圖 9所示。
圖 9 IEEE 802.1X認證係統的EAP終結方式業務流程
EAP終結方式與EAP中繼方式的認證流程相比，不同之處在於用來對用戶密碼信息進行加密處理的隨機加密字由設備端生成，之後設備端會把用戶名、隨機加密字和客戶端加密後的密碼信息一起送給RADIUS服務器，進行相關的認證處理。
設備不僅支持協議所規定的基於端口的接入認證方式，還對其進行了擴展、優化，支持基於MAC的接入控製方式。
l 當采用基於端口的接入控製方式時，隻要該端口下的第一個用戶認證成功後，其它接入用戶無須認證就可使用網絡資源，但是當第一個用戶下線後，其它用戶也會被拒絕使用網絡。
l 采用基於MAC的接入控製方式時，該端口下的所有接入用戶均需要單獨認證，當某個用戶下線時，也隻有該用戶無法使用網絡。
802.1X認證過程中會啟動多個定時器以控製接入用戶、設備以及RADIUS服務器之間進行合理、有序的交互。802.1X的定時器主要有以下幾種：
l 用戶名請求超時定時器（tx-period）：該定時器定義了兩個時間間隔。其一，當設備端向客戶端發送EAP-Request/Identity請求報文後，設備端啟動該定時器，若在tx-period設置的時間間隔內，設備端沒有收到客戶端的響應，則設備端將重發認證請求報文；其二，為了兼容不主動發送EAPOL-Start連接請求報文的客戶端，設備會定期組播EAP-Request/Identity請求報文來檢測客戶端。tx-period定義了該組播報文的發送時間間隔。
l 客戶端認證超時定時器（supp-timeout）：當設備端向客戶端發送了EAP-Request/MD5 Challenge請求報文後，設備端啟動此定時器，若在該定時器設置的時長內，設備端沒有收到客戶端的響應，設備端將重發該報文。
l 認證服務器超時定時器（server-timeout）：當設備端向認證服務器發送了RADIUS Access-Request請求報文後，設備端啟動server-timeout定時器，若在該定時器設置的時長內，設備端沒有收到認證服務器的響應，設備端將重發認證請求報文。
l 握手定時器（handshake-period）：此定時器是在用戶認證成功後啟動的，設備端以此間隔為周期發送握手請求報文，以定期檢測用戶的在線情況。如果配置發送次數為N，則當設備端連續N次沒有收到客戶端的響應報文，就認為用戶已經下線。
l 靜默定時器（quiet-period）：對用戶認證失敗以後，設備端需要靜默一段時間（該時間由靜默定時器設置），在靜默期間，設備端不處理該用戶的認證請求。
l 周期性重認證定時器（reauth-period）：如果端口下開啟了周期性重認證功能，設備端以此定時器設置的時間間隔為周期對該端口在線用戶發起重認證。
802.1X用戶在服務器上通過認證時，服務器會把授權信息傳送給設備端。如果服務器上配置了下發VLAN功能，則授權信息中含有授權下發的VLAN信息，設備根據用戶認證上線的端口鏈路類型，按以下三種情況將端口加入下發VLAN中。
l 端口的鏈路類型為Access，當前Access端口離開用戶配置的VLAN並加入授權下發的VLAN中。
l 端口的鏈路類型為Trunk，設備允許授權下發的VLAN通過當前Trunk端口，並且端口的缺省VLAN ID為下發VLAN的VLAN ID。
l 端口的鏈路類型為Hybrid，設備允許授權下發的VLAN以不攜帶Tag的方式通過當前Hybrid端口，並且端口的缺省VLAN ID為下發VLAN的VLAN ID。需要注意的是，若當前Hybrid端口上配置了基於MAC的VLAN，則設備將根據認證服務器下發的授權VLAN動態地創建基於用戶MAC的VLAN，而端口的缺省VLAN ID並不改變。
授權下發的VLAN並不改變端口的配置，也不影響端口的配置。但是，授權下發的VLAN的優先級高於用戶配置的VLAN，即通過認證後起作用的VLAN是授權下發的VLAN，用戶配置的VLAN在用戶下線後生效。
Guest VLAN功能允許用戶在未認證的情況下，可以訪問某一特定VLAN中的資源，比如獲取客戶端軟件，升級客戶端或執行其他一些用戶升級程序。這個VLAN稱之為Guest VLAN。
根據端口的接入控製方式不同，可以將Guest VLAN劃分基於端口的Guest VLAN和基於MAC的Guest VLAN。
(1) PGV（Port-based Guest VLAN）
在接入控製方式為portbased的端口上配置的Guest VLAN稱為PGV。若在一定的時間內（默認90秒），配置了PGV的端口上無客戶端進行認證，則該端口將被加入Guest VLAN，所有在該端口接入的用戶將被授權訪問Guest VLAN裏的資源。端口加入Guest VLAN的情況與加入授權下發VLAN相同，與端口鏈路類型有關。
當端口上處於Guest VLAN中的用戶發起認證且失敗時：如果端口配置了Auth-Fail VLAN，則該端口會被加入Auth-Fail VLAN；如果端口未配置Auth-Fail VLAN，則該端口仍然處於Guest VLAN內。關於Auth-Fail VLAN的具體介紹請參見“3. Auth-Fail VLAN”。
當端口上處於Guest VLAN中的用戶發起認證且成功時，端口會離開Guest VLAN，之後端口加入VLAN情況與認證服務器是否下發VLAN有關，具體如下：
l 若認證服務器下發VLAN，則端口加入下發的VLAN中。用戶下線後，端口離開下發的VLAN回到初始VLAN中，該初始VLAN為端口加入Guest VLAN之前所在的VLAN。
l 若認證服務器未下發VLAN，則端口回到初始VLAN中。用戶下線後，端口仍在該初始VLAN中。
(2) MGV（MAC-based Guest VLAN）
在接入控製方式為macbased的端口上配置的Guest VLAN稱為MGV。配置了MGV的端口上未認證的用戶被授權訪問Guest VLAN裏的資源。
當端口上處於Guest VLAN中的用戶發起認證且失敗時：如果端口配置了Auth-Fail VLAN，則認證失敗的用戶將被加入Auth-Fail VLAN；如果端口未配置Auth-Fail VLAN，則該用戶將仍然處於Guest VLAN內。
當端口上處於Guest VLAN中的用戶發起認證且成功時，設備會根據認證服務器是否下發VLAN決定將該用戶加入到下發的VLAN中，或回到加入Guest VLAN之前端口所在的初始VLAN。
Auth-Fail VLAN功能允許用戶在認證失敗的情況下可以訪問某一特定VLAN中的資源，這個VLAN稱之為Auth-Fail VLAN。需要注意的是，這裏的認證失敗是認證服務器因某種原因明確拒絕用戶認證通過，比如用戶密碼錯誤，而不是認證超時或網絡連接等原因造成的認證失敗。
與Guest VLAN類似，根據端口的接入控製方式不同，可以將Auth-Fail VLAN劃分為基於端口的Auth-Fail VLAN和基於MAC的Auth-Fail VLAN。
(1) PAFV（Port-based Auth-Fail VLAN）
在接入控製方式為portbased的端口上配置的Auth-Fail VLAN稱為PAFV。在配置了PAFV的端口上，若有用戶認證失敗，則該端口會被加入到Auth-Fail VLAN，所有在該端口接入的用戶將被授權訪問Auth-Fail VLAN裏的資源。端口加入Auth-Fail VLAN的情況與加入授權下發VLAN相同，與端口鏈路類型有關。
當端口上處於Auth-Fail VLAN中的用戶再次發起認證時：如果認證失敗，則該端口將會仍然處於Auth-Fail VLAN內；如果認證成功，則該端口會離開Auth-Fail VLAN，之後端口加入VLAN情況與認證服務器是否下發VLAN有關，具體如下：
l 若認證服務器下發VLAN，則端口加入下發的VLAN中。用戶下線後，端口會離開下發的VLAN回到初始VLAN中，該初始VLAN為端口加入任何授權VLAN之前所在的VLAN。
l 若認證服務器未下發VLAN，則端口回到初始VLAN中。用戶下線後，端口仍在該初始VLAN中。
(2) MAFV（MAC-based Auth-Fail VLAN）
在接入控製方式為macbased的端口上配置的Auth-Fail VLAN稱為MAFV。在配置了MAFV的端口上，認證失敗的用戶將被授權訪問Auth-Fail VLAN裏的資源。
當Auth-Fail VLAN中的用戶再次發起認證時，如果認證成功，則設備會根據認證服務器是否下發VLAN決定將該用戶加入到下發的VLAN中，或回到加入Auth-Fail VLAN之前端口所在的初始VLAN。
ACL（Access Control List，訪問控製列表）提供了控製用戶訪問網絡資源和限製用戶訪問權限的功能。當用戶上線時，如果RADIUS服務器上配置了授權ACL，則設備會根據服務器下發的授權ACL對用戶所在端口的數據流進行控製；在服務器上配置授權ACL之前，需要在設備上配置相應的規則。管理員可以通過改變服務器的授權ACL設置或設備上對應的ACL規則來改變用戶的訪問權限。
指定端口的強製認證域（mandatory domain）為802.1X接入提供了一種安全控製策略。所有從該端口接入的802.1X用戶將被強製使用該認證域來進行認證、授權和計費，可以防止用戶通過惡意假冒其它域賬號來接入網絡。
另外，對於采用證書的EAP中繼方式的802.1X認證來說，接入用戶的客戶端證書決定了用戶的域名。因此，即使所有端口上客戶端的用戶證書隸屬於同一證書頒發機構，即輸入的用戶域名相同，管理員也可以通過配置強製認證域對不同端口指定不同的認證域，從而增加了管理員部署802.1X接入策略的靈活性。
EAD（Endpoint Admission Defense，端點準入防禦）作為一個網絡端點接入控製方案，它通過安全客戶端、安全策略服務器、接入設備以及第三方服務器的聯動，加強了對用戶的集中管理，提升了網絡的整體防禦能力。但是在實際的應用過程中EAD客戶端的部署工作量很大，例如，需要網絡管理員手動為每一個EAD客戶端下載、升級客戶端軟件，這在EAD客戶端數目較多的情況下給管理員帶來了操作上的不便。
802.1X認證支持的EAD快速部署就可以解決以上問題，可為所有接入網絡的終端用戶提供自動下載並安裝EAD客戶端的方便途徑。
802.1X支持的EAD快速部署是通過以下兩個功能的配合工作實現的：
(1) 用戶受限訪問
802.1X認證成功之前（包括認證失敗），終端用戶隻能訪問一個特定的IP地址段。該IP地址段中可以配置一個或多個特定服務器，用於提供EAD客戶端的下載升級或者動態地址分配等服務。
(2) 用戶HTTP訪問URL重定向
終端用戶在802.1X認證成功之前（包括認證失敗），如果使用瀏覽器訪問網絡，設備會將用戶訪問的URL重定向到已配置的URL（例如，重定向到EAD客戶端下載界麵），這樣隻要用戶打開瀏覽器，就必須進入管理員預設的界麵。提供重定向URL的服務器必須位於用戶受限訪問的特定網段內。
售前谘詢
售後谘詢
人工在線谘詢
