CN103338440B - 认证***中的认证方法及设备端 - Google Patents

Abstract

本申请公开了一种认证***中的认证方法及设备端，该认证***中包括：客户端、设备端和认证服务器，该方法应用于设备端，该方法包括：在用户认证成功后，将本设备连接用户的客户端的端口授权；在检测到客户端在端口被授权且获取到了IP地址之后，请求认证服务器开始计费。利用本申请的技术方案，认证服务器从客户端获取到IP地址，能够正常访问网络业务之后，才开始进行计费，从而，避免了对用户计费不准确，即多计费的问题，实现了对认证用户的准确合理计费。

Description

认证***中的认证方法及设备端

技术领域

本申请涉及网络通信技术领域，特别涉及一种认证***中的认证方法及设备端。

背景技术

为解决无线局域网的网络安全问题，IEEE（InstituteofElectricalandElectronicsEngineers，电气电子工程师学会）802LAN（LocalAreaNetwork，局域网）/WAN（WideAreaNetwork，广域网）委员会提出了802.1x协议。后来，802.1x协议作为局域网端口的一个普通接入控制机制在以太网中被广泛应用，主要解决以太网内认证和安全方面的问题。802.1x协议是一种基于端口的网络接入控制协议（portbasednetworkaccesscontrolprotocol）。“基于端口的网络接入控制”是指在局域网接入设备的端口这一级对所接入的用户设备进行认证和控制。连接在端口上的用户设备如果能通过认证，就可以访问局域网中的资源；如果不能通过认证，则无法访问局域网中的资源—相当于物理连接被断开。使用802.1x的***为典型的Client（客户端）/Server（服务器）体系结构，包括三个实体，如图1所示，这三个实体分别为：SupplicantSystem（客户端）、AuthenticatorSystem（设备端）以及AuthenticationServerSystem（认证服务器）。

802.1x***支持EAP（ExtensibleAuthenticationProtocol，可扩展认证协议）中继方式和EAP终结方式与RADIUS（RemoteAuthenticationDialInUserService，远程用户拨入认证服务）对接，从而利用远端的RADIUS服务器完成认证。在客户端与设备端之间，EAP协议报文使用EAPOL（ExtensibleAuthenticationProtocoloverLAN，局域网上的可扩展认证协议）封装格式。

如图1所示，以EAP终结方式为例，现有技术的802.1x认证流程主要包括以下步骤：

步骤1：当用户需要访问外部网络时打开802.1x客户端（程序），输入已经申请、登记过的用户名和密码，发起连接请求。此时，客户端将向设备端发出认证请求帧EAPOL-Start，开始启动一次认证过程；

步骤2，设备端接收到EAPOL-Start后，将发出一个Identity（身份）类型的请求帧EAP-Request/Identity，要求客户端发送用户输入的用户名；

步骤3，客户端响应设备端发出的EAP-Request/Identity，将用户输入的用户名通过Identity类型的响应帧EAP-Response/Identity发送给设备端；

步骤4，设备端随机生成一个MD5Challenge（加密字），将此MD5Challenge封装在MD5Challenge类型的请求帧EAP-Request/MD5Challenge中发送出去，要求客户端使用此MD5Challenge对用户输入的密码进行加密处理；

步骤5，客户端收到由设备端传来的MD5Challenge后，用该MD5Challenge对用户输入的密码进行加密处理，将MD5Challenge和加密后的密码携带在MD5Challenge类型的响应帧EAP-Response/MD5Challenge中，发送给设备端；

步骤6，设备端将客户端发来的用户名、MD5Challenge和客户端加密后的密码封装在RADIUS报文RADIUSAccess-Request中发送给RADIUS服务器进行处理；

步骤7，RADIUS服务器提取RADIUSAccess-Request中的用户名、MD5Challenge和客户端加密后的密码，将该用户名与数据库中的用户名列表中的用户名进行对比，找到该用户名对应的密码，用RADIUSAccess-Request中的MD5Challenge对找到的密码进行加密，再与RADIUSAccess-Request中的客户端加密后的密码进行对比，如果两者相同，则认为该用户是合法用户，向设备端发送认证通过报文RADIUSAccess-Accept；

步骤8，设备端接收到RADIUSAccess-Accept后，向RADIUS服务器发起计费开始请求报文RADIUSAccounting-Request；

步骤9，RADIUS服务器核对用户名信息后，开始计费，并发出计费开始响应报文RADIUSAccounting-Response给设备端；

步骤10，设备端接收到RADIUSAccounting-Response后，向客户端发送认证成功帧EAP-Success，并将本设备连接至客户端的端口的状态改为授权状态，允许用户通过端口访问网络；之后，用户获取IP地址；

步骤11，用户在线后，设备端会定时向RADIUS服务器上报本段时间内用户访问资源的情况，发送实时计费请求报文RADIUSAccounting-Request；

步骤12，RADIUS服务器收到RADIUSAccounting-Request后，更新用户访问的资源信息，然后发送实时计费响应报文RADIUSAccounting-Response；

