802.1x(dot1x)_h3c交换机dot1x逃生vlan

转载：802.1x（dot1x）协议详解 作者：大西洋里的鱼

802.1x协议是基于Client/Server的访问控制和认证协议。

它可以限制未经授权的用户/设备通过接入端口(access port)访问LAN/WLAN。在获得交换机或LAN提供的各种业务之前，802.1x对连接到交换机端口上的用户/设备进行认证。在认证通过之前，802.1x只允许EAPOL（基于局域网的扩展认证协议）数据通过设备连接的交换机端口；认证通过以后，正常的数据可以顺利地通过以太网端口。

客户端 设备端 认证服务器需要满足的要求

客户端：局域网用户终端设备，但必须是支持EAPOL（Extensible Authentication Protocol over LAN，局域网可扩展认证协议）的设备（如PC机），可通过启动客户端设备上安装的802.1x客户端软件发起802.1x认证。

设备端：支持802.1x协议的网络设备（如交换机），对所连接的客户端进行认证。它为客户端提供接入局域网的端口，可以是物理端口，也可以是逻辑端口（如Eth-Trunk口）。

认证服务器：为设备端802.1x协议提供认证服务的设备，是真正进行认证的设备，实现对用户进行认证、授权和计费，通常为RADIUS服务器。

802.1X认证的触发方式

802.1x的认证过程可以由客户端主动发起，也可以由设备端主动发起。在“客户端主动触发方式”中，由客户端主动向设备端发送EAPOL-Start（EAPOL开始）报文来触发认证；而“设备端主动触发方式”中用于支持不能主动发送EAPOL-Start报文的客户端，例如Windows XP自带的802.1x客户端。

设备端主动触发方式”中又有两种以下具体的触发方式“

DHCP报文触发：设备在收到用户的DHCP请求报文后主动触发对用户的802.1x认证，仅适用于客户端采用DHCP方式自动分配IP地址的情形。因为DHCP请求报文是以广播方式发送的，所以在同一网段中的设备都可以收到，故设备端不一定就是担当DHCP服务器的设备。

源MAC地址未知报文触发：当设备收到源MAC地址未知的报文时主动触发对用户的802.1x认证。若设备端在设置的时长内没有收到客户端的响应，则重发该报文。

802.1x的认证方式

无论是哪种触发方式，802.1x认证系统都是使用EAP协议来实现客户端、设备端和认证服务器之间认证信息的交换。在客户端与设备端之间使用的是基于以太局域网的EAPOL格式封装EAP报文，然后承载于以太网数据帧中进行交互；而设备端与RADIUS服务器之间的EAP报文可以使用以下两种方式进行交互：

EAP中继：来自客户端的EAP报文到达设备端后，直接使用EAPOR（EAP over RADIUS）格式封装在RADIUS报文中，再发送给RADIUS服务器，则RADIUS服务器来从封装的EAP报文中获取客户端认证信息，然后再对客户端进行认证。

这种认证方式的优点是设备端的工作很简单，不需要对来自客户端的EAP报文进行任何处理，只需要用EAPOR对EAP报文进行封装即可，根本不管客户端的认证信息。同时在这种认证方式中，设备端与RADIUS服务器之间可支持多种EAP认证方法，例如MD5-Challenge、EAP-TLS、PEAP等，但要求服务器端也支持相应的认证方法。

EAP终结：来自客户端的EAP报文在设备端进行终结，然后由设备端将从EAP报文中提取的客户端认证信息封装在标准的RADIUS报文（不再是EAPOR格式）中，与RADIUS服务器之间采用PAP（Password Authentication Protocol，密码验证协议）或CHAP（Challenge Handshake Authentication Protocal，质询握手验证协议）方式对客户端进行认证（当然在RAIUDS服务器端必须配置合法用户的用户名和密码信息）。

这种认证方式的优点是现有的RADIUS服务器基本均可支持PAP和CHAP认证，无需升级服务器，但设备端的工作比较繁重，因为在这种认证方式中，设备端不仅要从来自客户端的EAP报文中提取客户端认证信息，还要通过标准的RAIUDS协议对这些信息进行封装，且不能支持除MD5-Challenge之外的其它EAP认证方法。

802.1x认证原理

对于EAP中继方式，802.1X认证流程如下图所示：

在第5步中，如果采用的是EAP-MD5认证，则处理方式方式如下：
认证服务器收到接入设备转发的用户名信息后，按照如下方式对其密码进行验证。

