所选语种没有对应资源,请选择:

本站点使用Cookies,继续浏览表示您同意我们使用Cookies。Cookies和隐私政策>

提示

尊敬的用户,您的IE浏览器版本过低,为获取更好的浏览体验,请升级您的IE浏览器。

升级

S1720, S2700, S5700, S6720 V200R012(C00&C20) 配置指南-用户接入与认证

本文档介绍了用户接入与认证的配置,具体包括AAA配置、NAC配置和策略联动配置。
评分并提供意见反馈 :
华为采用机器翻译与人工审校相结合的方式将此文档翻译成不同语言,希望能帮助您更容易理解此文档的内容。 请注意:即使是最好的机器翻译,其准确度也不及专业翻译人员的水平。 华为对于翻译的准确性不承担任何责任,并建议您参考英文文档(已提供链接)。
Portal认证原理描述

Portal认证原理描述

Portal认证简介

定义

Portal认证通常也称为Web认证,一般将Portal认证网站称为门户网站。用户上网时,必须在门户网站进行认证,如果未认证成功,仅可以访问特定的网络资源,认证成功后,才可以访问其他网络资源。

优点
  • 一般情况下,客户端不需要安装额外的软件,直接在Web页面上认证,简单方便。
  • 便于运营,可以在Portal页面上进行业务拓展,如广告推送、责任公告、企业宣传等。
  • 技术成熟,被广泛应用于运营商、连锁快餐、酒店、学校等网络。
  • 部署位置灵活,可以在接入层或关键数据的入口作访问控制。
  • 用户管理灵活,可基于用户名与VLAN/IP地址/MAC地址的组合对用户进行认证。
认证系统

Portal认证系统如图2-18所示,其主要包括四个基本要素:客户端、接入设备、Portal服务器与认证服务器。

图2-18  Portal认证系统组网图
  • 客户端:安装有运行HTTP/HTTPS协议的浏览器的主机。
  • 接入设备:交换机、路由器等接入设备的统称,主要有三方面的作用。
    • 在认证之前,将认证网段内用户的所有HTTP/HTTPS请求都重定向到Portal服务器。
    • 在认证过程中,与Portal服务器、认证服务器交互,完成对用户身份认证、授权与计费的功能。
    • 在认证通过后,允许用户访问被管理员授权的网络资源。
  • Portal服务器:接收客户端认证请求的服务器系统,提供免费门户服务和认证界面,与接入设备交互客户端的认证信息。
  • 认证服务器:与接入设备进行交互,完成对用户的认证、授权与计费。
说明:

Portal服务器可以是接入设备之外的独立实体(外置Portal服务器),也可以是存在于接入设备之内的内嵌实体(内置Portal服务器)。内置Portal服务器的接入设备实现了简单的Portal服务器功能,仅能给用户提供通过Web方式上线、下线的基本功能,并不能完全替代独立的Portal服务器,也不支持外置独立服务器的任何扩展功能,例如不支持MAC优先的Portal认证。

通过内置Portal服务器进行Portal认证,由于不需要部署额外的Portal服务器,故增强了Portal认证的通用性。但是,受限于接入设备存储空间、功能和性能,内置Portal服务器适用于功能简单、接入人数少的场景,例如小型餐馆提供的连接Internet服务。

Portal认证协议

Portal协议包括Portal接入协议和Portal认证协议。
  • Portal接入协议:HTTP/HTTPS协议,描述了客户端和Portal服务器之间的协议交互。

    客户端通过HTTP/HTTPS协议依次向Portal服务器发起连接请求和Portal认证请求。具体认证流程请参见基于Portal协议的Portal认证流程基于HTTP/HTTPS协议的Portal认证流程

  • Portal认证协议:支持如下两种认证协议。

    • Portal协议:描述了Portal服务器和接入设备之间的协议交互,可以用来传递用户名和密码等参数。其兼容中国移动Portal 2.0协议,支持该协议的基本功能。

      收到客户端的Portal认证请求后,Portal服务器通过Portal协议向接入设备发起Portal认证请求(携带用户名和密码)。具体认证流程请参见基于Portal协议的Portal认证流程

    • HTTP/HTTPS协议:描述了客户端和接入设备之间的协议交互,可以用来传递用户名和密码等参数。

      收到客户端的Portal认证请求后,Portal服务器通过HTTP/HTTPS协议通知客户端向接入设备发起Portal认证请求,然后客户端通过HTTP/HTTPS协议向接入设备发起Portal认证请求(携带用户名和密码)。具体认证流程请参见基于HTTP/HTTPS协议的Portal认证流程

说明:

建议接入设备使用Portal协议与Portal服务器对接,如果Portal服务器不支持Portal协议,则接入设备可以使用HTTP/HTTPS协议。

使用内置Portal服务器进行Portal认证时,接入设备仅支持Portal协议。

HTTP/HTTPS协议可以作为Portal接入协议,也可以作为Portal认证协议,详情请参见RFC2616和RFC2818。这里重点介绍接入设备支持的Portal认证协议的相关内容。

Portal协议
报文格式

Portal协议报文由固定长度头和可变长度的属性字段组成,属性字段采用TLV(Type-Length-Value)格式。其报文格式如图2-19所示。

图2-19  报文格式

报文字段

Version

Portal协议的版本号,长度为1字节,默认取值为0x02。

Type