步骤13，用户在线期间，设备端会通过向客户端定期发送握手报文EAP-Request/Identity的方法，对用户的在线情况进行监测；

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

步骤15，客户端可以发送EAPOL-Logoff给设备端，主动要求下线。设备端把端口状态从授权状态改变成未授权状态。

由上述认证流程可知，用户认证成功后，在端口还没有授权，用户无法获取IP地址的情况下，就通过步骤8开始了计费流程，此时，由于用户还没有获取到IP地址，因此，用户的业务是无法正常进行的，直到获取到IP地址后用户才能够正常访问网络业务。也就是说，RADIUS服务器将从用户认证成功到获取到IP地址的这段时间也计入了用户的在线时长，对这段时间进行了计费，但是，用户在这段时间内是无法进行正常访问网络的，因此，导致了计费不准确，即多计费的问题。

发明内容

本申请提供了一种认证***中的认证方法及设备端，以解决现有技术中存在的对用户的计费不准确，即多计费的问题。

本申请的技术方案如下：

一方面，提供了一种认证***中的认证方法，该认证***中包括：客户端、设备端和认证服务器，该方法应用于设备端，该方法包括：

在用户认证成功后，将本设备连接用户的客户端的端口授权；

在检测到客户端在端口被授权且获取到了IP地址之后，请求认证服务器开始计费。

另一方面，还提供了一种认证***中的设备端，该认证***中包括：客户端、设备端和认证服务器，该设备端包括：

授权模块，用于在用户认证成功后，将本设备连接用户的客户端的端口授权；

计费开始请求模块，用于检测客户端在端口被授权后是否获取到了IP地址，并且，在检测到客户端获取到了IP地址之后，请求认证服务器开始计费。

通过本申请的技术方案，在用户认证成功后，设备端先将端口授权允许用户的客户端申请IP地址，并且在检测到客户端获取到了IP地址之后，才请求认证服务器开始计费，也就是说，将计费开始流程移到了客户端获取到IP地址之后再进行，这样，认证服务器就可以从客户端获取到IP地址，能够正常访问网络业务之后，才开始进行计费，从而，避免了对用户计费不准确，即多计费的问题，实现了对认证用户的准确合理计费。

附图说明

图1是现有技术的802.1x认证流程图；

图2是本申请的实施例一的认证***中的认证方法的流程图；

图3是本申请的实施例一的EAP-Response/Identity报文的格式示意图；

图4是本申请的实施例一的RD_IpCtrl_Option属性的格式示意图；

图5是本申请的实施例二的认证***中的认证方法的具体流程图；

图6是本申请的实施例二的设备端中认证状态机的状态转移图；

图7是本申请的实施例二的上线过程的IP联动处理流程图；

图8是本申请的实施例二的在线过程的IP联动处理流程图；

图9是本申请的实施例三的认证***中的设备端的结构示意图。

具体实施方式

为了解决现有技术中存在的对用户多计费，为用户带来了经济损失的问题，本申请的以下实施例中提供了一种认证***中的认证方法、以及一种可以应用该方法的设备端。

在以下实施例的认证***中包括：客户端、设备端和认证服务器。其中，该认证***可以是802.1x认证***，也可以是其他的接入认证***，例如MAC（MediaAccessControl，介质访问控制）认证***，设备端可以是NAS（NetworkAccessServer，网络接入服务器）设备，认证服务器可以是RADIUS服务器，本申请对此不做限定。

实施例一

本实施例一的认证***中的认证方法由设备端来执行。如图2所示，该方法包括以下步骤：

步骤S202，在用户认证成功后，将本设备连接用户的客户端的端口授权；

步骤S204，在检测到客户端在端口被授权且客户端获取到了IP（InternetProtocol，因特网协议）地址之后，请求认证服务器开始计费。

例如，在实际实施过程中，以EAP终结方式的802.1x认证为例，设备端在接收到如图1中所示的RADIUSAccess-Accept报文之后，暂时先不向认证服务器发送计费开始请求报文RADIUSAccounting-Request，而是先向客户端发送认证成功帧EAP-Success，并将本设备连接至客户端的端口的状态改为授权状态，以允许客户端申请IP地址。在设备端将该端口的状态改为授权状态之后，客户端就可以获取IP地址了。设备端在检测到客户端获取到了IP地址之后，才请求认证服务器开始计费，即向认证服务器发起RADIUSAccounting-Request报文。

其中，检测客户端获取IP地址的方式可以为客户端上传、通过DHCP（DynamicHostConfigurationProtocol，动态主机配置协议）SNOOPING（侦听）等，本申请对此不做限定。

通过本实施例的技术方案，在用户认证成功后，设备端先将端口授权允许用户的客户端申请IP地址，并且在检测到客户端获取到了IP地址之后，才请求认证服务器开始计费，也就是说，将计费开始流程移到了客户端获取到IP地址之后再进行，这样，认证服务器就可以从客户端获取到IP地址，能够正常访问网络业务之后，才开始进行计费，从而，避免了对用户计费不准确，即多计费的问题，实现了对认证用户的准确合理计费。

其中，步骤S204的具体操作步骤如下：