认证服务器将用户名信息与数据库中的用户名列表进行对比，找到该用户名对应的密码信息。
认证服务器用随机生成的一个MD5 Challenge对密码进行加密处理，并将此MD5 Challenge通过接入设备发送给客户端。
客户端收到由接入设备转发的MD5 Challenge后，用该Challenge对密码部分进行加密处理，之后将加密后的密码通过接入设备发送到认证服务器。
认证服务器将收到的已加密的密码信息和本地经过加密运算后的密码信息进行对比。如果相同，则认为该用户为合法用户；如果不同，则认为该用户为非法用户。
EAP终结方式与EAP中继方式的认证流程相比，不同之处在于步骤4和5。对于EAP终结方式，当接入设备将客户端发送的用户名信息发送给认证服务器时，会随机生成一个MD5 Challenge并发送给客户端（MD5 Challenge由接入设备生成而非认证服务器生成）。之后接入设备会把用户名、MD5 Challenge和客户端加密后的密码信息一起送给认证服务器，进行相关的认证处理。

在EAP中继认证的过程中，设备端起一个中继代理的角色，用于通过EAPOR封装和解封装的过程转发客户端和认证服务器之间的交互报文。整个认证过程是先进行用户名认证，然后再进行对应的密码认证，具体如下

（1）当用户访问网络时自动打开802.1x客户端程序，根据提示输入已经在RADIUS服务器中创建的用户名和密码，发起连接请求。因为端口最初的状态是未授权状态，所以此时端口除了IEEE 802.1x协议包外不能接收和发送任何包。此时，客户端程序将向设备端发出认证请求帧（EAPOL-Start），启动认证过程。

（2）设备端在收到客户端的认证请求帧后，将发出一个Identity（标识）类型的EAP请求帧（EAP-Request/Identity），要求用户的客户端程序发送上一步用户所输入的用户名。

（3）客户端程序在收到设备端的Identity请求帧后，将用户名信息通过Identity类型的EAP响应帧（EAP-Response/Identity）发送给设备端，响应设备端发出的请求。

（4）设备端将客户端发送的Identity响应帧中的EAP报文原封不动地使用EAPOR格式封装在RADIUS报文（ RADIUS Access-Request）中，发送给认证服务器进行处理。

（5）RADIUS服务器收到设备端发来的RADIUS报文后从中提取用户名信息后，将该信息与数据库中的用户名列表中对比，找到该用户名对应的密码信息，并用随机生成的一个MD5 Challenge消息对密码进行加密处理，然后将此MD5 Challenge消息同样通过EAPOR格式封装以RADIUS Access-Challenge报文发送给设备端。

（6）设备端在收到来自RADIUS服务器的EAPOR格式的Access-Challenge报文后，通过解封装，将其中的MD5 Challenge消息转发给客户端。

（7）客户端在收到由设备端传来的MD5 Challenge消息后，用该Challenge消息对密码部分进行加密处理，然后生成EAP-Response/MD5 Challenge报文，并发送给设备端。

（8）设备端又将此EAP-Response/MD5 Challenge报文以EAPOR格式封装在RADIUS报文（ RADIUS Access-Request）中发送给RADIUS服务器。

（9）RADIUS服务器将收到的已加密的密码信息后，与第（5）步在本地经过加密运算后的密码信息进行对比，如果相同则认为为合法用户，并向设备端发送认证通过报文（RADIUS Access-Accept）。

（10）设备收到RADIUS Access-Accept报文后，经过EAPOR解封装再以EAP-Success报文向客户端发送，并将端口改为授权状态，允许用户通过端口访问网络。

（11）用户在线期间设备端会通过向客户端定期发送握手报文，对用户的在线情况进行监测。

（12）客户端收到握手报文后向设备发送应答报文，表示用户仍然在线。缺省情况下，若设备端发送的两次握手请求报文都未得到客户端应答，设备端就会让用户下线，防止用户因为异常原因下线而设备无法感知。

（13）客户端可以发送EAPOL-Logoff帧给设备端，主动要求下线。

（14）在设备端收到客户端发来的EAPOL-Logoff帧后，把端口状态从授权状态改变成未授权状态，并向客户端发送EAP-Failure报文，确认对应客户端下线。

2. EAP终结认证原理

EAP终结方式与EAP中继方式的认证流程相比，主要不同在于步骤（4）中用来对用户密码信息进行加密处理的MD5 challenge是由设备端生成（而不是由RADIUS服务器生成），之后设备端会把用户名、MD5 challenge和客户端加密后的密码信息一起送给RADIUS服务器，进行相关的认证处理。

3. MAC旁路认证

在802.1x认证过程中，设备端会首先触发用户采用802.1x认证方式，但若用户长时间内没有进行802.1x认证，则以用户的MAC地址作为用户名和密码上送认证服务器进行认证。MAC旁路认证可使802.1x认证系统中无法安装和使用802.1x客户端软件的终端，例如打印机等，以自身MAC地址作为用户名和密码进行认证。

和802.1X配合使用的特性

1. VLAN下发