Portal协议的报文类型,长度为1字节。

报文类型 取值 含义
REQ_CHALLENGE 0x01 Portal服务器向接入设备发送的Challenge请求报文
ACK_CHALLENGE 0x02 接入设备对Portal服务器Challenge请求的响应报文
REQ_AUTH 0x03 Portal服务器向接入设备发送的认证请求报文
ACK_AUTH 0x04 接入设备对Portal服务器认证请求的响应报文
REQ_LOGOUT 0x05 Portal服务器向接入设备发送的下线请求报文
ACK_LOGOUT 0x06 接入设备对Portal服务器下线请求的响应报文
AFF_ACK_AUTH 0x07 Portal服务器向接入设备发送的认证成功响应报文
NTF_LOGOUT 0x08 接入设备向Portal服务器发送的用户被强制下线通知报文
REQ_INFO 0x09 Portal服务器向接入设备发送的信息询问报文
ACK_INFO 0x0a 接入设备对Portal服务器信息询问的应答报文
ACK_NTF_LOGOUT 0x0e Portal服务器通知接入设备用户强制下线成功
USER_SYN 0x10 Portal服务器向接入设备发送的用户信息同步请求报文
ACK_USER_SYN 0x11 接入设备对Portal服务器用户信息同步请求的响应报文
STATUS_NOTIFY 0x81 Portal服务器定时向接入设备发送的状态通知报文
ACK_STATUS_NOTIFY 0x82 接入设备对Portal服务器状态通知报文的响应报文
MAC_QUERY 0x30 接入设备对Portal服务器查询MAC缓存报文
ACK_MAC_QUERY 0x31 Portal服务器给接入设备发送的MAC缓存查询回应报文

AuthType

认证方式,长度为1字节。设备支持两种认证方式:

  • CHAP认证:取值为0,是一种三次握手认证,它采用密文方式传输用户名和密码。

  • PAP认证:取值为0x01,是一种两次握手认证,它采用明文方式传输用户名和密码。

CHAP认证方式才有REQ_CHALLENGE和ACK_CHALLENGE的交互步骤。CHAP认证保密性较好,更为安全可靠。如果是基于安全性的考虑,建议采用该方式。

Rsvd

目前为保留字段,长度为1字节,在所有报文中取值为0。

SerialNo

报文的序列号,长度为2字节,由Portal服务器随机生成。Portal服务器必须保证在同一个认证流程中所有报文的序列号相同;在不同认证流程中的报文序列号在一定时间内不得重复。

RequestID

报文ID,长度为2字节,由接入设备生成,RequestID不会重复。

UserIP

Portal用户的IP地址,长度为4字节。

UserPort

目前为保留字段,长度为2字节,在所有报文中取值为0。

ErrCode

错误码,长度为1字节。其和Type字段一起表示一定的意义。

  • Type值为0x01、0x03、0x07、0x09、0x0e、0x10、0x11、0x30、0x31、0x81、0x82时

    ErrCode字段无意义,取值为0。

  • Type值为0x02时

    • ErrCode值为0,表示接入设备通知Portal服务器Challenge请求成功。
    • ErrCode值为0x01,表示接入设备通知Portal服务器Challenge请求被拒绝。
    • ErrCode值为0x02,表示接入设备通知Portal服务器此链接已建立。
    • ErrCode值为0x03,表示接入设备通知Portal服务器有一个用户正在认证过程中,请稍后再试。
    • ErrCode值为0x04,表示接入设备通知Portal服务器此用户Challenge请求失败。
    • ErrCode值为0xfd,表示接入设备通知Portal服务器未找到此用户(用户已漫游或下线)。
  • Type值为0x04时

    • ErrCode值为0,表示接入设备通知Portal服务器此用户认证成功。
    • ErrCode值为0x01,表示接入设备通知Portal服务器此用户认证请求被拒绝。
    • ErrCode值为0x02,表示接入设备通知Portal服务器此链接已建立。
    • ErrCode值为0x03,表示接入设备通知Portal服务器有一个用户正在认证过程中,请稍后再试。
    • ErrCode值为0x04,表示接入设备通知Portal服务器此用户认证失败(发生错误,例如用户名错误)。
    • ErrCode值为0x05,表示接入设备通知Portal服务器此用户认证失败(Portal在线用户数已达到最大值)。
    • ErrCode值为0x06,表示接入设备通知Portal服务器此用户认证失败(设备正在对该终端进行其他方式的认证)。
    • ErrCode值为0xfd,表示接入设备通知Portal服务器未找到此用户(用户已漫游或下线)。
  • Type值为0x05时

    • ErrCode值为0,表示Portal服务器发给接入设备的请求下线报文。
    • ErrCode值为0x01,表示Portal服务器没有收到接入设备对各种请求的响应报文时,定时器超时后Portal服务器发给接入设备的报文。
  • Type值为0x06时

    • ErrCode值为0,表示接入设备通知Portal服务器此用户下线成功。
    • ErrCode值为0x01,表示接入设备通知Portal服务器此用户下线被拒绝。
    • ErrCode值为0x02,表示接入设备通知Portal服务器此用户下线失败。
  • Type值为0x08时

    ErrCode值为0x02,表示接入设备通知Portal服务器此用户被强制下线。

  • Type值为0x0a时

    • ErrCode值为0,表示接入设备通知Portal服务器此询问消息处理成功。
    • ErrCode值为0x01,表示接入设备通知Portal服务器此询问消息处理失败(不支持该功能)。
    • ErrCode值为0x02,表示接入设备通知Portal服务器此询问消息处理失败(发生错误,例如询问消息格式错误)。