步骤S301，判断计费开始依赖于IP地址获取的功能是否被使能，若被使能，则从认证状态切换到IP检查状态，执行步骤S302；若没有被使能，则从认证状态切换到计费状态；

当处于计费状态时，设备端请求认证服务器开始计费，具体的，向认证服务器发送计费开始请求报文。

其中，设备端在接收到客户端发来的EAPOL-Start报文后，就进入到认证状态，之后，在用户认证成功后将本设备连接客户端的端口授权之后，执行步骤S301。

步骤S302，在从认证状态切换到IP检查状态之后，判断客户端是否获取到了IP地址，若获取到了IP地址，则进入步骤S303，否则，进入步骤S304；

步骤S303，从IP检查状态切换到计费状态；

步骤S304，开启定时器，判断客户端是否在定时器超时之前获取到了IP地址，若是，则从IP检查状态切换到计费状态；若在定时器超时之前没有获取到IP地址，则从IP检查状态切换到下线状态。

当处于下线状态时，将用户下线，并将端口的状态由授权状态修改为未授权状态。

在步骤S204中，增加了一个IP检查状态，在用户认证成功后，若使能了计费开始依赖于IP地址获取功能，则从认证状态切换到IP检查状态，在IP检查状态中，只有在检测到客户端获取到了IP地址之后，才会切换到计费状态，向认证服务器发起计费开始请求，这样，通过认证用户在获取到IP地址后才开始计费，能够实现IP联动的实时准确合理的计费。

另外，当处于计费状态时，在请求认证服务器开始计费之后，设备端需要在认证服务器开始计费成功之后，即，在接收到认证服务器返回的计费开始响应报文之后，从计费状态切换到在线状态，当处于在线状态时，需要执行以下操作步骤：

步骤S401，当处于在线状态时，判断IP地址变化触发重计费的功能或者IP地址变化触发下线的功能是否被使能，若其中一种功能被使能，则执行步骤S402，否则，即，这两种功能均没有被使能，则执行步骤S403；

其中，IP地址变化触发重计费的功能和IP地址变化触发下线的功能不能同时被使能。

步骤S402，从在线状态切换到IP检查状态，在从在线状态切换到IP检查状态之后，周期性地执行以下步骤1-3：

步骤1：判断客户端的IP地址是否发生了改变，若是，则执行步骤2，否则，执行步骤3；

其中，判断客户端的IP地址是否发生了改变可以利用现有技术中的握手交互过程，通过客户端与设备端之间的握手交互过程，设备端可以获知客户端的IP地址变化情况。

步骤2：判断IP地址变化触发重计费的功能或者IP地址变化触发下线的功能是否被使能，若IP地址变化触发重计费的功能被使能，则将记录的客户端的IP地址更新为改变后的IP地址，结束本次计费，从IP检查状态切换到计费状态；若IP地址变化触发下线的功能被使能，则从IP检查状态切换到下线状态；若IP地址变化触发重计费的功能和IP地址变化触发下线的功能均没有被使能，则将记录的客户端的IP地址更新为改变后的IP地址，从IP检查状态切换到在线状态；

其中，若IP地址变化触发重计费的功能被使能，则结束本次计费是指结束针对改变前的原IP地址的计费，从IP检查状态切换到计费状态之后，会请求认证服务器针对改变后的新IP地址开始计费。

步骤3：从IP检查状态切换到在线状态；

步骤S403，维持于在线状态。当处于在线状态时，会再次执行步骤S401-步骤S403。

因此，步骤S401-步骤S403是一个周期性执行的操作。

现有技术中，若设备端检测到在线用户的IP地址变化则将用户下线，对于IP变化的监控手段单一、不灵活，适应性较差，实际应用中在用户认证成功后，如果认证服务器下发了授权VLAN（VirtualLocalAreaNetwork，虚拟局域网）、或其他协议下发了动态VLAN，由于VLAN的切换，用户IP地址会发生变化，这属于正常现象，如果这种情况下将用户下线，会造成用户业务的中断，也限制了与其他协议的配合。本实施例通过上述的步骤S401-步骤S403，对于在线用户在IP地址变化触发重计费的功能或者IP地址变化触发下线的功能被使能的情况下，周期性地判断客户端的IP地址是否发生了改变，若发生了改变，则在IP地址变化触发重计费的功能被使能了的情况下，结束针对原IP地址的计费，并针对改变后的新IP地址请求认证服务器开始计费，或者在IP地址变化触发下线的功能被使能了的情况下，将用户下线，或者在IP地址变化触发重计费的功能和IP地址变化触发下线的功能都没有被使能的情况下，仅更新IP地址。这样，对于在线用户的IP地址改变的情况，提供了三种监控手段：重新计费、下线、或忽略（即令用户仍然在线），监控手段灵活，适用于各种应用场景中。

另外，在上述的操作步骤中，判断计费开始依赖于IP地址获取的功能、IP地址变化触发重计费的功能、或者IP地址变化触发下线的功能是否被使能的方式可以采用以下三种方式中的任意一种：

