最初， IEEE 802 LAN/WAN 委员会为解决无线局域网网络安全问题，提出了 802.1X 协议。后来，802.1X 协议作为局域网的一个普通接入控制机制在以太网中被广泛应用，主要解决以太网内认证和安全方面的问题。
802.1X 协议是一种基于端口的网络接入控制协议，即在局域网接入设备的端口上对所接入的用户设备进行认证，以便用户设备控制对网络资源的访问。
802.1X的体系结构
802.1X系统中包括三个实体：客户端（ Client）、设备端（ Device）和认证服务器Authenticationserver），如 图 40-1 所示。
· 客户端是请求接入局域网的用户终端设备，它由局域网中的设备端对其进行认证。客户端上必须安装支持 802.1X 认证的客户端软件。
· 设备端是局域网中控制客户端接入的网络设备，位于客户端和认证服务器之间，为客户端提供接入局域网的端口（物理端口或逻辑端口），并通过与服务器的交互来对所连接的客户端进行认证。
· 认证服务器用于对客户端进行认证、授权和计费，通常为 RADIUS（ Remote AuthenticationDial-In User Service，远程认证拨号用户服务）服务器。认证服务器根据设备端发送来的客户端认证信息来验证客户端的合法性，并将验证结果通知给设备端，由设备端决定是否允许客户端接入。在一些规模较小的网络环境中，认证服务器的角色也可以由设备端来代替，即由设备端对客户端进行本地认证、授权和计费。
802.1X对端口的控制
1. 受控/非受控端口
设备端为客户端提供接入局域网的端口被划分为两个逻辑端口： 受控端口和非受控端口。任何到达该端口的帧，在受控端口与非受控端口上均可见。
· 非受控端口始终处于双向连通状态，主要用来传递 EAPOL（ Extensible AuthenticationProtocol over LAN，局域网上的可扩展认证协议）协议帧，保证客户端始终能够发出或接收认证报文。
· 受控端口在授权状态下处于双向连通状态，用于传递业务报文；在非授权状态下禁止从客户端接收任何报文。
2. 授权/非授权状态
设备端利用认证服务器对需要接入局域网的客户端执行认证，并根据认证结果（ Accept 或 Reject）对受控端口的授权状态进行相应地控制。
图 40-2 显示了受控端口上不同的授权状态对通过该端口报文的影响。图中对比了两个 802.1X认证系统的端口状态。系统 1 的受控端口处于非授权状态，不允许报文通过；系统 2 的受控端口处于授权状态，允许报文通过。
3. 受控方向
在非授权状态下，受控端口可以被设置成单向受控和双向受控。
· 处于双向受控状态时，禁止帧的发送和接收；
· 处于单向受控状态时，禁止从客户端接收帧，但允许向客户端发送帧。
说明：目前，设备上的受控端口只能处于单向受控状态。
802.1X的认证触发方式
802.1X 的认证过程可以由客户端主动发起，也可以由设备端发起。
1. 客户端主动触发方式
· 组播触发：客户端主动向设备端发送 EAPOL-Start 报文来触发认证，该报文目的地址为组播MAC 地址 01-80-C2-00-00-03。
· 广播触发：客户端主动向设备端发送 EAPOL-Start 报文来触发认证，该报文的目的地址为广播 MAC 地址。该方式可解决由于网络中有些设备不支持上述的组播报文，而造成认证设备无法收到客户端认证请求的问题。
目前， iNode 的 802.1X 客户端可支持广播触发方式。
2. 设备端主动触发方式
设备端主动触发方式用于支持不能主动发送 EAPOL-Start 报文的客户端，例如 Windows XP 自带的802.1X 客户端。设备主动触发认证的方式分为以下两种：
· 组播触发：设备每隔 N 秒（缺省为 30 秒）主动向客户端组播发送 Identity 类型的 EAP-Request帧来触发认证。
· 单播触发：当设备收到源 MAC 地址未知的报文时，主动向该 MAC 地址单播发送 Identity 类型的 EAP-Request 帧来触发认证。若设备端在设置的时长内没有收到客户端的响应，则重发该报文。
802.1X的认证过程
802.1X 系统支持采用 EAP 中继方式和 EAP 终结方式与远端 RADIUS 服务器交互。以下关于两种认证方式的过程描述，都以客户端主动发起认证为例。
1. EAP中继方式
这种方式是 IEEE 802.1X 标准规定的，将 EAP 承载在其它高层协议中，如 EAP over RADIUS，以便扩展认证协议报文穿越复杂的网络到达认证服务器。一般来说，需要 RADIUS 服务器支持 EAP属性： EAP-Message 和 Message-Authenticator，分别用来封装 EAP 报文及对携带 EAP-Message的 RADIUS 报文进行保护。
下面以MD5-Challenge认证方法为例介绍基本业务流程，认证过程如 图 40-3 所示。
(2) 当用户需要访问外部网络时打开 802.1X 客户端程序，输入已经申请、登记过的用户名和密码，发起连接请求。此时，客户端程序将向设备端发出认证请求帧（ EAPOL-Start），开始启动一次认证过程。
(3) 设备端收到认证请求帧后，将发出一个 Identity 类型的请求帧（ EAP-Request/Identity）要求用户的客户端程序发送输入的用户名。
(4) 客户端程序响应设备端发出的请求，将用户名信息通过 Identity 类型的响应帧（ EAP-Response/Identity）发送给设备端。
(5) 设备端将客户端发送的响应帧中的 EAP 报文封装在 RADIUS 报文（ RADIUS Access-Request）中发送给认证服务器进行处理。
(6) RADIUS 服务器收到设备端转发的用户名信息后，将该信息与数据库中的用户名列表中对比，找到该用户名对应的密码信息，用随机生成的一个 MD5 Challenge 对密码进行加密处理，同时将此 MD5 Challenge 通过 RADIUS Access-Challenge 报文发送给设备端。
(7) 设备端将 RADIUS 服务器发送的 MD5 Challenge 转发给客户端。
(8) 客户端收到由设备端传来的 MD5 Challenge 后，用该 Challenge 对密码部分进行加密处理，生成 EAP-Response/MD5 Challenge 报文，并发送给设备端。
(9) 设备端将此 EAP-Response/MD5 Challenge 报文封装在 RADIUS 报文（ RADIUSAccess-Request）中发送给 RADIUS 认证服务器。
(10) RADIUS 服务器将收到的已加密的密码信息和本地经过加密运算后的密码信息进行对比，如果相同，则认为该用户为合法用户，并向设备端发送认证通过报文（ RADIUSAccess-Accept）。
(11) 设备收到认证通过报文后向客户端发送认证成功帧（ EAP-Success），并将端口改为授权状态，允许用户通过端口访问网络。
(12) 用户在线期间，设备端会通过向客户端定期发送握手报文的方法，对用户的在线情况进行监测。
(13) 客户端收到握手报文后，向设备发送应答报文，表示用户仍然在线。缺省情况下，若设备端发送的两次握手请求报文都未得到客户端应答，设备端就会让用户下线，防止用户因为异常原因下线而设备无法感知。
(14) 客户端可以发送 EAPOL-Logoff 帧给设备端，主动要求下线。
(15) 设备端把端口状态从授权状态改变成未授权状态，并向客户端发送 EAP-Failure 报文。
说明：EAP 中继方式下，需要保证在客户端和 RADIUS 服务器上选择一致的 EAP 认证方法，而在设备，只需要配置 802.1X 用户的认证方式为 EAP 即可。
2. EAP终结方式
这种方式将EAP报文在设备端终结并映射到RADIUS报文中，利用标准RADIUS协议完成认证、授权和计费。设备端与RADIUS服务器之间可以采用PAP或者CHAP认证方法。下面以CHAP认证方法为例介绍基本业务流程，如 图 40-4 所示。
EAP 终结方式与 EAP 中继方式的认证流程相比，不同之处在于步骤(4)中用来对用户密码信息进行加密处理的 MD5 Challenge 由设备端生成，之后设备端会把用户名、 MD5 Challenge 和客户端加密后的密码信息一起送给 RADIUS 服务器，进行相关的认证处理。
802.1X的接入控制方式
设备不仅支持协议所规定的基于端口的接入认证方式（ Port Based），还对其进行了扩展、优化，支持基于 MAC 的接入控制方式（ MAC Based）。
·当采用基于端口的接入控制方式时，只要该端口下的第一个用户认证成功后，其它接入用户无须认证就可使用网络资源，但是当第一个用户下线后，其它用户也会被拒绝使用网络。
· 采用基于 MAC 的接入控制方式时，该端口下的所有接入用户均需要单独认证，当某个用户下线时，也只有该用户无法使用网络。
802.1X扩展功能
1. 支持VLAN下发
802.1X 用户在服务器上通过认证时， 服务器会把授权信息传送给设备端。如果服务器上指定了授权给该用户的下发 VLAN，则服务器发送给设备的授权信息中将含有下发的 VLAN 信息，设备根据用户认证上线的端口连接类型，按以下三种情况将端口加入下发 VLAN 中。
下发的 VLAN 并不影响端口的配置。但是，下发的 VLAN 的优先级高于用户配置的 VLAN，即通过认证后起作用的 VLAN 是下发的 VLAN，用户配置的 VLAN 在用户下线后生效。
说明：对于 Hybrid 端口，不建议把服务器将要下发或已经下发的 VLAN 配置为携带 Tag 的方式加入端口。
2. Guest VLAN
Guest VLAN 功能允许用户在未认证的情况下，访问某一特定 VLAN 中的资源。这个特定的 VLAN称之为 Guest VLAN，该 VLAN 内通常放置一些用于用户下载客户端软件或其他升级程序的服务器。
根据端口的接入控制方式不同， Guest VLAN 的生效情况有所不同。
(1) 端口的接入控制方式为 Port Based
在接入控制方式为Port Based的端口上配置Guest VLAN后，若在一定的时间内（默认 90 秒），该端口上无客户端进行认证，则该端口将被加入Guest VLAN，所有在该端口接入的用户将被授权访问Guest VLAN里的资源。不同链路类型的端口加入Guest VLAN的情况有所不同，具体情况与端口加入服务器下发的VLAN类似，请参见“1. 支持VLAN下发”。
当端口上处于Guest VLAN中的用户发起认证且失败时：如果端口配置了认证失败VLAN，则该端口会被加入认证失败VLAN；如果端口未配置认证失败VLAN，则该端口仍然处于Guest VLAN内。关于认证失败VLAN的具体介绍请参见“3. 认证失败VLAN”。
当端口上处于 Guest VLAN 中的用户发起认证且成功时，端口会离开 Guest VLAN，之后端口加入VLAN 情况与认证服务器是否下发 VLAN 有关，具体如下：
· 若认证服务器下发 VLAN，则端口加入下发的 VLAN 中。用户下线后，端口离开下发的 VLAN回到初始 VLAN 中，该初始 VLAN 为端口加入 Guest VLAN 之前所在的 VLAN。
· 若认证服务器不下发 VLAN，则端口回到初始 VLAN 中。用户下线后，端口仍在该初始 VLAN中。
(2) 端口的接入控制方式为 MAC Based
在接入控制方式为 MAC Based 的端口上配置 Guest VLAN 后，端口上未认证的用户被授权访问Guest VLAN 里的资源。
当端口上处于 Guest VLAN 中的用户发起认证且失败时，如果端口配置了认证失败 VLAN，则认证失败的用户将被加入认证失败 VLAN；如果端口未配置认证失败 VLAN，则该用户将仍然处于 GuestVLAN 内。
当端口上处于 Guest VLAN 中的用户发起认证且成功时，设备会根据认证服务器是否下发 VLAN 决定将该用户加入到下发的 VLAN 中，或回到加入 Guest VLAN 之前端口所在的初始 VLAN。
3. 认证失败VLAN
认证失败 VLAN（ Auth-Fail VLAN）功能允许用户在认证失败的情况下访问某一特定 VLAN 中的资源，这个 VLAN 称之为认证失败 VLAN。需要注意的是，这里的认证失败是认证服务器因某种原因明确拒绝用户认证通过， 比如用户密码错误，而不是认证超时或网络连接等原因造成的认证失败。根据端口的接入控制方式不同，认证失败 VLAN 的生效情况有所不同。
(1) 端口的接入控制方式为 Port Based
在接入控制方式为 Port Based 的端口上配置认证失败 VLAN 后，若该端口上有用户认证失败，则该端口会被加入到认证失败 VLAN，所有在该端口接入的用户将被授权访问认证失败 VLAN 里的资源。端口加入认证失败 VLAN 的情况与加入授权下发 VLAN 相同，与端口链路类型有关。
当加入认证失败 VLAN 的端口上有用户发起认证并失败，则该端口将会仍然处于认证失败 VLAN 内；如果认证成功，则该端口会离开认证失败 VLAN，之后端口加入 VLAN 情况与认证服务器是否下发VLAN 有关，具体如下：
· 若认证服务器下发 VLAN，则端口加入下发的 VLAN 中。用户下线后，端口会离开下发的VLAN 回到初始 VLAN 中，该初始 VLAN 为端口加入认证失败 VLAN 之前所在的 VLAN。
· 若认证服务器未下发 VLAN，则端口回到初始 VLAN 中。用户下线后，端口仍在该初始 VLAN中。
(2) 端口的接入控制方式为 MAC Based
在接入控制方式为 MAC Based 的端口上配置认证失败 VLAN 后，该端口上认证失败的用户将被授权访问认证失败 VLAN 里的资源。
当认证失败 VLAN 中的用户再次发起认证时，如果认证成功，则设备会根据认证服务器是否下发VLAN 决定将该用户加入到下发的 VLAN 中，或回到加入认证失败 VLAN 之前端口所在的初始 VLAN；如果认证失败，则该用户仍然留在该 VLAN 中。
