802.1X原理及测试.doc

802.1X原理及测试Page 36 of 36目 录第一章802.1X简介41.1引言41.2802.1X认证体系41.3802.1X认证流程5第二章802.1X协议介绍72.1802.1X协议的工作机制72.2协议实现内容92.3典型应用的拓扑结构11第三章实验拓扑及抓包133.1TL-SL3226P实验拓扑及认证软件133.2TL-SL3226P认证过程抓包分析143.3H3C S5100认证实验193.4TL-SL3226P与H3C S5100的比较29第四章802.1X功能测试314.1认证发起测试314.2退出认证测试324.3多客户端认证测试324.4端口认证方式测试334.5Guest VLAN测试344.6时间参数测试35第一章 802.1X简介1.1 引言802.1X协议起源于802.11协议，后者是IEEE的无线局域网协议，制订802.1X协议的初衷是为了解决无线局域网用户的接入认证问题。 IEEE802LAN协议定义的局域网并不提供接入认证，只要用户能接入局域网控制设备(如LANS witch)，就可以访问局域网中的设备或资源。这在早期企业网有线LAN应用环境下并不存在明显的安全隐患。 随着移动办公及驻地网运营等应用的大规模发展，服务提供者需要对用户的接入进行控制和配置。尤其是WLAN的应用和LAN接入在电信网上大规模开展，有必要对端口加以控制 以实现用户级的接入控制，802.1X就是IEEE为了解决基于端口的接入控制(Port-Based Network Access Control)而定义的一个标准。1.2 802.1X认证体系802.1X是一种基于端口的认证协议，是一种对用户进行认证的方法和策略。端口可以是一个物理端口，也可以是一个逻辑端口(如VLAN)。对于无线局域网来说，一个端口就是一个信道。802.1X认证的最终目的就是确定一个端口是否可用。对于一个端口，如果认证成功那么就“打开”这个端口，允许所有的报文通过；如果认证不成功就使这个端口保持“关闭”，即只允许802.1X的认证协议报文通过。 802.1X的体系结构如图1所示。它的体系结构中包括三个部分，即请求者系统、认证系统和认证服务器系统三部分：图1 802.1X认证的体系结构1.请求者系统 请求者是位于局域网链路一端的实体，由连接到该链路另一端的认证系统对其进行认证。请求者通常是支持802.1X认证的用户终端设备，用户通过启动客户端软件发起802.1X认证，后文的认证请求者和客户端二者表达相同含义。 2.认证系统 认证系统对连接到链路对端的认证请求者进行认证。认证系统通常为支持802.1X协议的网络设备，它为请求者提供服务端口，该端口可以是物理端口也可以是逻辑端口，一般在用户接入设备(如LAN Switch和AP)上实现802.1X认证。后文的认证系统、认证点和接入设备三者表达相同含义。 3.认证服务器系统 认证服务器是为认证系统提供认证服务的实体，建议使用RADIUS服务器来实现认证服务器的认证和授权功能。 请求者和认证系统之间运行802.1X定义的EAPOL (Extensible Authentication Protocol over LAN)协议。当认证系统工作于中继方式时，认证系统与认证服务器之间也运行EAP协议，EAP帧中封装认证数据，将该协议承载在其它高层次协议中(如RADIUS)，以便穿越复杂的网络到达认证服务器；当认证系统工作于终结方式时，认证系统终结EAPOL消息，并转换为其它认证协议(如 RADIUS)，传递用户认证信息给认证服务器系统。 认证系统每个物理端口内部包含有受控端口和非受控端口。非受控端口始终处于双向连通状态，主要用来传递EAPOL协议帧，可随时保证接收认证请求者发出的EAPOL认证报文；受控端口只有在认证通过的状态下才打开，用于传递网络资源和服务。1.3 802.1X认证流程基于802.1X的认证系统在客户端和认证系统之间使用EAPOL格式封装EAP协议传送认证信息，认证系统与认证服务器之间通过RADIUS协议传送认证信息。由于EAP协议的可扩展性，基于EAP协议的认证系统可以使用多种不同的认证算法，如EAP-MD5，EAP-TLS，EAP-SIM，EAP -TTLS以及EAP-AKA等认证方法。 以EAP-MD5为例，描述802.1X的认证流程。EAP-MD5是一种单向认证机制，可以完成网络对用户的认证，但认证过程不支持加密密钥的生成。基于EAP- MD5的802.1X认证流程如图2所示，认证流程包括以下步骤：(1)客户端向接入设备发送一个EAPOL-Start报文，开始802.1X认证接入； (2)接入设备向客户端发送EAP-Request/Identity报文，要求客户端将用户名送上来； (3)客户端回应一个EAP-Response/Identity给接入设备的请求，其中包括用户名； (4)接入设备将EAP-Response/Identity报文封装到RADIUS Access-Request报文中，发送给认证服务器； (5)认证服务器产生一个Challenge，通过接入设备将RADIUS Access-Challenge报文发送给客户端，其中包含有EAP-Request/MD5-Challenge； (6)接入设备通过EAP-Request/MD5-Challenge发送给客户端，要求客户端进行认证； (7)客户端收到EAP-Request/MD5-Challenge报文后，将密码和Challenge做MD5算法后的Challenged-Pass-word，在EAP-Response/MD5-Challenge回应给接入设备； (8)接入设备将Challenge，Challenged Password和用户名一起送到RADIUS服务器，由RADIUS服务器进行认证；(9)RADIUS服务器根据用户信息，做MD5算法，判断用户是否合法，然后回应认证成功/失败报文到接入设备。如果成功，携带协商参数，以及用户的相关业务属性给用户授权。如果认证失败，则流程到此结束； (10)如果认证通过，用户通过标准的DHCP协议(可以是DHCP Relay)，通过接入设备获取规划的IP地址； (11)如果认证通过，接入设备发起计费开始请求给RADIUS用户认证服务器； (12)RADIUS用户认证服务器回应计费开始请求报文。用户上线完毕。图2 基于EAP-MD5的802.1X认证流程第二章 802.1X协议介绍802.1X定义了基于端口的网络接入控制协议，需要注意的是该协议仅适用于接入设备与接入端口间点到点的连接方式。为了在点到点链路上建立通信，在链路建立阶段PPP链路的每一端都必须首先发送LCP数据包来对该数据链路进行配置。在链路已经建立起来后，在进入网络层协议之前PPP提供一个可选的认证阶段，而EAPOL就是PPP的一个可扩展的认证协议。2.1 802.1X协议的工作机制802.1X作为一个认证协议，在实现的过程中有很多重要的工作机制。图3 802.1X协议的工作机制2.1.1 认证发起认证的发起可以由用户主动发起，也可以由认证系统发起。当认证系统探测到未经过认证的用户使用网络，就会主动发起认证；用户端则可以通过客户端软件向认证系统发送EAPOL-Start报文发起认证。1) 由认证系统发起的认证当认证系统检测到有未经认证的用户使用网络时，就会发起认证。在认证开始之前，端口的状态被强制为未认证状态。如果客户端的身份标识不可知，则认证系统会发送EAP-Request/Identity报文，请求客户端发送身份标识。这样，就开始了典型的认证过程。客户端在收到来自认证系统的EAP-Request报文后，将发送EAP-Response报文响应认证系统的请求。认证系统支持定期的重新认证，可以随时对一个端口发起重新认证的过程。如果端口状态为已认证状态，则当认证系统发起重新认证时，该端口通过认证，那么状态保持不便；如果未通过认证，则端口的状态改变为未认证状态2) 由客户端发起认证如果用户要上网，则可以通过客户端软件主动发起认证。客户端软件会向认证系统发送EAPOL-Start报文主动发起认证。认证系统在收到客户端发送的EAPOL-Start报文后，会发送EAP-Request/Identity报文响应用户请求，要求用户发送身份标识，这样就启动了一个认证过程。2.1.2 退出认证状态有几种方式可以造成认证系统把端口状态从已认证状态改变成未认证状态：a)客户端未通过认证服务器的认证；b)由于管理性的控制端口始终处于未认证状态，而不管是否通过认证；c)与端口对应的MAC地址出现故障（管理性禁止或硬件故障）；d)客户端与认证系统之间的连接失败，造成认证超时；e)重新认证超时；f)客户端未响应认证系统发起的认证请求；g)客户端发送EAPOL-Logoff报文，主动下线；退出已认证状态的直接结果就是导致用户下线，如果用户要继续上网则要再发起一个认证过程。为什么要专门提供一个EAPOL-Logoff机制，是处于如下安全的考虑：当一个用户从一台终端退出后，很可能其他用户不通过发起一个新的登录请求，就可以利用该设备访问网络。提供专门的退出机制，以确保用户与认证系统专有的会话进程被中止，可以防止用户的访问权限被他人盗用。通过发送EAPOL-Logoff报文，可以使认证系统将对应的端口状态改变为未认证状态。2.1.3 重新认证为了保证用户和认证系统之间的链路处于激活状态，而不因为用户端设备发生故障造成异常死机，从而影响对用户计费的准确性，认证系统可以定期发起重新认证过程，该过程对于用户是透明的，也即用户无需再次输入用户名/密码。重新认证由认证系统发起，时间是从最近一次成功认证后算起。重新认证可以激活或关闭。重新认证的时间由重认证超时参数控制，默认值为3600秒（一个小时）而且默认重新认证是关闭的。注意 重新认证的时间设定需要认真的规划，认证系统对端口进入的MAC地址的检测能力会影响到该时间的设定。如果对MAC地址的检测比较可靠，则重新认证时间可以设长一些。2.1.4 认证报文丢失重传对于认证系统和客户端之间通信的EAP报文，如果发生丢失，由认证系统负责进行报文的重传。在设定重传的时间时，考虑网络的实际环境，通常会认为认证系统和客户端之间报文丢失的几率比较低以及传送延迟低，因此一般通过一个超时计数器来设定，默认重传时间为30秒钟。对于有些报文的丢失重传比较特殊，如EAPOL-Star报文的丢失，由客户端负责重传；而对于EAP-Failure和EAP-Success报文，由于客户端无法识别，认证系统不会重传。由于对用户身份合法性的认证最终由认证服务器执行，认证系统和认证服务器之间的报文丢失重传也很重要。另外注意，对于用户的认证，在执行802.1X认证时，只有认证通过后，才有DHCP发起（如果配置为DHCP的自动获取） 和IP分配的过程。由于客户终端配置了DHCP自动获取，则可能在未启动802.1X客户端之前，就发起了DHCP的请求，而此时认证系统处于禁止通行状态，这样认证系统会丢掉初始化的DHCP帧，同时会触发认证系统发起对用户的认证。2.1.5 与不支持 802.1X 的设备的兼容对于从一个没有认证的系统过渡到认证系统，最理想的状态是希望能够平滑的进行过渡。由于802.1X协议是一个比较新的协议，如果应用在原有的旧网络中，则可能会存在与不支持设备的兼容性问题。如果客户端支持802.1X协议，而网络设备不支持（也就是没有认证系统），则客户端是不会收到认证系统响应的EAP-Request/Identity报文。在802.1X认证发起阶段，客户端首先发送EAPOL-Star报文到802.1X协议组申请的组播MAC地址，以查询网络上可以处理802.1X的设备（即认证系统），由于网络中没有设备充当认证系统，所以客户端是得不到响应的。因此客户端在发起多次连接请求无响应后，自动认为已经通过认证。如果客户端不支持802.1X协议，而网络中存在802.1X协议的认证系统，则客户端是不会响应认证系统发送的EAP-Request/Identity报文，因此端口会始终处于未认证状态。2.2 协议实现内容802.1X协议在实现整个安全认证的过程中，其三个关键部分（客户端、认证系统、认证服务器）之间是通过通信协议进行交互的，因此有必要对其相关的通信协议EAPOL做个介绍。下面是一个典型的PPP协议的帧格式：当PPP帧中的protocol域表明协议类型为C227(PPP EAP)时，在PPP数据链路层帧的Information域中封装且仅封装PPP EAP数据包，此时表明将应用PPP的扩展认证协议EAP。这个时候这个封装着EAP报文的Information域就担负起了下一步认证的全部任务，下一步的EAP认证都将通过它来进行。一个典型的EAP认证的过程分为：request、response、success或者failure阶段，每一个阶段的报文传送都由Information域所携带的EAP报文来承担。EAP报文的格式为：Code域为一个字节，表示了EAP数据包的类型，EAP的Code的值指定和意义如下：Code1 RequestCode2 ResponseCode3 SuccessCode4 FailureIdentifier域为一个字节，辅助进行request和response的匹配每一个request都应该有一个response相对应，这样的一个Identifier域就建立了这样的一个对应关系相同的Identifier相匹配。Length域为两个字节，表明了EAP数据包的长度，包括Code、Identifier、Length以及Data等各域。超出Length域范围的字节应该视为数据链路层填充（padding），在接收时应该被忽略掉。Data域为0个或者多个字节，Data域的格式由Code的值来决定。下面分别介绍Code为不同值的时候报文的格式和各个域的定义。1) 当Code域为1或者2的时候，这个时候为EAP的request和response报文，报文的格式为：Identifier域为一个字节。在等待Response时根据timeout而重发的Request的Identifier域必须相同。任何新的（非重发的）Request必须修改Identifier域。如果对方收到了重复的Request，并且已经发送了对该Request的Response，则对方必须重发该Response。如果对方在给最初的Request发送Response之前收到重复的Request（也就是说，它在等待用户输入），它必须悄悄的丢弃重复的Request。Length域为两个字节，表明EAP数据包的长度，包括Code、Identifier、Length、Type以及Type-Data等各域。超出Length域的字节应视为数据链路层填充（padding），在接收时应该被忽略掉。Type域为一个字节,该域表明了Request或Response的类型。在EAP的Request或Response中必须出现且仅出现一个Type。通常Response中的Type域和Request中的Type域相同。但是，Response可以有个Nak类型，表明Request中的Type不能被对方接受。当对方发送Nak来响应一个Request时，它可以暗示它所希望使用并且支持的认证类型。Type Data域随Request和相对应的Response的Type的不同而不同。Type域总共分为6个值域，其中头3种Type被认为特殊情形的Type，其余的Type定义了认证的交换流量。Nak类型仅对Response数据包有效，不允许把它放在Request中发送。Type1 IdentifierType2 NotificationType3 Nak（Response Only）Type4 MD5-ChallengeType5 One-Time Password (OTP)Type6 Generic Token Card2) 当Code域为3或者4的时候，这个时候为EAP的Success和Failure报文，报文的格式为：当Code为3的时候是Success报文，当Code为4的时候是Failure报文。Identifier域为一个字节，辅助匹配Response应答。Identifier域必须与其正在应答的Response域中的Identifier域相匹配。2.3 典型应用的拓扑结构在实际的网络拓扑结构中，有两种典型的应用：带802.1X的设备作为接入层设备、带802.1X的设备作为汇接层设备。带802.1X的设备作为接入层设备，拓扑图如图4所示，该拓扑的主要特点如下：1) 每台支持802.1X 的交换机所负责的客户端少，认证速度快。各台交换机之间相互独立，交换机的重起等操作不会影响到其它交换机所连接的用户；2) 用户的管理集中于Radius Server 上，管理员不必考虑用户连接在哪台交换机上，便于管理员的管理；3) 管理员可以通过网络管理到接入层的设备。带802.1X的设备作为汇接层设备，拓扑图如图5所示，该拓扑的主要特点如下：1) 由于是汇接层设备，网络规模大，下接用户数多，对设备的要求高，因为若该层设备发生故障，将导致大量用户不能正常访问网络；2) 用户的管理集中于Radius Server 上，管理员不比考虑用户连接在哪台交换机上，便于管理员的管理；3) 接入层设备可以使用较廉价的非网管型交换机（只要支持EAPOL 帧透传）；4) 管理员不能通过网络直接管理到接入层设备。图4 认证系统作接入层设备图5 认证系统作汇接层设备第三章 实验拓扑及抓包本章的实验拓扑及抓包分析都是基于认证体系的三个部分：请求者系统、认证系统和认证服务器系统。3.1 TL-SL3226P实验拓扑及认证软件实验拓扑如图6所示，请求者系统即普通工作站PC，上面安装了认证客户端软件TpSupplicant，认证系统即支持802.1X的交换机，拓扑实验中是我司的TL-SL3226P，认证服务器系统即Radius Server，实验中是运行WinRadius软件的普通PC。图6 TL-SL3226P实验拓扑图TL-SL3226P页面认证设置如图7、图8所示，认证配置分为交换机配置和端口配置，交换机配置中各参数要与服务器的IP、端口、密钥对应，端口配置是与认证客户机所连接的端口是否打开认证功能。图7 TL-SL3226P认证配置图8 TL-SL3226P认证端口配置3.2 TL-SL3226P认证过程抓包分析3.2.1 认证发起抓包分析点击客户端软件TpSupplicant的连接请求时，一个完整的认证过程如图9所示。图9 802.1X认证过程(MD5-Challenge)下面重点分析一下整个认证过程。1) 客户端向接入设备发送一个EAPOL-Start报文，开始802.1X认证接入，见图9报文11；2) 接入设备向客户端发送EAP-Request/Identity报文，要求客户端将用户名送上来，见图9报文12；3) 客户端回应一个EAP-Response/Identity给接入设备的请求，见图9报文13，其中包括用户名hgs(在WinRadius软件中自己添加的用户名)，如下图红色区域所示；4) 接入设备将EAP-Response/Identity报文封装到RADIUS Access-Request报文中，发送给认证服务器，见图9报文14；3) 认证服务器产生一个Challenge，通过接入设备将RADIUS Access-Challenge报文发送给客户端，其中包含有EAP-Request/MD5-Challenge，见图9报文15；4) 接入设备把EAP-Request/MD5-Challenge发送给客户端，要求客户端进行认证，见图9报文16；5) 客户端收到EAP-Request/MD5-Challenge报文后，将密码和Challenge做MD5算法后的Challenged-Pass-word，在EAP-Response/MD5-Challenge回应给接入设备，见图9报文17；6) 接入设备将Challenge，Challenged Password和用户名一起送到RADIUS服务器，由RADIUS服务器进行认证，见图9报文18；7) RADIUS服务器根据用户信息，做MD5算法，判断用户是否合法，然后回应认证成功/失败报文到接入设备。如果成功，携带协商参数，以及用户的相关业务属性给用户授权，见图9报文19。如果认证失败，则流程到此结束；8) 接入设备将Challenge，Challenged Password和用户名一起送到RADIUS服务器，由RADIUS服务器进行认证，见图9报文20；9) 如果认证通过，接入设备发起计费开始请求给RADIUS用户认证服务器，见图9报文21；10) RADIUS用户认证服务器回应计费开始请求报文，认证成功，见图9报文22、23。如果用户名或者密码错误，则认证只会到第九步就会结束，过程如图10所示。图10 输入错误的密码后的认证过程下图为认证失败后EAP-Failure报文结构。图11是使用TP-LINK扩展认证算法的一个完整认证过程。图11 802.1X认证过程(TP-LINK扩展认证算法)3.2.2 退出认证抓包分析图12为客户端主动点击断开时抓包过程。图13是把交换机和客户端连接的端口2改为Disable后断开的过程，由图12、图13可以看出，客户端主动断开连接时它会主动发出一个EAPOL-Logoff报文给交换机通知它已断开，而交换机端口状态改变时交换机会主动向客户端发一个EAP-Failure的报文。图12 客户端断开连接图13 交换机端口状态改变3.2.3 认证成功后抓包分析当客户端认证成功后，客户端与交换机每隔一定的时间有一个报文信息的交互，如图14所示。图14 认证成功后3.2.4 多客户端认证当TL-SL3226P一个端口连接有多台客户机时，拓扑图如图15所示。图15 多客户端认证上图中，Switch1为TL-SL3226P，Switch2为TL-SG1005D，Client1和Client2都认证成功后，TL-SL3226P页面上有如下信息显示：端口2的用户数目为2，并且受控端口下正确显示出已通过认证的客户端MAC地址。某一时刻Client1或Client2主动断开连接或者链接物理断开时，不会影响另一台Client的正常应用。3.3 H3C S5100认证实验3.3.1 认证过程H3C S5100交换机支持EAP 终结方式和EAP 中继方式进行认证。1. EAP中继方式这种方式是IEEE 802.1X 标准规定的，将EAP 协议承载在其他高层协议中，如EAP over RADIUS，以便扩展认证协议报文穿越复杂的网络到达认证服务器。一般来说，EAP 中继方式需要RADIUS 服务器支持EAP 属性：EAP-Message（值为79）和Message-Authenticator（值为80）。EAP 中继方式有四种认证方法：EAP-MD5、EAP-TLS（Transport Layer Security，传输层安全）、EAP-TTLS 和PEAP（Protected Extensible Authentication Protocol，受保护的扩展认证协议）。以下以EAP-MD5 方式为例介绍基本业务流程，如图16所示：图16 802.1X认证系统的EAP中继方式业务流程2. EAP终结方式这种方式将EAP报文在设备端终结并映射到RADIUS报文中，利用标准RADIUS协议完成认证和计费。对于EAP终结方式，交换机与RADIUS服务器之间可以采用PAP或者CHAP认证方法。以下以CHAP 认证方法为例介绍基本业务流程，如图17所示。EAP 终结方式与EAP中继方式的认证流程相比，不同之处在于用来对用户口令信息进行加密处理的随机加密字由交换机生成，之后交换机会把用户名、随机加密字和客户端加密后的口令信息一起送给RADIUS服务器，进行相关的认证处理。图17 802.1X认证系统的EAP终结方式业务流程图18为H3C S5100认证实验拓扑图。图18 H3C S5100认证拓扑图下面命令行是H3C S5100关于802.1X的认证配置，具体命令的含义和参数的配置请查看H3C S5100-SI/EI 系列以太网交换机 命令手册。WinRadius的配置如图19所示。图19 WinRadius参数配置客户端上安装H3C以太网交换机认证专用软件，如果交换机和服务器都配置正确以后，点击客户端认证软件的连接，就会弹出已成功通过网络验证的消息。l EAP中继方式抓包(EAP-MD5)l EAP终结方式抓包(PAP)l EAP终结方式抓包(CHAP)图20、21分别是在客户端和服务器上Ethereal抓包显示认证发起、认证成功后和退出认证的整个过程。图20 Client-Switch过程抓包图21 Server-Switch过程抓包H3C S5100 802.1X认证发起到认证成功的过程即为图20、21的前6个报文(EAP中继方式MD5加密算法)，总的认证过程也是12个报文的交互。图20的7至64个报文显示了认证成功后交换机与客户端的报文交互，时间间隔是15秒。图20的第65、66两个报文和图21的第55、56两个报文为客户端主动断开时的客户端与交换机以及服务器与交换机之间的报文交互。3.3.2 定时器802.1X认证过程中会启动多个定时器以控制接入用户、交换机以及RADIUS服务器之间进行合理、有序的交互。H3C S5100定时器主要有以下几种：l 握手定时器（handshake-period）：此定时器是在用户认证成功后启动的，交换机以此间隔为周期发送握手请求报文，以定期检测用户的在线情况。如果dot1x retry 命令配置重试次数为N，则如果交换机连续N次没有收到客户端的响应报文，就认为用户已经下线。交换机默认握手定时器为15s，修改为30s后交换机和客户端每个30s交互一次报文以确认客户端的在线状态，如图22所示。图22 握手定时器设置及其抓包l 静默定时器（quiet-period）：对用户认证失败以后，交换机需要静默一段时间（该时间由静默定时器设置）后，用户可以再重新发起认证，在静默期间，交换机不进行该用户的802.1X认证相关处理。交换机默认静默定时器关闭，打开静默定时器并设置时间为120s，在客户端软件输入错误的用户名或密码，认证失败，如图23中的报文98至105，然后输入正确的用户名和密码进行认证，由图23中可以看出在138s交换机才处理客户端认证请求，时间差为138-19=119s，在客户端软件上同样也可大概计算出静默定时器，14:42:23开始认证，失败后到14:44:19的时间段内交换机不处理客户端的认证请求，时间差为116s。图23 静默定时器设置及其抓包图24 客户端观察静默定时器的设置l 重认证超时定时器（reauth-period）：在该定时器设置的时长内，交换机会发起802.1X重认证。802.1X重认证流程如图25所示，由图可以看出，进行重认证时服务器计费并不会终止。交换机默认重认证超时定时器关闭，打开重认证超时定时器并设置时间为60s，由图26可以看出每隔60s交换机和服务器会进行一次报文交互来进行认证，图27在客户端软件界面上同样可以看出重认证时间为60s。图25 802.1X重认证流程图26 重认证超时定时器设置及其抓包图27 客户端观察重认证超时定时器l 传送超时定时器（tx-period）：以下两种情况交换机启动tx-period定时器：其一是在客户端主动发起认证的情况下，当交换机向客户端发送单播Request/Identity请求报文后，交换机启动该定时器，若在该定时器设置的时长内，交换机没有收到客户端的响应，则交换机将重发认证请求报文；其二是为了对不支持主动发起认证的802.1X客户端进行认证，交换机会在启动802.1X功能的端口不停地发送组播Request/Identity报文，发送的间隔为tx-period。传送时间设置为10s，重复次数为5次，对于主动发起认证的客户端，发送一个EAPOL-Start报文后(LinkPackets模拟发包)不再响应EAP-Request请求，交换机每隔10s发送一个请求报文，5次之后没有响应则主动发送一个EAP-failure报文，整个过程如图28所示。交换机默认打开传送超时定时器，主动认证请求报文时间间隔为30s，如图29报文43至309所示，将其设置为10s后，如图29报文332至448所示。图28 客户端主动认证超时图29 交换机主动发起认证超时l RADIUS服务器超时定时器（server-timeout）：若在该定时器设置的时长内，RADIUS 服务器未成功响应，交换机将重发认证请求报文。交换机默认服务器超时时间为100s，实验过程中用LinkPackets回复RADIUS-ACCESS/Request，如图30中报文24所示，但是交换机仍然发id=10的RADIUS-ACCESS/Request报文，说明回复的报文RADIUS-ACCESS/Challenge未被交换机识别(MD5每次发出的密文都是用随机吗生成的)。报文64至70是WinRadius关闭时交换机连续发出的3次请求报文。服务器超时定时器设置为100s，重复次数为5次，实验结果仍然是请求报文时间间隔为3s，次数都是3次，与设置无关，具体原因未知。图30 服务器认证超时定时器l 客户端认证超时定时器（supp-timeout）： 当交换机向客户端发送了Request/Challenge 请求报文后，交换机启动此定时器，若在该定时器设置的时长内，设备端没有收到客户端的响应，交换机将重发该报文。交换机默认时间为30s，交换机发出EAP-Request请求报文后，用LinkPackets回复一个EAP-Response报文，交换机再发出一个EAP-Request/Challenge报文，客户端不再回复，交换机并没有按设置的30s重复发送EAP-Request/Challenge报文，而是等待180后主动发出一个EAP-Failure报文，如图31所示。说明：实验进行了多次，交换机在发出EAP-Request/Challenge报文后未收到回复，都是过180s后发出EAP-Failure报文，与客户端认证超时定时器的设置无关，具体原因未知。图31 客户端认证超时定时器l ver-period：客户端版本请求超时定时器。若在该定时器设置的时长内，客户端设备未成功发送版本应答报文，则交换机将重发版本请求报文。在交换机上启动了对802.1X客户端的版本验证功能后，交换机会对接入用户的802.1X 客户端软件的版本和合法性进行验证，以防止使用有缺陷的老版本客户端或者非法客户端的用户上网。该功能的实现需要H3C 802.1X客户端程序（iNode）的配合。3.3.3 Guest VLANGuest VLAN功能用来允许未认证用户访问某些特定资源。在实际应用中，如果用户在没有安装802.1X客户端的情况下，需要访问某些资源；或者在用户未认证的情况下升级802.1X客户端，这些情况可以通过开启Guest VLAN功能来解决。Guest VLAN 的功能开启后：1) 交换机将在所有开启802.1X功能的端口发送多播触发报文；2) 如果达到最大发送次数后，仍有端口尚未返回响应报文，则交换机将该端口加入到Guest VLAN 中；3) 之后属于该Guest VLAN 中的用户访问该Guest VLAN 中的资源时，不需要进行802.1X认证，但访问外部的资源时仍需要进行认证。实验拓扑如图32所示，WinRadius位于VLAN1，Client位于VLAN2， Client认证方式为端口认证，打开H3C S5100的Guest VLAN功能，配置VLAN1为Guest VLAN并将Client与H3C S5100相连接的端口加入Guest VLAN。图32 Guest VLAN实验拓扑加入了Guest VLAN功能后，虽然Client与Server属于不同的VLAN，但是Client可以Ping通Server，如图33所示。Client成功通过认证后，由于Client与Server属于不同的VLAN，所以Client不能Ping通Server，如图34所示。图33 客户端认证前图34 客户端认证后图32配置的Guest VLAN原理解释：用户在通过认证之前，Client所连接的物理端口的PVID不是10，而是在交换机上配置的Guest VLAN 1，因此Client无需通过认证就可以Ping通Server；Client通过认证之后，Client所连接端口的PVID自动变为10，所以不能Ping通Server。3.4 TL-SL3226P与H3C S5100的比较下面列出TL-SL3226P和H3C S5100在实现802.1X认证方面的比较表格，主要从3个方面进行对比：功能实现、参数、认证方式。对比项目DUT型号是否能完全实现802.1X认证认证参数是否齐全是否具有端口和MAC认证及实现情况TL-SL3226P否不齐全具有，只能实现MAC认证H3C S5100是齐全具有，都能实现下面对上面表格作几点说明：1) TL-SL3226P虽然支持802.1X，但是其功能还有很多不完善的地方。如Client断开连接后，Client仍能Ping通Server；输入错误的密码或用户名，认证不能成功，但是Client还是能Ping通Server。对于上面的两种情况，H3C S5100做认证系统时，客户端不能Ping通Server。2) TL-SL3226P只有定期重认证这个参数，并且这个参数改为60s后，认证成功后经过60s，TL-SL3226P未要求客户端进行重新认证。H3C S5100的认证参数如图20所示，能根据不同的网络拓扑设置不同的参数从而达到网络的优化。图20 H3C S5100认证参数3) TL-SL3226P不能实现基于端口的认证，虽然设置界面中有这项设置，但是选择Port-Based 802.1X时，在任何一个端口客户端都不能进入交换机的主界面即客户端不能Ping通交换机，只有重新上电或重启才行。H3C S5100能很好的实现基于端口的认证和基于MAC地址的认证。H3C S5100基于端口认证和基于MAC地址认证的区别：l 基于端口的认证：只要该物理端口下的第一个用户认证成功后，其他接入用户无须认证就可使用网络资源，当第一个用户下线后，其他用户也会被拒绝使用网络。l 基于MAC 地址认证：该物理端口下的所有接入用户都需要单独认证，当某个用户下线时，也只有该用户无法使用网络，不会影响其他用户使用网络资源。认证通过后，不管是TL-SL3226P还是H3C S5100，交换机与服务器的链接物理断开或服务器端WinRadius关闭，客户端的连接均显示正常，即交换机不能把其与服务器的状态(连接正常或断开)告知给客户端。实验中还有很多不足的地方，认证服务器只是运行WinRadius软件的PC，而在Windows Server 2003上搭建的Radius服务器作认证计费服务器，认证一直没有成功。第四章 802.1X功能测试由于TL-SL3226P没有完全实现802.1X的功能，所以本章的测试用例都是基于H3C S5100交换机，由于没有配套的服务器，所以还无法在实验中确认某些参数的具体含义，所以有些认证参数没有制定测试用例，但是802.1X测试用例会随着我司新出交换机完全实现这一功能而逐步更新和完善。测试用例中每个测试项的测试拓扑图和测试软件如无变化，都和认证发起测试相同，测试用例中将省略这两项。4.1 认证发起测试测试目的：当客户端发出EAPOL-Start报文请求认证后，检验DUT的处理能力(能否完成整个认证过程)。测试软件：TpSupplicant(支持DUT认证的专用客户端认证软件)、WinRadius、Ethereal测试拓扑：测试步骤：1) 启用DUT的802.1X功能，Port1设置为Auto，Port2设置为ForceAuthorized；2) 启动客户端认证软件，发起认证请求；3) 在PC1端用Ethereal抓包；4) 输入正确的用户名和密码；5) 观察客户端的认证结果和DUT认证页面相关信息；6) 输入错误的用户名或密码，重新启动一次认证；7) 观察客户端的认证结果和DUT认证页面相关信息；8) DUT禁用802.1X协议，重复测试一遍；9) 在其它端口再重复一次测试。判断标准：1) 对于能主动发起认证的DUT，在PC1能捕获到DUT发出EAP-Request/Identity报文；2) 对于不能主动发起认证的DUT，步骤3中PC1应能捕获客户端发出的EAPOL-Start报文以及DUT发出的EAP-Request/Identity报文；3) 步骤5中PC1应该出现“认证通过、成功登录网络”的信息框，DUT认证页面中Port1用户数目应该显示为1；4) 步骤6中PC1应该出现“认证失败，请检查用户名和密码”的信息框；5) 步骤8中客户端发起认证请求，PC1捕获包只有EAPOL-Start和EAP-Success报文；6) 在PC2抓包，一个完整的认证过程(MD5-Challenge)应该如图9所示；7) 步骤9中其它端口测试结果同上。4.2 退出认证测试测试目的：检测DUT在收到客户端的EAP-Logoff消息时的注销能力(能否发出EAP-Failure报文)或主动注销端口的能力(端口由Enable变为Disable)。测试步骤：1) 认证成功后，在客户端点击断开即主动发出EAP-Logoff报文；2) 在PC1端用Ethereal抓包；3) 认证成功后，在DUT认证页面中Port1由Enable设置为Disable；4) 在PC1端用Ethereal抓包。判断标准：1) 步骤2中PC1应该能捕获到EAPOL-Logoff、EAP-Failure报文，如图12所示；2) 步骤4中PC1应该能捕获到EAP-Failure报文。4.3 多客户端认证测试测试目的：检验DUT某个端口能否同时支持多个客户端进行认证。测试拓扑：测试步骤：1) PC1认证成功后，在PC2上以相同的用户名和密码进行认证；2) PC1认证成功后，在PC2上以不同的用户名和密码进行认证；3) PC1断开连接；4) PC1、PC2都认证成功后，在DUT页面认证地址表中删除PC1的认证信息；5) PC1、PC2都认证成功后，Port1由Enable设置为Disable。判断标准：1) 步骤1中PC2应能认证成功；2) 步骤2中PC2应能认证成功；3) 步骤3中PC1断开连接应不影响PC2的认证状态；4) 步骤4中PC1应该能捕获到EAP-Failure报文；5) 步骤5中PC1、PC2都能捕获到EAP-Failure报文。4.4 端口认证方式测试测试目的：检验DUT是否支持基于MAC地址的认证(MAC-based)和基于端口的认证(Port-based)。测试拓扑：同多客户端认证测试拓扑。测试步骤：1) 启用DUT的802.1X功能，Port1设置为Auto，认证方式为基于MAC地址认证，Port2设置为ForceAuthorized；2) PC1、PC2分别发起认证(PC1认证在前)；3) PC1主动下线；4) PC2 Ping PC3(PC1、PC2、PC3在同一个VLAN并且在同一个网段)；5) PC2主动下线，Port1认证方式设置为基于端口认证；6) PC1发起认证；7) PC2 Ping PC3(PC1、PC2、PC3在同一个VLAN并且在同一个网段)；8) PC1主动下线；9) PC2 Ping PC3。判断标准：1) 步骤2中PC1、PC2都能通过认证；2) 步骤4中PC2能Ping通PC3；3) 步骤7中PC2能Ping通PC3；4)