方式一：根据本设备的配置信息进行判断，其中，配置信息中包括：计费开始依赖于IP地址获取的功能和/或IP地址变化触发重计费的功能被使能，或者，计费开始依赖于IP地址获取的功能和/或IP地址变化触发下线的功能被使能；

在实际实施过程中，由设备端本身来管理上述三种功能的使能情况，根据客户端上传IP地址的支持情况、认证服务器的计费对IP地址要求的严格程度，来配置对应功能的使能，具体命令格式例如可以为（不局限于此）：

dot1xaccountingstart-optionneed-ip//表示计费开始依赖于IP地址获取的功能被使能

dot1xaccountingonline-optionip-change-re-accounting//表示IP地址变化触发重计费的功能被使能

dot1xaccountingonline-optionip-change-offline//表示IP地址变化触发下线的功能被使能

管理员可以根据具体的组网环境及需求配置上述三种功能被使能，不做配置则说明对应功能没有被使能。

方式二：根据接收到的客户端发来的控制信息进行判断，其中，控制信息用于指示计费开始依赖于IP地址获取的功能和/或IP地址变化触发重计费的功能是否被使能，或者，计费开始依赖于IP地址获取的功能和/或IP地址变化触发下线的功能是否被使能。

在实际实施过程中，客户端可以通过发送给设备端的EAP-Response/Identity报文携带控制信息，来控制设备端上的上述三种功能的使能。例如，定义一种新的属性IP_Ctrl_Option（IP控制选项）来实现上述控制信息，如图3所示，IP_Ctrl_Option是一种TLV（TypeLengthValue，类型长度值）格式，下面对IP_Ctrl_Option中的主要字段解释如下：

Type：表示本TLV是IP_Ctrl_Option，该字段的值可以为0x81；

Length：表示本TLV中Value字段的长度，该字段的值可以固定为1字节；

Value：在图3中表示为IP联动选项，该字段的长度为1字节，即8个比特位，可以使用这8个比特位中的3个比特位来表示上述三种功能是否被使能。例如，可以使用这8个比特位中的低3位，每一个比特位对应于一个功能，不同比特位对应于不同功能，当一个比特位置为1时，表示对应的功能被使能，当该比特位置为0时，表示对应的功能没有被使能。

例如，最低3位从高到低分别对应于IP地址变化触发下线的功能、IP地址变化触发重计费的功能和计费开始依赖于IP地址获取的功能，则客户端要求设备端使能计费开始依赖于IP地址获取的功能和IP地址变化触发下线的功能，则Value的值应该置为0x5（00000101）。

方式三：根据接收到的认证服务器发来的控制信息进行判断，其中，控制信息用于指示计费开始依赖于IP地址获取的功能和/或IP地址变化触发重计费的功能是否被使能，或者，计费开始依赖于IP地址获取的功能和/或IP地址变化触发下线的功能是否被使能。

在实际实施过程中，认证服务器可以通过发给设备端的RADIUSAccess-Accept报文携带控制信息，来控制设备端上的上述三种功能的使能。例如，定义一种新的扩展属性RD_IpCtrl_Option（RADIUSIP控制选项），来实现上述控制信息。RD_IpCtrl_Option的属性说明如表1所示，封装格式如图4所示。

表1

如图4所示，RD_IpCtrl_Option是一种TLV格式，下面对RD_IpCtrl_Option中的主要字段解释如下：

Type：表示本TLV是RD_IpCtrl_Option，该字段的值可以为0xFD；

Length：表示本TLV中Value字段的长度，该字段的值可以固定为1字节，该字段的长度可以为1字节；

Value：在图4中表示为IP联动选项，该字段的长度为1字节，即8个比特位，可以使用这8个比特位中的3个比特位来表示上述三种功能是否被使能。例如，可以使用这8个比特位中的低3位，每一个比特位对应于一个功能，不同比特位对应于不同功能，当一个比特位置为1时，表示对应的功能被使能，当该比特位置为0时，表示对应的功能没有被使能。

例如，最低3位从高到低的对应情况为：

Bit0：计费开始依赖于IP地址获取的功能；

Bit1：IP地址变化触发重计费的功能；

Bit2：IP地址变化触发下线的功能。

则认证服务器要求设备端使能计费开始依赖于IP地址获取的功能和IP地址变化触发下线的功能，则Value的值应该置为0x5（00000101）。

在上述实施例中，IP联动的控制方式分为上线过程和在线过程：

上线过程中，在计费开始依赖于IP地址获取的功能被使能时，在检测到客户端获取到IP地址之后，才请求认证服务器开始计费，即，计费开始依赖于IP地址的获取；

在线过程中，在IP地址变化触发重计费的功能被使能时，检测到在线用户的IP地址发生改变之后，会触发重新计费；在IP地址变化触发下线的功能被使能时，检测到在线用户的IP地址发生改变之后，会触发用户下线。

在现有技术中，IP变化的监控功能的控制完全由设备端负责，客户端和认证服务器通常不参与控制，监控方案存在局限性，没有充分发挥客户端和认证服务器的控制作用。本实施例中，可以通过命令行配置、客户端下发、认证服务器下发这三种方式中的任意一种方式来控制设备端的IP联动方式，控制方式更加灵活，实现了动态控制。