802.1X用户在服务器上通过认证时，服务器会把授权信息传送给设备端。如果服务器上配置了下发VLAN功能，则授权信息中含有授权下发的VLAN信息，设备根据用户认证上线的端口链路类型，按以下三种情况将端口加入下发VLAN中。

端口的链路类型为Access，当前Access端口离开用户配置的VLAN并加入授权下发的VLAN中。
端口的链路类型为Trunk，设备允许授权下发的VLAN通过当前Trunk端口，并且端口的缺省VLAN ID为下发VLAN的VLAN ID。
端口的链路类型为Hybrid，设备允许授权下发的VLAN以不携带Tag的方式通过当前Hybrid端口，并且端口的缺省VLAN ID为下发VLAN的VLAN ID。需要注意的是，若当前Hybrid端口上配置了基于MAC的VLAN，则设备将根据认证服务器下发的授权VLAN动态地创建基于用户MAC的VLAN，而端口的缺省VLAN ID并不改变。
授权下发的VLAN并不改变端口的配置，也不影响端口的配置。但是，授权下发的VLAN的优先级高于用户配置的VLAN，即通过认证后起作用的VLAN是授权下发的VLAN，用户配置的VLAN在用户下线后生效。

2. Guest 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有关，具体如下：

若认证服务器下发VLAN，则端口加入下发的VLAN中。用户下线后，端口离开下发的VLAN回到初始VLAN中，该初始VLAN为端口加入Guest VLAN之前所在的VLAN。
若认证服务器未下发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。

3. Auth-Fail 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有关，具体如下：

若认证服务器下发VLAN，则端口加入下发的VLAN中。用户下线后，端口会离开下发的VLAN回到初始VLAN中，该初始VLAN为端口加入任何授权VLAN之前所在的VLAN。
若认证服务器未下发VLAN，则端口回到初始VLAN中。用户下线后，端口仍在该初始VLAN中。
MAFV（MAC-based Auth-Fail VLAN）
在接入控制方式为macbased的端口上配置的Auth-Fail VLAN称为MAFV。在配置了MAFV的端口上，认证失败的用户将被授权访问Auth-Fail VLAN里的资源。

当Auth-Fail VLAN中的用户再次发起认证时，如果认证成功，则设备会根据认证服务器是否下发VLAN决定将该用户加入到下发的VLAN中，或回到加入Auth-Fail VLAN之前端口所在的初始VLAN。

4. ACL下发

ACL（Access Control List，访问控制列表）提供了控制用户访问网络资源和限制用户访问权限的功能。当用户上线时，如果RADIUS服务器上配置了授权ACL，则设备会根据服务器下发的授权ACL对用户所在端口的数据流进行控制；在服务器上配置授权ACL之前，需要在设备上配置相应的规则。管理员可以通过改变服务器的授权ACL设置或设备上对应的ACL规则来改变用户的访问权限。

5. 指定端口的强制认证域

指定端口的强制认证域（mandatory domain）为802.1X接入提供了一种安全控制策略。所有从该端口接入的802.1X用户将被强制使用该认证域来进行认证、授权和计费，可以防止用户通过恶意假冒其它域账号来接入网络。

另外，对于采用证书的EAP中继方式的802.1X认证来说，接入用户的客户端证书决定了用户的域名。因此，即使所有端口上客户端的用户证书隶属于同一证书颁发机构，即输入的用户域名相同，管理员也可以通过配置强制认证域对不同端口指定不同的认证域，从而增加了管理员部署802.1X接入策略的灵活性。

802.1X支持EAD快速部署配置

1. 概述

EAD（Endpoint Admission Defense，端点准入防御）作为一个网络端点接入控制方案，它通过安全客户端、安全策略服务器、接入设备以及第三方服务器的联动，加强了对用户的集中管理，提升了网络的整体防御能力。但是在实际的应用过程中EAD客户端的部署工作量很大，例如，需要网络管理员手动为每一个EAD客户端下载、升级客户端软件，这在EAD客户端数目较多的情况下给管理员带来了操作上的不便。

802.1X认证支持的EAD快速部署就可以解决以上问题，可为所有接入网络的终端用户提供自动下载并安装EAD客户端的方便途径。

2. 实现机制

802.1X支持的EAD快速部署是通过以下两个功能的配合工作实现的：

(1)用户受限访问

802.1X认证成功之前（包括认证失败），终端用户只能访问一个特定的IP地址段。该IP地址段中可以配置一个或多个特定服务器，用于提供EAD客户端的下载升级或者动态地址分配等服务。

(2)用户HTTP访问URL重定向

终端用户在802.1X认证成功之前（包括认证失败），如果使用浏览器访问网络，设备会将用户访问的URL重定向到已配置的URL（例如，重定向到EAD客户端下载界面），这样只要用户打开浏览器，就必须进入管理员预设的界面。提供重定向URL的服务器必须位于用户受限访问的特定网段内