AttrNum

属性字段中属性的个数,长度为1字节,属性字段中最多有255个属性。

Authenticator

验证字,长度为16字节。其是通过MD5算法对各字段计算后得出的数据。

Attribute

一个可变长字段,由多个属性组合而成,每个属性的格式为TLV格式。

  • AttrType:属性类型,长度为1字节。

  • AttrLen:属性字段的长度,长度为1字节,其值是AttrType、AttrLen、AttrValue三个字段的长度之和。

  • AttrValue:具体的属性值,如下表所示。例如用户名、密码等,长度有些可变,有些固定,但最长不能超过253字节。

Attribute AttrType AttrValue长度 说明 使用该属性的消息类型
UserName 0x01 1~253 用户名,具体格式为:“用户名”+“@”+“域名”,例如test@huawei.com REQ_AUTH
PassWord 0x02

1~128

用户提交的密码 REQ_AUTH
Challenge 0x03 16 CHAP方式加密的认证字 ACK_CHALLENGE
ChapPassWord 0x04 16 经过CHAP方式加密后的密码 REQ_AUTH
TextInfo 0x05 2~253 用于将RADIUS等第三方鉴权设备的提示信息透传到Portal服务器。该属性所携带的内容为字符串,但是不包括字符串结束符‘\0’。该属性在同一个报文中允许出现多个,建议只携带1个该属性。 ACK_AUTH、REQ_AUTH(仅Portal 1.0版本)
Port 0x08 1~51

端口号,其格式为:

  • 类型+长度(在REQ_INFO报文)
  • 类型+长度+内容(在ACK_INFO报文)
REQ_INFO、ACK_INFO
Bas_IP 0x0a 4 用户漫游后的AC IP地址 ACK_AUTH、ACK_CHALLENGE
User_Mac 0x0b 6 用户的MAC地址 ACK_AUTH、ACK_LOGOUT、NTF_LOGOUT、ACK_CHALLENGE、ACK_INFO、REQ_CHALLENGE、REQ_AUTH、REQ_LOGOUT
User_Private_IP 0x0d 4~252 用户的IPv4地址 USER_SYN、ACK_USER_SYN
WebAuthenInfo 0x40 1~247 用于将用户在Web页面上的输入传递给RADIUS服务器,可携带多个 REQ_AUTH
User_IPV6 0xf1 16 用户的IPv6地址 REQ_CHALLENGE、ACK_CHALLENGE、REQ_AUTH、ACK_AUTH、REQ_LOGOUT、ACK_LOGOUT、AFF_ACK_AUTH、NTF_LOGOUT、REQ_INFO、ACK_INFO
HTTP/HTTPS协议
简介
设备支持使用HTTP/HTTPS协议与客户端对接:
  • 超文本传输协议HTTP(HyperText Transfer Protocol)是一种用于传送万维网WWW(World Wide Web)数据的传输协议。

    关于HTTP协议的详细内容请参考RFC2616。

  • 超文本传输安全协议HTTPS(Hypertext Transfer Protocol Secure),也常称为HTTP over TLS(Hyper Text Transfer Protocol over Transport Layer Security)或HTTP over SSL(Hyper Text Transfer Protocol over Secure Socket Layer),是以安全为目标的HTTP通道,简单讲是HTTP的安全版。HTTPS通过HTTP进行通信,并使用SSL/TLS来加密数据。

    HTTPS主要用来身份认证,保护数据的隐私与完整性。关于HTTPS协议的详细内容请参考RFC2818。

客户端请求方法

Portal认证时,Portal服务器会通知客户端使用HTTP/HTTPS协议向接入设备发起Portal认证请求,然后客户端将Portal认证请求转发给接入设备,请求报文中会携带HTTP请求方法、HTTP请求正文(即请求的数据,包含用户名和密码等参数)等内容。

目前设备支持两种HTTP请求方法:

  • POST:请求的数据放置在HTTP请求包的包体中,不作为URL的一部分,不易被窃取,安全性较高。设备默认支持此请求方法。

  • GET:请求的数据会附加在URL之后,以?分割URL和数据。数据在URL中对所有人都是可见的,易被窃取,安全性较差。