实施例二

在802.1x认证***的设备端中的认证状态机中增加了一个CHECKIP状态，用于在认证流程中进行IP联动。如图6所示，认证状态机的状态转移关系如下：

1、AUTH→CHECKIP：当用户认证成功后，如果需要检查IP地址，则切换到CHECKIP状态。

若计费开始依赖于IP地址获取的功能被使能，则说明需要检查IP地址，否则，说明不需要检查IP地址。

2、CHECKIP→ACCT：当检测到客户端成功获取到IP地址后，向认证服务器发送计费开始请求，切换到ACCT状态，开始计费；当检测到客户端的IP地址变化后，若需要重计费，则切换到ACCT状态，进行重计费。

若IP地址变化触发重计费的功能被使能，则说明需要重计费，否则，说明不需要重计费。

3、ONLINE→CHECKIP：用户在线后，如果需要监控客户端的IP地址的变化，则需要周期性地进入CHECKIP状态进行相应的监控动作。

若IP地址变化触发重计费的功能或者IP地址变化触发下线的功能被使能，则说明需要监控客户端的IP地址的变化，否则，这两个功能都没有被使能，说明不需要监控客户端的IP地址的变化。

4、CHECKIP→ONLINE：用户在线后，检测到客户端的IP地址无变化或者对IP地址的变化忽略，则切换到ONLINE状态。

若IP地址变化触发重计费的功能和IP地址变化触发下线的功能都没有被使能，则说明对IP地址的变化忽略。

5、CHECKIP→LOGOFF：用户认证成功后，如果预定时间内客户端尚未获取到IP地址，则切换到LOGOFF状态，将用户下线；或者，用户在线后，当检测到客户端的IP地址变化且IP变化后需要下线，则切换到LOGOFF状态，将用户下线。

若IP地址变化触发下线的功能被使能了，则说明IP变化后需要下线，否则，说明IP变化后不需要下线。

6、AUTH→ACCT：当用户认证成功后，如果不需要检查IP地址，则切换到ACCT状态，开始计费。

7、ACCT→ONLINE：若认证服务器计费开始成功，则切换到ONLINE状态。

8、ONLINE→ONLINE：若不需要监控客户端的IP地址的变化，则维持在在线状态。

9、ONLINE→LOGOFF：在收到客户端的下线请求后，则切换到LOGOFF状态，将用户下线。

结合如图6所示的状态转移关系，以EAP终结方式的802.1x认证为例，详细说明上述实施例一中的方法。如图5所示，该认证过程包括以下步骤：

步骤S501，当用户需要访问外部网络时打开802.1x客户端（程序），输入已经申请、登记过的用户名和密码，发起连接请求。此时，客户端将向设备端发出认证请求帧EAPOL-Start，开始启动一次认证过程；

步骤S502，设备端接收到EAPOL-Start后，进入如图6所示的认证（AUTH）状态，发出一个Identity（身份）类型的请求帧EAP-Request/Identity，要求客户端发送用户输入的用户名；

步骤S503-步骤S507，同图1中的步骤3-步骤7，这里不再赘述；

步骤S508，设备端接收到RADIUSAccess-Accept后，向客户端发送认证成功帧EAP-Success，并将本设备连接至客户端的端口的状态改为授权状态，允许用户的业务通过端口访问网络；之后，用户获取IP地址；

步骤S508-1，执行IP联动的上线处理流程，如图7所示，包括以下步骤：

步骤11：判断是否需要检查IP地址，若是，则执行步骤12，否则，执行步骤13；

若计费开始依赖于IP地址获取的功能被使能，则说明需要检查IP地址，否则，说明不需要检查IP地址。

步骤12：如图6所示，从AUTH状态切换到IP检查（CHECKIP）状态，在CHECKIP状态中，判断客户端是否获取到了IP地址，若获取到了IP地址，则执行步骤13，若尚未获取到IP地址，则执行步骤14；

步骤13：如图6所示，从AUTH状态切换到计费（ACCT）状态，在ACCT状态中，执行步骤S509；

步骤14：开启定时器，等待客户端获取IP地址；

步骤15：判断客户端是否获取到了IP地址（即，IP地址分配是否完成），若获取到了IP地址，则执行步骤13，否则，执行步骤16；

步骤16：判断定时器是否超时，若是，则执行步骤17，否则，返回步骤15；

步骤17：如图6所示，从CHECKIP状态切换到下线（LOGOFF）状态，在LOGOFF状态中，将用户下线，将端口的状态修改为未授权状态；

步骤S509，在ACCT状态中，设备端向RADIUS服务器发起计费开始请求报文RADIUSAccounting-Request；

步骤S510，RADIUS服务器核对用户名信息后，开始计费，并发出计费开始响应报文RADIUSAccounting-Response给设备端；

