- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 新华三人才研学中心
- 关于我们
03-802.1X配置
本章节下载： 03-802.1X配置 (524.78 KB)
本章节主要描述了802.1X的相关概念及配置步骤。由于通过配置端口安全特性也可以为用户提供802.1X认证服务，且还可以提供802.1X和MAC地址认证的扩展和组合应用，因此在需要灵活使用以上两种认证方式的组网环境下，推荐使用端口安全特性。无特殊组网要求的情况下，无线环境中通常使用端口安全特性。而在仅需要802.1X特性来完成接入控制的组网环境下，推荐单独使用802.1X特性。关于端口安全特性的详细介绍和具体配置请参见“安全配置指导”中的“端口安全”。
最初，IEEE802 LAN/WAN委员会为解决无线局域网的网络安全问题，提出了802.1X协议。后来，802.1X协议作为局域网的一个普通接入控制机制在以太网中被广泛应用，主要解决以太网内认证和安全方面的问题。
802.1X协议是一种基于端口的网络接入控制协议，即在局域网接入设备的端口上对所接入的用户设备进行认证，以便用户设备控制对网络资源的访问。
802.1X系统中包括三个实体：客户端（Client）、设备端（Device）和认证服务器（Authentication server），如图1-1所示。
图1-1 802.1X体系结构图
· 客户端是请求接入局域网的用户终端设备，它由局域网中的设备端对其进行认证。客户端上必须安装支持802.1X认证的客户端软件。
· 设备端是局域网中控制客户端接入的网络设备，位于客户端和认证服务器之间，为客户端提供接入局域网的端口（物理端口或逻辑端口），并通过与服务器的交互来对所连接的客户端进行认证。
· 认证服务器用于对客户端进行认证、授权和计费，通常为RADIUS（Remote Authentication Dial-In User Service，远程认证拨号用户服务）服务器。认证服务器根据设备端发送来的客户端认证信息来验证客户端的合法性，并将验证结果通知给设备端，由设备端决定是否允许客户端接入。在一些规模较小的网络环境中，认证服务器的角色也可以由设备端来代替，即由设备端对客户端进行本地认证、授权和计费。
设备端为客户端提供接入局域网的端口被划分为两个逻辑端口：受控端口和非受控端口。任何到达该端口的帧，在受控端口与非受控端口上均可见。
· 非受控端口始终处于双向连通状态，主要用来传递EAPOL协议帧，保证客户端始终能够发出或接收认证报文。
· 受控端口在授权状态下处于双向连通状态，用于传递业务报文；在非授权状态下禁止从客户端接收任何报文。
设备端利用认证服务器对需要接入局域网的客户端进行认证，并根据认证结果（Accept或Reject）对受控端口的授权状态进行相应地控制。
图1-2显示了受控端口上不同的授权状态对通过该端口报文的影响。图中对比了两个802.1X认证系统的端口状态。系统1的受控端口处于非授权状态，不允许报文通过；系统2的受控端口处于授权状态，允许报文通过。
· 处于单向受控状态时，禁止从客户端接收帧，但允许向客户端发送帧。
802.1X系统使用EAP（Extensible Authentication Protocol，可扩展认证协议）来实现客户端、设备端和认证服务器之间认证信息的交互。EAP是一种C/S模式的认证框架，它可以支持多种认证方法，例如MD5-Challenge、EAP-TLS、PEAP等。在客户端与设备端之间，EAP报文使用EAPOL（Extensible Authentication Protocol over LAN，局域网上的可扩展认证协议）封装格式承载于数据帧中传递。在设备端与RADIUS服务器之间，EAP报文的交互有以下两种处理机制。
设备对收到的EAP报文进行中继，使用EAPOR（EAP over RADIUS）封装格式将其承载于RADIUS报文中发送给RADIUS服务器进行认证。
图1-3 EAP中继原理示意图
该处理机制下，EAP认证过程在客户端和RADIUS服务器之间进行，RADIUS服务器作为EAP服务器来处理客户端的EAP认证请求，设备相当于一个代理，仅对EAP报文做中转，因此设备处理简单，并能够支持EAP的各种认证方法，但要求RADIUS服务器支持相应的EAP认证方法。
在RADIUS服务器不能支持EAP认证，或者实际网络环境中未部署RADIUS服务器的情况下，如果希望使用EAP中继模式来支持多种EAP认证方法，则还需要在设备上配置专门的本地EAP服务器来协助完成EAP认证。关于本地EAP认证的具体配置请参见“安全配置指导”中的“AAA”。
设备对EAP认证过程进行终结，将收到的EAP报文中的客户端认证信息封装在标准的RADIUS报文中，与服务器之间采用PAP（Password Authentication Protocol，密码验证协议）或CHAP（Challenge Handshake Authentication Protocol，质询握手验证协议）方法进行认证。
图1-4 EAP终结原理示意图
该处理机制下，由于现有的RADIUS服务器基本均可支持PAP认证和CHAP认证，因此对服务器无特殊要求，但设备处理较为复杂，它需要作为EAP服务器来解析与处理客户端的EAP报文，且目前仅能支持MD5-Challenge类型的EAP认证以及iNode 802.1X客户端发起的“用户名+密码”方式的EAP认证。
如果客户端采用了MD5-Challenge类型的EAP认证，则设备端只能采用CHAP认证；如果iNode 802.1X客户端采用了“用户名+密码”方式的EAP认证，设备上可选择使用PAP认证或CHAP认证，从安全性上考虑，通常使用CHAP认证。
(1) EAPOL数据帧的格式
EAPOL是802.1X协议定义的一种承载EAP报文的封装协议，主要用于在局域网中传送客户端和设备端之间的EAP协议报文。EAPOL数据包的格式如图1-5所示。
图1-5 EAPOL数据包格式
· PAE Ethernet Type：表示协议类型。EAPOL的协议类型为0x888E。
· Protocol Version：表示EAPOL数据帧的发送方所支持的EAPOL协议版本号。
· Type：表示EAPOL数据帧类型。目前设备上支持的EAPOL数据帧类型见表1-1。
表1-1 EAPOL数据帧类型
|
· 在终结方式下，该帧中的客户端认证信息会被设备端重新封装并承载于RADIUS报文中发送给认证服务器 · 在中继方式下，该帧承载的EAP报文会被设备端直接封装在RADIUS报文的EAP属性中发送给认证服务器 |
||
· Length：表示数据域的长度，也就是Packet Body字段的长度，单位为字节。当EAPOL数据帧的类型为EAPOL-Start或EAPOL-Logoff时，该字段值为0，表示后面没有Packet Body字段。
· Packet Body：数据域的内容。
(2) EAP报文的格式
当EAPOL数据帧的类型为EAP-Packet时，Packet Body字段的内容就是一个EAP报文，格式如图1-6所示。
图1-6 EAP报文格式
· Code：EAP报文的类型，包括Request（1）、Response（2）、Success（3）和Failure（4）。
· Identifier：用于匹配Request消息和Response消息的标识符。
· Length：EAP报文的长度，包含Code、Identifier、Length和Data域，单位为字节。
· Data：EAP报文的内容，该字段仅在EAP报文的类型为Request和Response时存在，它由类型域和类型数据两部分组成，例如，类型域为1表示Identity类型，类型域为4表示MD5 challenge类型。
RADIUS为支持EAP认证增加了两个属性：EAP-Message（EAP消息）和Message-Authenticator（消息认证码）。在含有EAP-Message属性的数据包中，必须同时包含Message-Authenticator属性。关于RADIUS报文格式的介绍请参见“安全配置指导”中的“AAA”的RADIUS协议简介部分。
如图1-7所示，EAP-Message属性用来封装EAP报文，Value域最长253字节，如果EAP报文长度大于253字节，可以对其进行分片，依次封装在多个EAP-Message属性中。
图1-7 EAP-Message属性封装
如图1-8所示，Message-Authenticator属性用于在EAP认证过程中验证携带了EAP-Message属性的RADIUS报文的完整性，避免报文被窜改。如果接收端对接收到的RADIUS报文计算出的完整性校验值与报文中携带的Message-Authenticator属性的Value值不一致，该报文会被认为无效而丢弃。
图1-8 Message-Authenticator属性封装
802.1X的认证过程可以由客户端主动发起，也可以由设备端发起。
· 组播触发：客户端主动向设备端发送EAPOL-Start报文来触发认证，该报文目的地址为组播MAC地址01-80-C2-00-00-03。
· 广播触发：客户端主动向设备端发送EAPOL-Start报文来触发认证，该报文的目的地址为广播MAC地址。该方式可解决由于网络中有些设备不支持上述的组播报文，而造成认证设备无法收到客户端认证请求的问题。
目前，iNode的802.1X客户端可支持广播触发方式。
设备端主动触发方式用于支持不能主动发送EAPOL-Start报文的客户端，例如Windows XP自带的802.1X客户端。设备主动触发认证的方式分为以下两种：
· 组播触发：设备每隔N秒（缺省为30秒）主动向客户端组播发送Identity类型的EAP-Request帧来触发认证。
· 单播触发：当设备收到源MAC地址未知的报文时，主动向该MAC地址单播发送Identity类型的EAP-Request帧来触发认证。若设备端在设置的时长内没有收到客户端的响应，则重发该报文。
802.1X系统支持采用EAP中继方式或EAP终结方式与远端RADIUS服务器交互。以下关于两种认证方式的过程描述，都以客户端主动发起认证为例。
这种方式是IEEE 802.1X标准规定的，将EAP承载在其它高层协议中，如EAP over RADIUS，以便扩展认证协议报文穿越复杂的网络到达认证服务器。一般来说，需要RADIUS服务器支持EAP属性：EAP-Message和Message-Authenticator，分别用来封装EAP报文及对携带EAP-Message的RADIUS报文进行保护。
下面以MD5-Challenge认证方法为例介绍基本业务流程，认证过程如图1-9所示。
图1-9 IEEE 802.1X认证系统的EAP中继方式业务流程
(1) 当用户需要访问外部网络时打开802.1X客户端程序，输入已经申请、登记过的用户名和密码，发起连接请求。此时，客户端程序将向设备端发出认证请求帧（EAPOL-Start），开始启动一次认证过程。
(2) 设备端收到认证请求帧后，将发出一个Identity类型的请求帧（EAP-Request/Identity）要求用户的客户端程序发送输入的用户名。
(3) 客户端程序响应设备端发出的请求，将用户名信息通过Identity类型的响应帧（EAP-Response/Identity）发送给设备端。
(4) 设备端将客户端发送的响应帧中的EAP报文封装在RADIUS报文（RADIUS Access-Request）中发送给认证服务器进行处理。
(5) RADIUS服务器收到设备端转发的用户名信息后，将该信息与数据库中的用户名列表中对比，找到该用户名对应的密码信息，用随机生成的一个MD5 Challenge对密码进行加密处理，同时将此MD5 Challenge通过RADIUS Access-Challenge报文发送给设备端。
(6) 设备端将RADIUS服务器发送的MD5 Challenge转发给客户端。
(7) 客户端收到由设备端传来的MD5 Challenge后，用该Challenge对密码部分进行加密处理，生成EAP-Response/MD5 Challenge报文，并发送给设备端。
(8) 设备端将此EAP-Response/MD5 Challenge报文封装在RADIUS报文（RADIUS Access-Request）中发送给RADIUS服务器。
(9) RADIUS服务器将收到的已加密的密码信息和本地经过加密运算后的密码信息进行对比，如果相同，则认为该用户为合法用户，并向设备端发送认证通过报文（RADIUS Access-Accept）。
(10) 设备收到认证通过报文后向客户端发送认证成功帧（EAP-Success），并将端口改为授权状态，允许用户通过端口访问网络。
(11) 用户在线期间，设备端会通过向客户端定期发送握手报文的方法，对用户的在线情况进行监测。
(12) 客户端收到握手报文后，向设备发送应答报文，表示用户仍然在线。缺省情况下，若设备端发送的两次握手请求报文都未得到客户端应答，设备端就会让用户下线，防止用户因为异常原因下线而设备无法感知。
(13) 客户端可以发送EAPOL-Logoff帧给设备端，主动要求下线。
(14) 设备端把端口状态从授权状态改变成未授权状态，并向客户端发送EAP-Failure报文。
EAP中继方式下，需要保证在客户端和RADIUS服务器上选择一致的EAP认证方法，而在设备上，只需要通过dot1x authentication-method eap命令启动EAP中继方式即可。
这种方式将EAP报文在设备端终结并映射到RADIUS报文中，利用标准RADIUS协议完成认证、授权和计费。设备端与RADIUS服务器之间可以采用PAP或者CHAP认证方法。下面以CHAP认证方法为例介绍基本业务流程，如图1-10所示。
图1-10 IEEE 802.1X认证系统的EAP终结方式业务流程
EAP终结方式与EAP中继方式的认证流程相比，不同之处在于步骤(4)中用来对用户密码信息进行加密处理的MD5 challenge由设备端生成，之后设备端会把用户名、MD5 challenge和客户端加密后的密码信息一起送给RADIUS服务器，进行相关的认证处理。
设备不仅支持协议所规定的基于端口的接入认证方式（Port-based），还对其进行了扩展、优化，支持基于MAC的接入控制方式（MAC-based）。
· 当采用基于端口的接入控制方式时，只要该端口下的第一个用户认证成功后，其它接入用户无须认证就可使用网络资源，但是当第一个用户下线后，其它用户也会被拒绝使用网络。
· 采用基于MAC的接入控制方式时，该端口下的所有接入用户均需要单独认证，当某个用户下线时，也只有该用户无法使用网络。
本特性的支持情况与设备的型号有关，请参见“配置指导导读”的“特性差异情况”部分的介绍。
目前，无线接口上支持802.1X双机热备功能，即支持对互为备份的两台设备的无线接口接入的802.1X用户信息进行热备，以实现在设备进行主备切换时，备份设备能够立即接管当前802.1X在线用户，保证用户能够正常通信，数据流不中断。802.1X的双机热备是通过端口安全的双机热备功能来实现的，详细介绍及配置请参见“安全配置指导”中的“端口安全”。
802.1X用户在服务器上通过认证时，服务器会把授权信息传送给设备端。如果服务器上指定了授权给该用户的下发VLAN，则服务器发送给设备的授权信息中将含有下发的VLAN信息，设备根据用户认证上线的端口链路类型，按以下三种情况将端口加入下发VLAN中。
|
Access端口 |
Trunk端口 |
Hybrid端口 |
|
|
端口离开用户配置的VLAN，加入下发的VLAN |
端口允许下发的VLAN通过，并且将缺省VLAN修改为下发的VLAN |
端口允许下发的VLAN以不携带Tag的方式通过，并且将缺省VLAN修改为下发的VLAN |
|
|
端口离开用户配置的VLAN，加入第一个通过认证的用户的下发VLAN |
端口允许下发的VLAN通过，并且将缺省VLAN修改为第一个通过认证的用户的下发VLAN |
端口允许下发的VLAN以不携带Tag的方式通过 · 若端口上开启了MAC VLAN功能，则根据下发的VLAN动态地创建基于用户MAC的VLAN，而端口的缺省VLAN ID并不改变 · 若端口上未开启MAC VLAN功能，则端口的缺省VLAN ID修改为第一个通过认证的用户的下发VLAN的VLAN ID |
|
|
说明：只有开启了MAC VLAN功能的端口上才允许给不同的用户MAC下发不同的VLAN。其它情况下，下发给所有用户的VLAN必须相同，否则仅第一个通过认证的用户的可以认证成功。 |
|||
下发的VLAN并不影响端口的配置。但是，下发的VLAN的优先级高于用户配置的VLAN，即通过认证后起作用的VLAN是下发的VLAN，用户配置的VLAN在用户下线后生效。
· 对于Hybrid端口，不建议把服务器将要下发或已经下发的VLAN配置为携带Tag的方式加入端口。
· 在启动了802.1X周期性重认证功能的Hybrid端口上，若用户在MAC VLAN功能开启之前上线，则MAC VLAN功能不能对该用户生效，即系统不会根据服务器下发的VLAN生成该用户的MAC VLAN表项，只有该在线用户重认证成功且服务器下发的VLAN发生变化时，MAC VLAN功能才会对它生效。MAC VLAN功能的详细介绍请参考“二层技术配置指导”中的“VLAN”。
目前，仅接入控制方式为MAC-based的端口支持Guest VLAN，接入控制方式为Port-based的端口暂不支持Guest VLAN。
Guest VLAN功能允许用户在未认证的情况下，访问某一特定VLAN中的资源。这个特定的VLAN称之为Guest VLAN，该VLAN内通常放置一些用于用户下载客户端软件或其他升级程序的服务器。
在接入控制方式为MAC-based的端口上配置Guest VLAN后，端口上未认证的用户被授权访问Guest VLAN里的资源。
· 当端口上处于Guest VLAN中的用户发起认证且失败时，如果端口配置了Auth-Fail VLAN，则认证失败的用户将被加入Auth-Fail VLAN；如果端口未配置Auth-Fail VLAN，则该用户将仍然处于Guest VLAN内；
· 当端口上处于Guest VLAN中的用户发起认证且成功时，设备会根据认证服务器是否下发VLAN决定将该用户加入到下发的VLAN中，或回到加入Guest VLAN之前端口所在的初始VLAN。
目前，仅接入控制方式为MAC-based的端口支持Auth-Fail VLAN，接入控制方式为Port-based的端口暂不支持Auth-Fail VLAN。
Auth-Fail VLAN功能允许用户在认证失败的情况下访问某一特定VLAN中的资源，这个VLAN称之为Auth-Fail VLAN。需要注意的是，这里的认证失败是认证服务器因某种原因明确拒绝用户认证通过，比如用户密码错误，而不是认证超时或网络连接等原因造成的认证失败。
在接入控制方式为MAC-based的端口上配置Auth-Fail VLAN后，该端口上认证失败的用户将被授权访问Auth-Fail VLAN里的资源。
当Auth-Fail VLAN中的用户再次发起认证时：
· 如果认证成功，则设备会根据认证服务器是否下发VLAN决定将该用户加入到下发的VLAN中，或回到加入Auth-Fail VLAN之前端口所在的初始VLAN；
· 如果认证失败，则该用户仍然留在该VLAN中。
802.1X支持ACL（Access Control List，访问控制列表）下发功能提供了对上线用户访问网络资源的过滤与控制功能。当用户上线时，如果RADIUS服务器上指定了要下发给该用户的授权ACL，则设备会根据服务器下发的授权ACL对用户所在端口的数据流进行过滤，仅允许ACL规则中允许的数据流通过该端口。由于服务器上指定的是授权ACL的编号，因此还需要在设备上创建该ACL并配置该对应的ACL规则。管理员可以通过改变服务器的授权ACL设置或设备上对应的ACL规则来改变用户的访问权限。
表1-3 802.1X配置任务简介
|
开启802.1X特性 |
无线端口的802.1X特性需要配合端口安全特性使用，缺省情况下并没有开启802.1X特性 |
|
|
配置802.1X系统的认证方法 |
若采用EAP中继模式，则必选 若采用EAP终结模式，则可选 |
|
|
配置802.1X认证超时定时器 |
||
|
配置Guest VLAN |
||
|
配置802.1X支持的域名分隔符 |
使用802.1X认证时建议关闭arp-snooping功能。
802.1X需要AAA的配合才能实现对用户的身份认证。因此，需要首先完成以下配置任务：
· 配置802.1X用户所属的ISP认证域及其使用的AAA方案，即本地认证方案或RADIUS方案。
· 如果需要通过RADIUS服务器进行认证，则应该在RADIUS服务器上配置相应的用户名和密码。
· 如果需要本地认证，则应该在设备上手动添加认证的用户名和密码。配置本地认证时，用户使用的服务类型必须设置为lan-access。
在RADIUS服务器不能支持EAP认证，或者使用本地认证的情况下，如果希望使用EAP中继模式来支持多种EAP认证方法，则还需要在设备上配置专门的本地EAP服务器来协助完成EAP认证。关于本地EAP认证以及AAA的具体配置请参见“安全配置指导”中的“AAA”。
设备上的802.1X系统采用的认证方法与设备对于EAP报文的处理机制有关，具体如下：
· EAP中继方式下，设备端对客户端发送的EAP报文进行中继处理，设备上需指定authentication-method为eap来启用EAP中继方式，并支持客户端与RADIUS服务器之间所有类型的EAP认证方法。
· EAP终结方式下，设备端对客户端发送的EAP报文进行本地终结，设备上需指定authentication-method为chap或pap来启用EAP终结方式，并支持与RADIUS服务器之间采用CHAP或PAP类型的认证方法。
表1-4 配置802.1X系统的认证方法
|
配置802.1X系统的认证方法 |
缺省情况下，设备启用EAP终结方式，并采用CHAP认证方法 |
如果采用EAP中继认证方式，则设备会把客户端输入的内容直接封装后发给服务器，这种情况下user-name-format命令的设置无效，user-name-format的介绍请参见“安全命令参考”中的“AAA”。
通过配置端口的授权状态，可以控制端口上接入的用户是否需要经过认证来访问网络资源。端口支持以下三种授权状态：
· 强制授权（authorized-force）：表示端口始终处于授权状态，允许用户不经认证即可访问网络资源。
· 强制非授权（unauthorized-force）：表示端口始终处于非授权状态，不允许用户进行认证。设备端不为通过该端口接入的客户端提供认证服务。
· 自动识别（auto）：表示端口初始状态为非授权状态，仅允许EAPOL报文收发，不允许用户访问网络资源；如果认证通过，则端口切换到授权状态，允许用户访问网络资源。这也是最常见的情况。
在系统视图和接口视图下均可进行端口授权状态的配置，前者可针对多个端口，后者仅针对当前端口。若在不同视图下先后对同一个端口的授权状态进行了配置，则最后执行的配置生效。
设备支持两种端口接入控制方式：基于端口控制（portbased）和基于MAC控制（macbased）。
在系统视图和接口视图下均可进行端口接入控制方式的配置，前者可针对多个端口，后者仅针对当前端口。若在不同视图下先后对同一个端口的接入控制方式进行了配置，则最后执行的配置生效。
|
dot1x port-method { macbased | portbased } [ interface interface-list ] |
缺省情况下，802.1X在端口上进行接入控制方式为macbased |
||
|
在二层以太网接口视图/WLAN-ESS接口视图下 |
interface interface-type interface-number |
||
|
dot1x port-method { macbased | portbased } |
|||
若端口上同时启动了802.1X和Portal认证功能，则端口接入控制方式必须为macbased。关于Portal认证的相关介绍，请参考“安全配置指导”中的“Portal”。
在系统视图和接口视图下均可进行端口接入用户数最大值的配置，前者可针对多个端口，后者仅针对当前端口。若在不同视图下先后对同一个端口的最大接入用户数进行了配置，则最后执行的配置生效。
|
在二层以太网接口视图/WLAN-ESS接口视图下 |
interface interface-type interface-number |
||
如果设备向用户发送认证请求报文后，在规定的时间里（可通过命令dot1x timer tx-period或者dot1x timer supp-timeout设定）没有收到用户的响应，则设备将向用户重发该认证请求报文，若设备累计发送认证请求报文的次数达到配置的最大值后，仍然没有得到用户响应，则停止发送认证请求。
|
dot1x retry max-retry-value |
缺省情况下，设备最多可向接入用户发送2次认证请求报文 |
802.1X认证过程中会启动多个定时器以控制接入用户、设备以及RADIUS服务器之间进行合理、有序的交互。可配置的802.1X认证定时器包括以下两种：
· 客户端认证超时定时器：当设备端向客户端发送了EAP-Request/MD5 Challenge请求报文后，设备端启动此定时器，若在该定时器设置的时长内，设备端没有收到客户端的响应，设备端将重发该报文。
· 认证服务器超时定时器：当设备端向认证服务器发送了RADIUS Access-Request请求报文后，设备端启动该定时器，若在该定时器设置的时长内，设备端没有收到认证服务器的响应，设备端将重发认证请求报文。
表1-9 配置802.1X定时器参数
开启设备的在线用户握手功能后，设备会定期（时间间隔通过命令dot1x timer handshake-period设置）向通过802.1X认证的在线用户发送握手报文，以定期检测用户的在线情况。如果设备连续多次（通过命令dot1x retry设置）没有收到客户端的响应报文，则会将用户置为下线状态。
在线用户握手功能处于开启状态的前提下，还可以通过开启在线用户握手安全功能，来防止在线的802.1X认证用户使用非法的客户端与设备进行握手报文的交互，而逃过双网卡检测等iNode客户端的安全检查功能。开启了在线用户握手安全功能的设备通过检验客户端上传的握手报文中携带的验证信息，来确认用户是否使用iNode客户端进行握手报文的交互。如果握手检验不通过，则会将用户置为下线状态。
需要注意的是：在线用户握手安全功能的实现依赖于在线用户握手功能。为使在线用户握手安全功能生效，请保证在线用户握手功能处于开启状态。
|
interface interface-type interface-number |
||
· 部分802.1X客户端不支持与设备进行握手报文的交互，因此建议在这种情况下，关闭设备的在线用户握手功能，避免该类型的在线用户因没有回应握手报文而被强制下线。
· 建议在线用户握手安全功能与iNode客户端以及iMC服务器配合使用，以保证该功能可以正常运行。
端口上开启认证触发功能后，设备会主动向该端口上的客户端发送认证请求来触发认证，以支持不能主动发送EAPOL-Start报文来发起认证的客户端。设备提供了以下两种类型的认证触发功能：
· 组播触发功能：启用了该功能的端口会定期（间隔时间通过命令dot1x timer tx-period设置）向客户端组播发送EAP-Request/Identity报文来检测客户端并触发认证。该功能用于支持不能主动发起认证的客户端。
· 单播触发功能：当启用了该功能的端口收到源MAC地址未知的报文时，会主动向该MAC地址单播发送EAP-Request/Identity报文，若端口在指定的时间内（通过命令dot1x timer tx-period设置）没有收到客户端的响应，则重发该报文（重发次数通过命令dot1x retry设置）。该功能适用于客户端不支持主动认证，且仅部分客户端需要进行认证的组网环境，可避免不希望认证或已认证的客户端收到多余的认证触发报文。
|
interface interface-type interface-number |
||
· 对于无线局域网来说，可以由客户端主动发起认证，或由无线模块发现用户并触发认证，而不必端口定期发送802.1X的组播报文来触发。同时，组播触发报文会占用无线的通信带宽，因此建议无线局域网中的接入设备关闭该功能。
配置端口的强制认证域（mandatory domain）为802.1X接入提供了一种安全控制策略。所有从该端口接入的802.1X用户将被强制使用指定的认证域来进行认证、授权和计费，从而防止用户通过恶意假冒其它域账号从本端口接入网络。另外，管理员也可以通过配置强制认证域对不同端口接入的用户指定不同的认证域，从而增加了管理员部署802.1X接入策略的灵活性。
|
interface interface-type interface-number |
||
当802.1X用户认证失败以后，设备需要静默一段时间（通过命令dot1x timer quiet-period设置）后再重新发起认证，在静默期间，设备不进行802.1X认证的相关处理。
端口启动了802.1X的周期性重认证功能后，设备会根据周期性重认证定时器设定的时间间隔（由命令dot1x timer reauth-period设置）定期向该端口在线802.1X用户发起重认证，以检测用户连接状态的变化、确保用户的正常在线，并及时更新服务器下发的授权属性（例如ACL、VLAN、User Profile）。
|
interface interface-type interface-number |
||
|
dot1x re-authenticate |
· 认证服务器可以通过下发RADIUS属性（session-timeout）来指定用户的重认证周期，且该功能不需要设备上开启周期性重认证功能来配合，属性下发成功即可生效。802.1X用户认证通过后，如果认证服务器对该用户下发了重认证周期，则设备上配置的周期性重认证时间无效，服务器下发的重认证周期生效。认证服务器下发重认证时间的具体配置以及是否可以下发重认证周期的情况与服务器类型有关，请参考具体的认证服务器实现。
· 在用户名不改变的情况下，端口允许重认证前后服务器向该用户下发不同内容的VLAN；但是，若重认证前端口下发了VLAN，而重认证后未下发VLAN，则重认证失败，用户下线，反之同样处理。
· 当端口向在线的802.1X用户发起重认证或者重认证过程中发现没有可达的服务器时，则在线用户将会下线。
· 如果用户端设备发出的是携带Tag的数据流，且接入端口上使能了802.1X认证并配置了Guest VLAN，为保证各种功能的正常使用，请为端口的缺省VLAN和802.1X的Guest VLAN分配不同的VLAN ID。
· 接入控制方式为MAC-based的端口上支持Guest VLAN，接入控制方式为Port-based的端口暂不支持Guest VLAN。
配置Guest VLAN之前，需要进行以下配置准备：
· 创建需要配置为Guest VLAN的VLAN。
· 在接入控制方式为MAC-based的端口上，保证端口类型为Hybrid，端口上的MAC VLAN功能处于使能状态，且不建议将指定的Guest VLAN修改为携带Tag的方式。MAC VLAN功能的具体配置请参考“二层技术配置指导”中的“VLAN”。
|
不同的端口可以配置不同的Guest VLAN，但一个端口最多只能配置一个Guest VLAN |
|||
|
在二层以太网接口视图/WLAN-ESS接口视图下 |
|||
· 在接入控制方式为MAC-based的端口上同时配置了802.1X认证的Guest VLAN与MAC地址认证的Guest VLAN时，则仅802.1X认证的Guest VLAN有效，即用户触发MAC地址认证且失败后，不会加入MAC地址认证的Guest VLAN，若之后未触发或者未成功通过802.1X认证，则会加入802.1X认证的Guest VLAN中（若端口上还配置了802.1X认证的Auth-Fail VLAN，则用户认证失败后加入Auth-Fail VLAN）。关于MAC地址认证Guest VLAN的介绍请参见“安全配置指导”中的“MAC地址认证”。
· 在接入控制方式为MAC-based的端口上生成的Guest VLAN表项会覆盖已生成的阻塞MAC表项，但如果端口因检测到非法报文而关闭，则802.1X的Guest VLAN功能无法生效。关于端口入侵检测关闭功能的具体介绍请参见“安全配置指导”中的“端口安全”。
· 如果用户端设备发出的是携带Tag的数据流，且接入端口上使能了802.1X认证并配置了Auth-Fail VLAN，为保证各种功能的正常使用，请为端口的缺省VLAN和802.1X的Auth-Fail VLAN分配不同的VLAN ID。
· 接入控制方式为MAC-based的端口支持Auth-Fail VLAN，接入控制方式为Port-based的端口暂不支持Auth-Fail VLAN。
配置Auth-Fail VLAN之前，需要进行以下配置准备：
· 创建需要配置为Auth-Fail VLAN的VLAN。
· 在接入控制方式为MAC-based的端口上，保证端口类型为Hybrid，端口上的MAC VLAN功能处于使能状态，且不建议将指定的Auth-Fail VLAN修改为携带Tag的方式。MAC VLAN功能的具体配置请参考“二层技术配置指导”中的“VLAN”。
|
不同的端口可以配置不同的Auth-Fail VLAN，但一个端口最多只能配置一个Auth-Fail VLAN |
· 在接入控制方式为MAC-based的端口上同时配置了802.1X认证Auth-Fail VLAN与MAC地址认证的Guest VLAN时，若用户首先进行MAC地址认证且失败，则加入MAC地址认证的Guest VLAN中，之后若该用户再进行802.1X认证且失败，则会离开MAC地址认证的Guest VLAN而加入802.1X认证的Auth-Fail VLAN中；若用户首先进行802.1X认证且失败，之后除非成功通过MAC地址认证或者802.1X认证，否则会一直位于802.1X认证的Auth-Fail VLAN中。
· 在接入控制方式为MAC-based的端口上生成的Auth-Fail VLAN表项会覆盖已生成的阻塞MAC表项，但如果端口因检测到非法报文而关闭，则802.1X的Auth-Fail VLAN功能无法生效。关于端口入侵检测关闭功能的具体介绍请参见“安全配置指导”中的“端口安全”。
设备对用户的管理是基于ISP域的，每个接入用户都属于一个ISP域。用户所属的ISP域是由用户登录时提供的用户名决定的，若用户名中携带域名，则设备使用该域中的AAA配置对用户进行认证、授权和计费，否则使用系统中的缺省域；若设备指定了802.1X的强制认证域，则无论用户名中是否携带域名，设备均使用指定的强制认证域。因此，设备能够准确解析用户名中的纯用户名和域名对于为用户提供认证服务非常重要。由于不同的802.1X客户端所支持的用户名域名分隔符不同，为了更好地管理和控制不同用户名格式的802.1X用户接入，需要在设备上指定802.1X可支持的域名分隔符。
目前，802.1X支持的域名分隔符包括@、\和/，对应的用户名格式分别为username@domain-name， domain-name\username和username/domain-name，其中username为纯用户名、domain-name为域名。如果用户名中包含有多个域名分隔符字符，则设备仅将第一个出现的域名分隔符识别为实际使用的域名分隔符，其它字符都被认为是域名中的一部分，例如，用户输入的用户名为123/22\@abc，则认为纯用户名为123，域名分隔符为/，域名为22\@abc。
如果用户输入的用户名中不包含任何802.1X可支持的域名分隔符，则设备会认为该用户名并未携带域名，则使用系统中的缺省域对该用户进行认证。
表1-17 指定802.1X支持的域名分隔符
|
指定802.1X支持的域名分隔符 |
dot1x domain-delimiter string |
若设备上指定发送给认证服务器的用户名携带域名（user-name-format with-domain），则发送给认证服务器的用户名中携带该用户输入的域名（若原始用户名携带域名），或携带最终使用的认证域的域名（若原始用户名未携带域名），并采用设备上指定的802.1X支持的域名分隔符，若设备上指定了多个域名分隔符，则选择的优先级由高到低依次为@、/、\。另外，为保证用户信息可在认证服务器上被准确匹配到，设备上指定的802.1X支持的域名分隔符必须与认证服务器支持的域名分隔符保持一致，否则可能会因为服务器匹配用户失败而导致用户认证失败。相关命令的具体介绍请参考“安全命令参考”中的“AAA”。
由于H3C iNode客户端具有上传用户IP地址的功能，因此不建议在接入H3C iNode客户端的端口上使能该功能。如果需要与H3C iNode客户端配合使用，建议配置的计费延时时间不大于20秒或者不启用EAD安全策略，否则用户有可能无法上线。
缺省情况下，计费延时功能处于关闭状态，用户认证成功后设备无论能否获取到用户的IP地址，都会立即向计费服务器发起计费请求。若该计费请求报文中携带了用户IP地址，则计费服务器将记录下用户的IP地址，该IP地址可用于管理用户的资费信息；若该计费请求报文中没有携带用户的IP地址，则计费服务器无法记录用户的IP地址。
如果开启了计费延时功能，则设备仅在获取到用户IP地址后才向计费服务器发送用户的计费请求报文，如果在指定的计费延时时间之内没有获取到用户的IP地址，则根据配置的计费延时动作来决定用户能否继续后续的计费流程。
若用户通过DHCP动态获取IP地址，且计费服务器要求记录用户IP地址时，建议开启该功能，确保设备在获取到用户的IP地址之后，将用户IP地址发送给计费服务器。
在完成上述配置后，在任意视图下执行display命令可以显示配置后802.1X的运行情况，通过查看显示信息验证配置的效果。
在用户视图下，执行reset命令可以清除802.1X的统计信息。
表1-19 802.1X显示和维护
|
显示802.1X的会话连接信息、相关统计信息或配置信息 |
display dot1x [ sessions | statistics ] [ interface interface-list ] [ | { begin | exclude | include } regular-expression ] |
|
显示802.1X的双机热备信息 |
display dot1x synchronization { connection | statistics | status } [ interface interface-type interface-number ] [ | { begin | exclude | include } regular-expression ] |
|
清除802.1X的统计信息 |
reset dot1x statistics [ interface interface-list ] |
|
清除802.1X双机热备报文统计信息 |
reset dot1x synchronization statistics [ interface interface-type interface-number ] |
有关802.1X认证的配置举例，请参见“WLAN配置指导”中的“WLAN安全”。
如图1-11所示，无线用户Client通过802.1X认证接入网络，认证服务器为RADIUS服务器。Internet网络中有一台FTP服务器，IP地址为10.0.0.1。
· 在认证服务器上配置授权下发ACL 3000。
· 在无线控制器的WLAN-ESS1上开启802.1X认证（userlogin-secure-ext模式），并配置ACL 3000。
当无线用户认证成功上线，认证服务器下发ACL 3000。此时ACL 3000在WLAN-ESS1上生效，Client可以访问Internet，但不能访问FTP服务器。
图1-11 下发ACL典型组网图
(1) 在AC上配置ACL下发
# 配置各接口的IP地址（略）。
# 配置RADIUS服务器并下发相应ACL（略）。
# 配置RADIUS方案。
[AC] radius scheme 2000
[AC-radius-2000] primary authentication 10.1.1.1
[AC-radius-2000] primary accounting 10.1.1.2
[AC-radius-2000] key authentication abc
[AC-radius-2000] key accounting abc
[AC-radius-2000] user-name-format without-domain
[AC-radius-2000] quit
# 配置ISP域的AAA方案。
[AC-isp-2000] authentication default radius-scheme 2000
[AC-isp-2000] authorization default radius-scheme 2000
[AC-isp-2000] accounting default radius-scheme 2000
[AC-isp-2000] quit
# 配置ACL 3000，拒绝目的IP地址为10.0.0.1的报文通过。
[AC-acl-adv-3000] rule 0 deny ip destination 10.0.0.1 0
# 设置认证方式为EAP。
[AC] dot1x authentication-method eap
# 全局开启端口安全。
# 配置无线端口安全，使用802.1X认证方式。
[AC-WLAN-ESS1] port link-type hybrid
[AC-WLAN-ESS1] port hybrid vlan 2 untagged
[AC-WLAN-ESS1] port hybrid pvid vlan 2
[AC-WLAN-ESS1] mac-vlan enable
[AC-WLAN-ESS1] port-security port-mode userlogin-secure-ext
[AC-WLAN-ESS1] port-security tx-key-type 11key
[AC-WLAN-ESS1] dot1x mandatory-domain 2000
# 关闭802.1X多播触发功能和在线用户握手功能。
[AC-WLAN-ESS1] undo dot1x multicast-trigger
[AC-WLAN-ESS1] undo dot1x handshake
[AC-WLAN-ESS1] quit
# 创建服务模板1（加密类型服务模板），配置SSID为dot1x，加密方式为tkip和ccmp。
[AC] wlan service-template 1 crypto
[AC-wlan-st-1] ssid dot1x
[AC-wlan-st-1] bind wlan-ess 1
[AC-wlan-st-1] cipher-suite tkip
[AC-wlan-st-1] cipher-suite ccmp
[AC-wlan-st-1] security-ie rsn
[AC-wlan-st-1] service-template enable
[AC-wlan-st-1] quit
# 配置AP：创建AP的模板，名称为ap1，型号名称选择WA3628i-AGN，并配置AP的序列号为210235A29G007C000020。
[AC] wlan ap ap1 model WA3628i-AGN
[AC-wlan-ap-ap1] serial-id 210235A29G007C000020
[AC-wlan-ap-ap1] radio 1 type dot11an
# 将服务模板1绑定到AP的radio 1口。
[AC-wlan-ap-ap1-radio-1] service-template 1
[AC-wlan-ap-ap1-radio-1] radio enable
用户认证上线后，使用display connection命令查看802.1X认证授权信息，显示用户已认证成功，ACL3000也下发成功。
Index=1,Username=localuser@2000
MAC=00-40-96-B3-8A-77
IP=192.168.1.10
IPv6=N/A
Online=00h00m53s
Total 1 connection(s) matched.
[AC]display connection ucibindex 1
Index=1, Username= localuser@2000
MAC=00-40-96-B3-8A-77
IP=192.168.1.10
IPv6=N/A
Access=8021X ,AuthMethod=EAP
Port Type=Wireless-802.11,Port Name=WLAN-DBSS1:1
Initial VLAN=2, Authorization VLAN=N/A
ACL Group=3000
User Profile=N/A
CAR=Disable
InputOctets =12121212 OutputOctets =12120
InputGigawords=1 OutputGigawords=0
Priority=Disable
SessionTimeout=86236(s), Terminate-Action=Default
Start=2013-06-30 17:29:39 ,Current=2013-06-30 17:30:51 ,Online=00h01m13s
Total 1 connection matched.
Pinging 10.0.0.1 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 10.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
由以上过程可知，无线用户无法ping通FTP服务器，说明认证服务器下发的ACL已对该用户生效。
不同款型规格的资料略有差异, 详细信息请向具体销售和400咨询。H3C保留在没有任何通知或提示的情况下对资料内容进行修改的权利!
支持
售前咨询
售后咨询
人工在线咨询