设备收到认证请求后,会根据参数名称解析请求报文来获取用户名和密码等参数,然后将获取的用户名和密码向RADIUS服务器进行认证。缺省情况下,请求报文中的参数名称必须符合特定的规范(如表2-10所示),否则设备无法解析请求报文,导致用户认证失败。例如设备收到的POST报文参数(username=abc&password=abc&client_mac=112233445566&initurl=http://portalserver.example.com/login),设备解析POST报文失败,因为POST报文中的用户MAC地址参数名称client_mac与设备默认的用户MAC地址识参数名称macaddress不一致。

因此,使用HTTP/HTTPS协议进行Portal认证时,用户必须确保Portal服务器上设置的参数名称与设备一致。

表2-10  请求报文的参数
参数 默认参数名称(识别关键字)
用户操作命令 cmd
用户登录 login
用户注销 logout
用户初始登录的URL initurl
用户名 username
密码 password
用户IP地址 ipaddress
用户MAC地址 macaddress

用户登录成功/失败、用户注销成功/失败时,在设备上可以设置回复信息或重定向URL给用户。

Portal认证方式

按照网络中实施Portal认证的网络层次来分,Portal认证方式分为两种:二层认证方式和三层认证方式。

  • 当客户端与接入设备之间为二层网络时,即客户端与接入设备直连(或之间只有二层设备存在),接入设备可以学习到客户端的MAC地址,则接入设备可以利用IP地址和MAC地址来识别用户,此时可配置Portal认证为二层认证方式。

    二层认证流程简单,安全性高,但由于限制了用户只能与接入设备处于同一网段,所以组网灵活性不高。

  • 当客户端与接入设备之间包含三层网络时,即客户端与接入设备之间存在三层转发设备,接入设备不能获取到认证客户端的MAC地址,只能以IP地址作为用户的唯一标识,此时需要将Portal认证配置为三层认证方式。

    三层认证组网灵活,容易实现远程控制,但由于只能以IP地址作为用户的唯一标识,所以安全性不高。

Portal认证流程

认证的第一件事情就是发起认证,有两种认证触发方式:

  • 主动认证

    用户通过浏览器主动访问Portal认证网站时,即在浏览器中直接输入Portal服务器的网络地址,然后在显示的网面中输入用户名和密码进行认证,这种开始Portal认证过程的方式即为主动认证,即由用户自己主动访问Portal服务器发起的身份认证。

  • 强制认证(重定向认证)

    用户输入的访问地址不是Portal认证网站地址时,将被强制访问Portal认证网站(通常称为重定向),从而开始Portal认证过程,这种方式称作强制认证。

具体认证流程请参见:

基于Portal协议的Portal认证流程

这里主要介绍外置Portal服务器的二层认证流程。对于内置Portal服务器的认证流程,与外置Portal服务器的认证流程类似,这里不再赘述。

在二层认证方式下,用户上线时的报文交互流程如图2-20所示。对于三层认证方式,客户端与接入设备之间没有建立预连接过程,其余报文处理流程跟二层认证完全一致。

图2-20  基于Portal协议的Portal认证流程图
  1. 在认证之前客户端与接入设备之间建立起预连接,即客户端用户在认证成功之前在接入设备上已建立用户在线表项,并且只有部分网络访问权限。

  2. 客户端发起HTTP连接请求。

  3. 接入设备收到HTTP连接请求报文时,如果是访问Portal服务器或免认证网络资源的HTTP报文,则接入设备允许其通过;如果是访问其它地址的HTTP报文,则接入设备将其URL地址重定向到Portal认证页面。

  4. 客户端根据获得的URL地址向Portal服务器发起HTTP连接请求。

  5. Portal服务器向客户端返回Portal认证页面。

  6. 用户在Portal认证页面输入用户名和密码后,客户端向Portal服务器发起Portal认证请求。
  7. Portal服务器收到Portal认证请求后,如果Portal服务器与接入设备之间采用CHAP认证,则Portal服务器向接入设备发起Portal挑战字请求报文(REQ_CHALLENGE);如果Portal服务器与接入设备之间采用PAP认证,则接入设备直接进行第9步。
  8. 接入设备向Portal服务器回应Portal挑战字应答报文(ACK_CHALLENGE)。
  9. Portal服务器将用户输入的用户名和密码封装在Portal认证请求报文(REQ_AUTH)中,并发送给接入设备。
  10. 接入设备根据获取到的用户名和密码,向RADIUS服务器发送RADIUS认证请求(ACCESS-REQUEST)。
  11. RADIUS服务器对用户名和密码进行认证。如果认证成功,则RADIUS服务器向接入设备发送认证接受报文(ACCESS-ACCEPT);如果认证失败,则RADIUS服务器返回认证拒绝报文(ACCESS-REJECT)。

    由于RADIUS协议合并了认证和授权的过程,因此认证接受报文中也包含了用户的授权信息。

  12. 接入设备根据接收到的认证结果接入/拒绝用户。如果允许用户接入,则接入设备向RADIUS服务器发送计费开始请求报文(ACCOUNTING-REQUEST)。
  13. RADIUS服务器返回计费开始响应报文(ACCOUNTING-RESPONSE),并开始计费,将用户加入自身在线用户列表。
  14. 接入设备向Portal服务器返回Portal认证结果(ACK_AUTH),并将用户加入自身在线用户列表。
  15. Portal服务器向客户端发送认证结果报文,通知客户端认证成功,并将用户加入自身在线用户列表。
  16. Portal服务器向接入设备发送认证应答确认(AFF_ACK_AUTH)。
基于HTTP/HTTPS协议的Portal认证流程

在二层认证方式下,用户上线时的HTTP协议认证报文交互过程如图2-21所示。对于三层认证方式,客户端与接入设备之间没有建立预连接过程,其余报文处理流程跟二层认证完全一致。

HTTPS协议认证报文交互过程与HTTP类似,区别在于HTTPS报文经过加解密处理。

图2-21  基于HTTP协议的Portal认证流程图
  1. 在认证之前客户端与接入设备之间建立起预连接,即客户端用户在认证成功之前在接入设备上已建立用户在线表项,并且只有部分网络访问权限。

  2. 客户端发起HTTP连接请求。

  3. 接入设备收到HTTP连接请求时,如果是访问Portal服务器或免认证网络资源的HTTP报文,则接入设备允许其通过;如果是访问其它地址的HTTP报文,则接入设备将其URL地址重定向到Portal认证页面。

  4. 客户端根据获得的URL地址向Portal服务器发起HTTP连接请求。

  5. Portal服务器向客户端返回Portal认证页面。

  6. 用户在Portal认证页面输入用户名和密码后,客户端向Portal服务器发起Portal认证请求。
  7. Portal服务器通知客户端向接入设备发起Portal认证请求。
  8. 客户端向接入设备发起Portal认证请求(HTTP POST/GET)。
  9. 接入设备根据获取到的用户名和密码,向RADIUS服务器发送RADIUS认证请求(ACCESS-REQUEST)。
  10. RADIUS服务器对用户名和密码进行认证。如果认证成功,则RADIUS服务器向接入设备发送认证接受报文(ACCESS-ACCEPT);如果认证失败,则RADIUS服务器返回认证拒绝报文(ACCESS-REJECT)。

    由于RADIUS协议合并了认证和授权的过程,因此认证接受报文中也包含了用户的授权信息。

  11. 接入设备根据接收到的认证结果接入/拒绝用户。如果允许用户接入,则接入设备向RADIUS服务器发送计费开始请求报文(ACCOUNTING-REQUEST)。
  12. RADIUS服务器返回计费开始响应报文(ACCOUNTING-RESPONSE),并开始计费,将用户加入自身在线用户列表。
  13. 接入设备向客户端返回Portal认证结果,并将用户加入自身在线用户列表。

Portal认证授权

认证用于确认尝试接入网络的用户身份是否合法,而授权则用于指定身份合法的用户所能拥有的网络访问权限,即用户能够访问哪些资源。授权最基础也是最常使用的参数是ACL和UCL组,此处以RADIUS授权进行说明,其他授权方式的授权方法以及更多可授权的参数请参见AAA授权方案

ACL
用户认证成功后,认证服务器将指定ACL授权给用户,则设备会根据该ACL对用户报文进行控制。
  • 如果用户报文匹配到该ACL中动作为permit的规则,则允许其通过。
  • 如果用户报文匹配到该ACL中动作为deny的规则,则将其丢弃。
RADIUS服务器授权ACL有两种方法:
  • 授权静态ACL:RADIUS服务器通过RADIUS标准属性Filter-Id将ACL ID授权给用户。为使授权的ACL生效,需要提前在设备上配置相应的ACL及规则。
  • 授权动态ACL:RADIUS服务器通过华为RADIUS扩展属性HW-Data-Filter将ACL ID及其ACL规则授权给用户。ACL ID及其ACL规则需要在RADIUS服务器上配置,设备上不需要配置。
UCL
用户控制列表UCL组(User Control List)是网络成员的集合。UCL组里面的成员,可以是PC、手机等网络终端设备。借助UCL组,管理员可以将具有相同网络访问策略的一类用户划分为同一个组,然后为其部署一组网络访问策略,满足该类别所有用户的网络访问需求。相对于为每个用户部署网络访问策略,基于UCL组的网络控制方案能够极大的减少管理员的工作量。RADIUS服务器授权UCL组有两种方式:
  • 授权UCL组名称:RADIUS服务器通过RADIUS标准属性Filter-Id将UCL组名称授权给指定用户。
  • 授权UCL组ID:RADIUS服务器通过华为RADIUS扩展属性HW-UCL-Group将UCL组ID授权给指定用户。
无论是哪一种授权UCL组方式,都必须提前在设备上配置相应的UCL组及UCL组的网络访问策略。
free-rule

用户认证成功之前,为满足用户基本的网络访问需求,需要用户认证成功前就能获取部分网络访问权限。可在free-rule模板中配置free-rule规则,满足用户的认证成功前的网络访问需求。

用户的free-rule可以通过普通的free-rule定义,也可以通过ACL定义。普通的free-rule由IP地址、MAC地址、接口、VLAN等参数确定;通过ACL定义的free-rule由ACL规则确定。两种方式定义的free-rule都能够指定用户无需认证就可以访问的目的IP地址。除此之外,ACL定义的free-rule还能够指定用户认证成功前就可以访问的目的域名。

基于域名定义用户的free-rule有时要比基于IP地址简单方便。例如,某些认证用户由于没有认证账号,必须首先在运营商提供的官方网站上注册申请会员账号;或者通过微博、微信等第三方账号进行登录。这就要求用户认证通过前,能够访问特定的网站。由于用户记忆网站的域名要比记忆其IP地址容易的多,所以,此时可以通过ACL定义的free-rule,指定用户认证成功前即可访问以上网站域名。

Portal认证用户下线

当用户已下线,而接入设备、RADIUS服务器和Portal服务器未感知到该用户已下线时,会产生以下问题:
  • RADIUS服务器仍会对该用户进行计费,造成误计费。
  • 存在非法用户仿冒合法用户IP地址和MAC地址接入网络的风险。
  • 已下线用户数量过多的情况下,还会占用设备用户规格,可能会导致其他用户无法接入网络。

因此,接入设备要能够及时感知到用户已下线,删除该用户表项,并通知RADIUS服务器停止对该用户进行计费。

用户下线分为客户端主动下线、接入设备控制用户下线、认证服务器强制用户下线和Portal服务器强制用户下线。

客户端主动下线

由用户发起的主动下线,例如用户点击注销按钮,客户端向Portal服务器发送用户注销请求。

对于Portal协议,Portal服务器收到用户的下线请求后,会通知客户端下线成功,而不需要等待接入设备对下线的确认。对于HTTP/HTTPS协议,Portal服务器收到用户的下线请求后,会通知客户端向接入设备发送用户下线通知。

Portal协议

具体下线流程如图2-22所示。

图2-22  客户端主动下线流程图
  1. 客户端向Portal服务器发送用户注销请求。
  2. Portal服务器向客户端发送用户注销响应,并向接入设备发送用户下线通知报文(REQ_LOGOUT)。
  3. 接入设备向RADIUS服务器发送停止计费请求报文(ACCOUNTING-REQUEST),并将用户下线。同时,接入设备向Portal服务器发送用户下线响应报文(ACK_LOGOUT)。

    Portal服务器收到用户下线响应后,将用户下线。

  4. RADIUS服务器返回停止计费响应报文(ACCOUNTING-RESPONSE),并将用户下线。

HTTP/HTTPS协议

具体下线流程如图2-23所示,以HTTP协议为例。
图2-23  客户端主动下线流程图
  1. 客户端向Portal服务器发送用户注销请求。
  2. Portal服务器通知客户端向接入设备发送用户注销请求,并将用户下线。
  3. 客户端向接入设备发送用户注销请求。
  4. 接入设备向RADIUS服务器发送停止计费请求报文(ACCOUNTING-REQUEST),并将用户下线。同时,接入设备向客户端发送用户注销响应报文。
  5. RADIUS服务器返回停止计费响应报文(ACCOUNTING-RESPONSE),并将用户下线。
接入设备控制用户下线

接入设备控制用户下线有两种方式:

  • 在接入设备上执行命令强制指定用户下线。
  • 在接入设备上配置用户探测功能,用于探测用户是否在线。当用户在指定的时间内无响应,则认为用户下线,删除用户表项。

具体下线流程如图2-24所示。这里以Portal协议为例介绍下线探测的下线流程,对于HTTP/HTTPS协议,接入设备不会向Portal服务器发送用户下线通知。

图2-24  用户下线探测流程图
  1. 下线探测过程。

    接入设备获取到客户端IP地址,启动下线探测定时器,周期为time-length(通过命令portal timer offline-detect time-length)。在T时间内(T = time-length/3)收到客户端报文,接入设备认为用户在线,并且在T时刻会重置下线探测定时器。在T时间内未收到客户端报文时,接入设备每隔T时间向客户端发送ARP请求报文,如果连续两次没有收到客户端的ARP请求的应答报文或其他报文(即下线探测周内没有收到客户端的报文),接入设备认为用户已下线。

  2. 接入设备向Portal服务器发送用户下线通知(NTF_LOGOUT),并将用户下线。同时,接入设备向RADIUS服务器发送停止计费请求报文(ACCOUNTING-REQUEST)。

  3. Portal服务器向接入设备发送用户下线响应报文(AFF_ACK_LOGOUT),并将用户下线。RADIUS服务器向接入设备发送停止计费响应报文(ACCOUNTING-RESPONSE),并将用户下线。

认证服务器强制用户下线

服务器强制用户下线有以下方式:

  • RADIUS服务器可通过DM报文(Disconnect Message)强制用户下线。DM是指用户离线报文,即由RADIUS服务器端主动发起的强迫用户下线的报文。
  • RADIUS服务器通过授权RADIUS标准属性Session-Timeout和Termination-Action。其中,Session-Timeout为用户在线时长定时器,Termination-Action属性值为0表示将用户下线。当用户在线的时长达到定时器指定的数值时,设备会将用户下线。

具体下线流程如图2-25所示,以RADIUS服务器通过DM报文强制用户下线为例。

图2-25  认证服务器强制用户下线流程图
  1. RADIUS服务器向接入设备发送用户下线请求(DM Request)。

  2. 接入设备向Portal服务器发送下线通知(NTF_LOGOUT),并将用户下线。同时,接入设备向RADIUS服务器发送下线响应(DM ACK)及停止计费请求报文(ACCOUNTING-REQUEST)。

    使用HTTP/HTTPS协议时,接入设备不会向Portal服务器发送下线通知。

  3. Portal服务器向接入设备发送用户下线响应报文(AFF_ACK_LOGOUT),并将用户下线。RADIUS服务器向接入设备发送停止计费响应报文(ACCOUNTING-RESPONSE),并将用户下线。

Portal服务器强制用户下线

当管理员注销用户或Portal服务器主动探测发现用户已经离线等事件发生时,Portal服务器将用户下线,并向接入设备发送下线通知。

具体下线流程如图2-26所示。这里以使用Portal协议的Portal服务器为例介绍下线流程,使用HTTP/HTTPS协议的Portal服务器强制用户下线时直接将用户下线,不会通知接入设备将用户下线。

图2-26  Portal服务器强制用户下线流程图
  1. Portal服务器向接入设备发送用户下线通知报文(REQ_LOGOUT)。
  2. 接入设备向RADIUS服务器发送停止计费请求报文(ACCOUNTING-REQUEST),并将用户下线。同时,接入设备向Portal服务器发送用户下线响应报文(ACK_LOGOUT)。

    Portal服务器收到用户下线响应后,将用户下线。

  3. RADIUS服务器返回停止计费响应报文(ACCOUNTING-RESPONSE),并将用户下线。

Portal定时器

表2-11所示,接入设备支持以下Portal定时器。

表2-11  Portal定时器
Portal定时器 功能 适用场景
用户静默定时器

用来防止用户认证失败时频繁认证,形成了一种DoS攻击,浪费系统资源。

适用于使用Portal或HTTP/HTTPS协议的外置Portal服务器,或者使用Portal协议的内置Portal服务器场景。
Portal服务器探测定时器

用来防止接入设备与Portal服务器之间出现网络故障导致通信中断或Portal服务器本身出现故障时,已经在线的Portal用户无法正常下线或新的Portal认证用户无法上线。

适用于使用Portal协议的外置Portal服务器场景。
用户信息同步定时器

用来防止接入设备与Portal服务器之间出现网络故障导致通信中断或Portal服务器本身出现故障时,已经在线的Portal用户无法正常下线,造成接入设备与Portal服务器用户信息不一致以及计费不准确问题。

适用于使用Portal协议的外置Portal服务器场景。
用户下线重传定时器

用来防止接入设备与Portal服务器之间的网络不稳定、存在丢包等现象时,Portal服务器接收不到接入设备发送的用户下线报文,出现用户在接入设备上显示已经下线,在Portal服务器上显示仍然在线的情况。

适用于使用Portal协议的外置Portal服务器场景。
内置Portal服务器心跳探测定时器

用来防止用户关闭浏览器、网络异常断开等缘故造成用户下线时,接入设备上仍保留该用户信息,造成计费不准确或其他用户无法上线等问题。

适用于使用Portal协议的内置Portal服务器场景。
用户静默定时器

Portal认证期间,如果用户输入无效的用户名或密码,则接入设备会收到认证服务器的认证拒绝报文,并将认证结果通知给Portal服务器。当该用户频繁认证时,接入设备需不断地处理此认证请求,这样就形成了一种DoS攻击,一方面造成系统资源的浪费,另一方面存在攻击者通过多次尝试输入用户名和密码的方式暴力破解用户名和密码的风险。

为了解决上述问题,接入设备提供了一种用户静默功能。用户在60秒内认证失败的次数超过指定的次数(通过命令portal quiet-times fail-times)时,接入设备会将该用户静默一段时间(通过命令portal timer quiet-period quiet-period-value),在静默期间,接入设备会丢弃该用户的Portal认证请求。具体静默流程如图2-27所示,以使用Portal协议认证为例

图2-27  用户被静默流程图
Portal服务器探测定时器

Portal认证期间,如果接入设备与Portal服务器之间出现网络故障导致通信中断或Portal服务器本身出现故障,则会造成新的Portal用户无法上线,已经在线的Portal用户也无法正常下线。

为了解决上述问题,接入设备提供了一种Portal服务器探测功能。其通过Portal服务器的心跳报文定期发送给接入设备,接入设备通过检测此报文来判断服务器的可达状态,如果接入设备在指定的探测周期内(通过命令server-detect interval interval-period)收到Portal心跳报文或者其它认证报文,且验证其正确,则认为此次探测成功且服务器可达(状态为Up),否则认为此次探测失败。当对某一Portal服务器连续探测失败次数超过最大次数(通过命令server-detect max-times times)时,接入设备会将该Portal服务器的状态由Up改变为Down。

同时,接入设备将会做出以下动作,使管理员能够实时掌握网络中Portal服务器的状态或保证用户一定的网络访问权限。

  • 发送告警:Portal服务器可达或者不可达的状态改变时,发送告警信息给网管,其中记录了Portal服务器IP地址以及该服务器的当前状态。
  • 发送日志:Portal服务器可达或者不可达的状态改变时,发送日志信息给网管,其中记录了Portal服务器IP地址以及该服务器的当前状态。
  • 启用Portal逃生机制:状态为Up的Portal服务器数目小于或等于设置的最小值(通过命令server-detect critical-num critical-num)时,暂时取消接口的Portal认证,允许所有Portal用户访问指定的网络资源。之后,当接入设备收到某Portal服务器的心跳报文,或者收到其它认证报文(例如用户下线报文)时,接入设备会将该Portal服务器的状态由Down改变为Up,如果状态为Up的Portal服务器数目大于设置的最小值,则恢复该接口的Portal认证功能。

具体探测流程如图2-28所示。

说明:

建议在接入设备上配置的Portal服务器探测周期interval-period大于在Portal服务器上配置的心跳报文周期。

图2-28  Portal服务器探测流程图
用户信息同步定时器

用户上线后,如果接入设备与Portal服务器之间出现网络故障导致通信中断或Portal服务器本身出现故障,使得已经在线的Portal用户无法正常下线。这将可能会导致设备与Portal服务器用户信息不一致以及计费不准确问题。

为了解决上述问题,接入设备提供了一种Portal用户信息同步功能。该功能利用了Portal同步报文的发送及检测机制,具体实现如下:

  1. Portal服务器周期性地(周期为Tps)将在线用户信息通过用户信息同步请求报文(USER_SYN)发送给接入设备。
  2. 接入设备在开启Portal用户信息同步功能之后,即启动用户信息同步定时器,在用户信息同步周期内(通过命令user-sync interval interval-period),收到用户同步请求报文后,将其中携带的在线用户信息与自己的在线用户信息进行对比:
    • 如果发现同步请求报文中有设备上不存在的用户信息,则将这些自己没有的用户信息通过用户同步请求的响应报文(ACK_USER_SYN)反馈给Portal服务器,Portal服务器将删除这些用户信息。
    • 如果发现同步请求报文中的用户信息在设备上都存在,则设备不对该同步请求报文进行响应,只是将这些用户标记为已同步。对于不在同步请求报文中的用户不置同步标记,如果某用户信息在一个用户信息同步周期内,都未在Portal服务器发送过来的用户同步请求报文中出现过,则认为该用户同步失败一次,当在用户信息同步最大失败次数(通过命令user-sync max-times times)内均是此情况时,设备会将该用户强制下线。

具体同步流程如图2-29所示。

说明:

该功能仅适用于使用Portal协议的外置Portal服务器认证场景。目前接入设备仅支持和华赛TSM Portal服务器同步用户信息。

建议接入设备配置的interval-period x times的值应该大于Portal服务器发送同步请求报文的时间间隔,否则设备可能会在达到最大失败次数后,由于收不到Portal服务器的同步请求报文,将用户强制下线。

图2-29  用户信息同步流程图
用户下线重传定时器

Portal认证期间,接入设备使Portal认证用户下线后,会发送用户下线报文(NTF-LOGOUT)通知Portal服务器将用户信息删除。如果接入设备与Portal服务器之间的网络不稳定、存在丢包等现象,Portal认证用户下线后,可能导致Portal服务器接收不到接入设备发送的用户下线报文,出现用户在接入设备上显示已经下线,在Portal服务器上显示仍然在线的情况。

为使Portal服务器能够接收到用户下线报文,保证Portal服务器上的用户在线信息正确,接入设备提供用户下线报文重传功能,在用户下线重传周期period内,接入设备没有收到Portal服务器的用户下线应答报文,会重传一次用户下线报文,最多重传times次(通过命令portal logout resend times timeout period)。

具体下线流程如图2-30所示。

图2-30  用户下线流程图
内置Portal服务器心跳探测定时器

使用内置Portal服务器进行Portal认证时,如果由于用户关闭浏览器、网络异常断开等缘故造成用户下线,此时接入设备上可能仍保留该用户信息,这会造成计费不准确等问题。另一方面,由于接入设备允许接入的用户数是有限的,若用户异常下线而设备上仍保留用户信息,则可能导致其他用户不能接入网络。

为了解决上述问题,接入设备提供了一种内置Portal服务器心跳探测功能。它是在用户认证通过后,推送给用户一个连接保持页面,表示该用户处于认证状态。这个连接保持页面中嵌入心跳程序,定期向接入设备发送心跳报文表示该用户在线。如果在指定的心跳探测时间内(通过命令portal local-server keep-alive interval interval-value)接入设备没有收到用户发送的心跳报文或认证报文,则可以认为该用户异常离线,并指定该用户下线。具体心跳探测流程如图2-31所示。

内置Portal服务器的心跳探测模式分为强制探测模式和自动探测模式。
  • 强制探测模式:对于所有用户,如果在指定的时间内接入设备没有收到过用户的心跳报文,则指定用户下线。
  • 自动探测模式:设备会检测用户客户端网页浏览器是否支持心跳程序,如果支持,则采用强制探测模式对该用户进行探测;如果不支持,则不对该用户进行探测。建议采用该模式,避免浏览器不支持心跳程序导致用户下线。
说明:

目前Windows7系统下浏览器IE8、firefox3.5.2、chrome28.0.1500.72、opera12.00支持心跳程序。

使用Java1.7及以上版本的浏览器不支持心跳程序。

图2-31  内置Portal服务器心跳探测流程图

定制内置Portal服务器登录页面

当用户使用内置Portal服务器进行认证时,作为内置Portal服务器的设备会向用户强制推送登录页面,随后用户在登录页面上输入用户名和密码即可进行认证。

设备支持对登录页面进行自定义设计,以满足用户的个性化需求,例如用户可以在登录页面上加载Logo图片、广告图片、使用说明、免责声明,也可以更改登录页面的背景图片或背景颜色。

图2-32所示,用户使用默认的登录页面进行登录。

图2-32  初始登录页面

图2-33所示,用户执行命令portal local-server logo load logo-file在登录页面上加载了Logo图片。Logo图片的大小需小于等于128K,推荐大小591*80像素。

图2-33  带有Logo图片的登录页面

图2-34所示,用户执行命令portal local-server ad-image load ad-image-file在登录页面上加载了广告图片。广告图片的大小需小于等于256K,推荐大小670*405像素。

图2-34  带有广告图片的登录页面

图2-35所示,用户执行命令portal local-server page-text load string在登录页面上加载了使用说明页面。

图2-35  带有使用说明页面的登录页面

图2-36所示,用户执行命令portal local-server policy-text load string在登录页面上加载了免责声明页面。

图2-36  带有免责声明页面的登录页面

图2-37所示,用户执行命令portal local-server background-image load { background-image-file | default-image1 }更改了登录页面的背景图片。

图2-37  更改背景图片的登录页面
翻译
下载文档
更新时间:2018-12-24

文档编号:EDOC1100038441

浏览量:30887

下载量:1238

平均得分:
本文档适用于这些产品
相关版本
相关文档
Share
上一页 下一页