步骤S511，设备端接收到计费开始响应报文RADIUSAccounting-Response后，如图6所示，从ACCT状态切换到在线（ONLINE）状态；在在线状态中，设备端会定时向RADIUS服务器上报本段时间内用户访问资源的情况，发送实时计费请求报文RADIUSAccounting-Request；

步骤S512，RADIUS服务器收到RADIUSAccounting-Request后，更新用户访问的资源信息，然后发送实时计费响应报文RADIUSAccounting-Response；

步骤S512-1，执行IP联动方案的在线处理流程，如图8所示，包括以下步骤：

步骤21：处于ONLINE状态；

步骤22：判断是否需要检查IP地址，若是，则执行步骤23，否则，返回步骤21；

若IP地址变化触发重计费的功能或者IP地址变化触发下线的功能被使能了，则说明需要检查IP地址，若都没有被使能，则说明不需要检查IP地址。

步骤23：如图6所示，从ONLINE状态切换到CHECKIP状态，在CHECKIP状态中，开启定时器，然后，执行步骤24；

步骤24：判断定时器是否超时，若是，则关闭定时器，执行步骤25，否则，返回步骤24；

步骤25：判断客户端的IP地址是否发生了改变，若是，则执行步骤26，否则，返回步骤21；

例如，可以通过步骤S513-步骤S514，或者DHCPSNOOPING等来检测客户端的IP地址是否发生了改变。

步骤26：判断IP地址改变是否需要重新计费，若是，则执行步骤27，否则，执行步骤28；

若IP地址变化触发重计费的功能被使能了，则说明IP地址改变需要重新计费，否则，说明IP地址改变不需要重新计费。

步骤27：更新IP地址，并如图6所示，从CHECKIP状态切换到ACCT状态；

进入ACCT状态后，会结束针对原IP地址的计费，针对改变后的新IP地址重新执行步骤S509；

步骤28：判断IP地址改变是否需要下线，若是，则执行步骤29，否则，返回步骤21；

步骤29，如图6所示，从CHECKIP状态切换到LOGOFF状态。

步骤S513，用户在线期间，设备端会通过向客户端定期发送握手报文EAP-Request/Identity的方法，对用户的在线情况进行监测；

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

步骤S515，客户端可以发送EAPOL-Logoff给设备端，主动要求下线。设备端切换到下线状态，将用户下线，将端口的状态从授权状态改变成未授权状态。

实施例三

针对上述实施例一中的方法，本实施例提供了一种认证***中的设备端。该设备端可以是NAS等，本申请对此不做限定。

如图9所示，该设备端中包括以下模块：授权模块10和计费开始请求模块20，其中：

授权模块10，用于在用户认证成功后，将本设备连接用户的客户端的端口授权；

计费开始请求模块20，用于检测客户端在端口被授权后是否获取到了IP地址，并且，在检测到客户端获取到了IP地址之后，请求认证服务器开始计费。

其中，计费开始请求模块20中包括：第一判断单元、请求单元、第二判断单元、第三判断单元和切换单元，其中：

第一判断单元，用于判断计费开始依赖于IP地址获取的功能是否被使能；

请求单元，用于当本设备处于计费状态时，请求认证服务器开始计费；

第二判断单元，用于在本设备从认证状态切换到IP检查状态之后，判断客户端是否获取到了IP地址；

第三判断单元，用于若第二判断单元判断出客户端没有获取到IP地址，则开启定时器，判断客户端是否在定时器超时之前获取到了IP地址；

切换单元，用于若第一判断单元判断出计费开始依赖于IP地址获取的功能被使能，则将本设备从认证状态切换到IP检查状态；还用于若第二判断单元判断出客户端获取到了IP地址，则将本设备从IP检查状态切换到计费状态；还用于若第三判断单元判断出客户端在定时器超时之前获取到了IP地址，则将本设备从IP检查状态切换到计费状态。

另外，该设备端中还包括：下线处理模块，其中：

切换单元，还用于若第三判断单元判断出客户端在定时器超时之前没有获取到IP地址，则将本设备从IP检查状态切换到下线状态；

下线处理模块，用于当本设备处于下线状态时，将用户下线，并将端口的状态由授权状态修改为未授权状态。

另外，该设备端中还包括：状态切换模块、在线处理模块和IP检查处理模块，其中：

状态切换模块，用于在认证服务器开始计费成功之后，将本设备从计费状态切换到在线状态；还用于若在线处理模块判断出IP地址变化触发重计费的功能或者IP地址变化触发下线的功能被使能，则将本设备从在线状态切换到IP检查状态；还用于若IP检查处理模块判断出客户端的IP地址没有发生改变，则将本设备从IP检查状态切换到在线状态；还用于若IP检查处理模块判断出客户端的IP地址发生了改变，且IP地址变化触发重计费的功能被使能，则将本设备从IP检查状态切换到计费状态；

在线处理模块，用于当本设备处于在线状态时，判断IP地址变化触发重计费的功能或者IP地址变化触发下线的功能是否被使能，其中，IP地址变化触发重计费的功能和IP地址变化触发下线的功能不能同时被使能；

IP检查处理模块，用于在本设备从在线状态切换到IP检查状态之后，周期性地执行以下操作：判断客户端的IP地址是否发生了改变，若没有发生改变，则触发状态切换模块将本设备从IP检查状态切换到在线状态，若发生了改变，则判断IP地址变化触发重计费的功能或者IP地址变化触发下线的功能是否被使能，若IP地址变化触发重计费的功能被使能，则将记录的客户端的IP地址更新为改变后的IP地址，结束本次计费，触发状态切换模块将本设备从IP检查状态切换到计费状态。

另外，状态切换模块，还用于若IP检查处理模块判断出客户端的IP地址发生了改变，且IP地址变化触发下线的功能被使能，则将本设备从IP检查状态切换到下线状态；还用于若IP检查处理模块判断出客户端的IP地址发生了改变，且IP地址变化触发重计费的功能和IP地址变化触发下线的功能均没有被使能，则将本设备从IP检查状态切换到在线状态；

IP检查处理模块，还用于若判断出客户端的IP地址发生了改变，且IP地址变化触发重计费的功能和IP地址变化触发下线的功能均没有被使能，则将记录的客户端的IP地址更新为改变后的IP地址，触发状态切换模块将本设备从IP检查状态切换到在线状态。

其中，判断计费开始依赖于IP地址获取的功能、IP地址变化触发重计费的功能、或者IP地址变化触发下线的功能是否被使能的方式可以采用上述三种方式中的任意一种。

综上，本申请以上实施例可以达到以下技术效果：

（1）将802.1x认证全过程（包括上线和在线过程）与用户IP地址紧密结合，实现准确合理计费，同时增加IP监控的手段。

（2）对IP地址的获取和改变进行监控，监控手段灵活，能够通过客户端、设备端和认证服务器进行控制，对IP地址的监控手段覆盖了整个认证***的参与角色，不再单一的依赖于一种管理角色的一种控制手段。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (6)

1.一种认证***中的认证方法，所述认证***中包括：客户端、设备端和认证服务器，所述方法应用于所述设备端，其特征在于，所述方法包括：

在用户认证成功后，将本设备连接用户的客户端的端口授权；

在检测到所述客户端在所述端口被授权且获取到了因特网协议IP地址之后，请求认证服务器开始计费；

其中，在检测到所述客户端在所述端口被授权且获取到了IP地址之后，请求认证服务器开始计费的方法包括：判断计费开始依赖于IP地址获取的功能是否被使能，若被使能，则从认证状态切换到IP检查状态；在从所述认证状态切换到所述IP检查状态之后，判断所述客户端是否获取到了IP地址；若获取到了IP地址，则从所述IP检查状态切换到计费状态，当处于所述计费状态时，请求认证服务器开始计费；若没有获取到IP地址，则开启定时器，判断所述客户端是否在定时器超时之前获取到了IP地址，若是，则从所述IP检查状态切换到所述计费状态；否则，从所述IP检查状态切换到下线状态，当处于下线状态时，将所述用户下线，并将所述端口的状态由授权状态修改为未授权状态。

2.根据权利要求1所述的方法，其特征在于，在请求认证服务器开始计费之后，还包括：

在所述认证服务器开始计费成功之后，从所述计费状态切换到在线状态；

当处于所述在线状态时，判断IP地址变化触发重计费的功能或者IP地址变化触发下线的功能是否被使能，若是，则从所述在线状态切换到所述IP检查状态，其中，所述IP地址变化触发重计费的功能和所述IP地址变化触发下线的功能不能同时被使能；

在从所述在线状态切换到所述IP检查状态之后，周期性地执行以下操作：判断所述客户端的IP地址是否发生了改变；若没有发生改变，则从所述IP检查状态切换到所述在线状态；若发生了改变，则判断所述IP地址变化触发重计费的功能或者所述IP地址变化触发下线的功能是否被使能；若所述IP地址变化触发重计费的功能被使能，则将记录的所述客户端的IP地址更新为改变后的IP地址，结束本次计费，从所述IP检查状态切换到所述计费状态；若所述IP地址变化触发下线的功能被使能，则从所述IP检查状态切换到所述下线状态；若所述IP地址变化触发重计费的功能和所述IP地址变化触发下线的功能均没有被使能，则将记录的所述客户端的IP地址更新为改变后的IP地址，从所述IP检查状态切换到所述在线状态。

3.根据权利要求2所述的方法，其特征在于，判断所述计费开始依赖于IP地址获取的功能、所述IP地址变化触发重计费的功能、或者所述IP地址变化触发下线的功能是否被使能的方法包括：

根据本设备的配置信息进行判断，其中，所述配置信息中包括：所述计费开始依赖于IP地址获取的功能和/或所述IP地址变化触发重计费的功能被使能，或者，所述计费开始依赖于IP地址获取的功能和/或所述IP地址变化触发下线的功能被使能；

或者，根据接收到的客户端或认证服务器发来的控制信息进行判断，其中，所述控制信息用于指示所述计费开始依赖于IP地址获取的功能和/或所述IP地址变化触发重计费的功能是否被使能，或者，所述计费开始依赖于IP地址获取的功能和/或所述IP地址变化触发下线的功能是否被使能。

4.一种认证***中的设备端，所述认证***中包括：客户端、所述设备端和认证服务器，其特征在于，所述设备端包括：授权模块、计费开始请求模块和下线处理模块，其中，所述计费开始请求模块中包括：第一判断单元、请求单元、第二判断单元、第三判断单元和切换单元；

授权模块，用于在用户认证成功后，将本设备连接用户的客户端的端口授权；

计费开始请求模块，用于检测所述客户端在所述端口被授权后是否获取到了因特网协议IP地址，并且，在检测到所述客户端获取到了IP地址之后，请求认证服务器开始计费；

第一判断单元，用于判断计费开始依赖于IP地址获取的功能是否被使能；

请求单元，用于当本设备处于计费状态时，请求认证服务器开始计费；

第二判断单元，用于在本设备从认证状态切换到IP检查状态之后，判断所述客户端是否获取到了IP地址；

第三判断单元，用于若所述第二判断单元判断出所述客户端没有获取到IP地址，则开启定时器，判断所述客户端是否在定时器超时之前获取到了IP地址；

切换单元，用于若所述第一判断单元判断出所述计费开始依赖于IP地址获取的功能被使能，则将本设备从认证状态切换到IP检查状态；还用于若所述第二判断单元判断出所述客户端获取到了IP地址，则将本设备从所述IP检查状态切换到计费状态；还用于若所述第三判断单元判断出所述客户端在定时器超时之前获取到了IP地址，则将本设备从所述IP检查状态切换到所述计费状态；还用于若所述第三判断单元判断出所述客户端在定时器超时之前没有获取到IP地址，则将本设备从所述IP检查状态切换到下线状态；

所述下线处理模块，用于当本设备处于下线状态时，将所述用户下线，并将所述端口的状态由授权状态修改为未授权状态。

5.根据权利要求4所述的设备端，其特征在于，还包括：

状态切换模块，用于在所述认证服务器开始计费成功之后，将本设备从所述计费状态切换到在线状态；还用于若在线处理模块判断出IP地址变化触发重计费的功能或者IP地址变化触发下线的功能被使能，则将本设备从所述在线状态切换到所述IP检查状态；还用于若IP检查处理模块判断出所述客户端的IP地址没有发生改变，则将本设备从所述IP检查状态切换到所述在线状态；还用于若所述IP检查处理模块判断出所述客户端的IP地址发生了改变，且所述IP地址变化触发重计费的功能被使能，则将本设备从所述IP检查状态切换到所述计费状态；还用于若所述IP检查处理模块判断出所述客户端的IP地址发生了改变，且所述IP地址变化触发下线的功能被使能，则将本设备从所述IP检查状态切换到所述下线状态；还用于若所述IP检查处理模块判断出所述客户端的IP地址发生了改变，且所述IP地址变化触发重计费的功能和所述IP地址变化触发下线的功能均没有被使能，则将本设备从所述IP检查状态切换到所述在线状态；

在线处理模块，用于当本设备处于所述在线状态时，判断所述IP地址变化触发重计费的功能或者所述IP地址变化触发下线的功能是否被使能，其中，所述IP地址变化触发重计费的功能和所述IP地址变化触发下线的功能不能同时被使能；

IP检查处理模块，用于在本设备从所述在线状态切换到所述IP检查状态之后，周期性地执行以下操作：判断所述客户端的IP地址是否发生了改变，若没有发生改变，则触发所述状态切换模块将本设备从所述IP检查状态切换到所述在线状态，若发生了改变，则判断所述IP地址变化触发重计费的功能或者所述IP地址变化触发下线的功能是否被使能，若所述IP地址变化触发重计费的功能被使能，则将记录的所述客户端的IP地址更新为改变后的IP地址，结束本次计费，触发所述状态切换模块将本设备从所述IP检查状态切换到所述计费状态；还用于若判断出所述客户端的IP地址发生了改变，且所述IP地址变化触发重计费的功能和所述IP地址变化触发下线的功能均没有被使能，则将记录的所述客户端的IP地址更新为改变后的IP地址，触发所述状态切换模块将本设备从所述IP检查状态切换到所述在线状态。

6.根据权利要求5所述的设备端，其特征在于，判断所述计费开始依赖于IP地址获取的功能、所述IP地址变化触发重计费的功能、或者所述IP地址变化触发下线的功能是否被使能的方式包括：

根据本设备的配置信息进行判断，其中，所述配置信息中包括：所述计费开始依赖于IP地址获取的功能和/或所述IP地址变化触发重计费的功能被使能，或者，所述计费开始依赖于IP地址获取的功能和/或所述IP地址变化触发下线的功能被使能；

或者，根据接收到的客户端或认证服务器发来的控制信息进行判断，其中，所述控制信息用于指示所述计费开始依赖于IP地址获取的功能和/或所述IP地址变化触发重计费的功能是否被使能，或者，所述计费开始依赖于IP地址获取的功能和/或所述IP地址变化触发下线的功能是否被使能。