portal配置总结
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
1.portal简介和认证流程:
portal是一种用web页面来进行认证的认证机制,通过提供给上网用户一个web页面访问点进行用户身份认证,在认证成功前用户不能真正上网,访问任何页面都会被强制转换到portal提供的认证页面。
Portal认证的实现:
在用户端不用安装专门的客户端,只需浏览器即可。
通过ac,portal,radius服务器,用户四者的数据交互完成portal认证的整个流程。
Portal认证流程主要分为以下几步:
1.用户与AC交互
用户发起http请求,AC在配置的制定接口监听到http请求后,向用户返回重定向报文(http 302),用户访问302报文提供的portal页面地址,开始与portal进行交互:
(由用户10.1.1.100向5.1.1.1发起的http请求,ac监听到以后,返回一个http302报文,其中包含portal页面的地址,并把源ip填写成5.1.1.1,),用户根据该地址,与
针对这一步骤的说明:
1)Iptables介绍:
ac对报文监听和阻截的功能通过iptables实现,iptables是unix 的内置firewall机制,由一系列的规则链表组成,链表的每一表项包括对源,目的,匹配后的处理动作(target),协议几个部分。
实现过程如下:
当数据包进入AC时,Linux Kernel会查找对应的链,直到找到一条规则与数据包匹配(源和目的ip均匹配)。
匹配后,如果该规则的target是ACCEPT,则整个匹配过程结束,
跳过剩下的规则,数据包被发送。
如果该规则的target是DROP,该数据包会被拦截掉,匹配过程结束,不会再参考其他规则,如果target是另一个链表的名称,则跳转到相应的链表,这种表称为内层链表,好处在于使匹配过程更易管理和明晰。
如果该规则的target是RETURN,不再根据当前链的其他规则来检查数据包,而是直接返回,继续被发送到其目的地址,或下一个链。
匹配过程按顺序执行和跳转,如果从始至终都没有一条规则与数据包匹配,而且表末尾又没有drop规则,那末该数据包会被accept。
Iptables总的原则就是丢弃多数,允许少数:默认丢弃,符合规则的允许
Iptables中的这些规则其实就是在web页面的配置内容,(比如白名单配置的内容是accept,黑名单是drop,监听端口是增加相应的规则链表)可以通过iptables命令查看和修改这些规则链表,但测试时只需通过查看链表以确定页面配置规则的下发结果是否正确即可,不用修改。
例:白名单200.1.1.1,portal重定向ip:200.1.1.1,监听vlan100:100.1.1.1和vlan300:192.168.5.214
不匹配流:300.1.1.1(红)
符合白名单流:200.1.1.1(绿)
符合监听的流:100.1.1.1(蓝)
2)推送页面:
portal页面存放于AC上/www/目录下,AC有默认的portal页面,也可以通过ftp上传页面到该目录下,在多portal一项里添加将要推送的页面地址(可以发送多个url,比如广告页面)。
测试的时候可以直接拷贝302报文里边这个返回的网址来访问,以确定portal 页面的有效性。
2.用户和portal的交互,用户通过认证界面,输入用户名密码给portal
这一步实际上就是用户和portal动态网页之间的交互,具体目的就是网页获取用户的用户名密码,使用页面代码决定的加密等机制。
3.Portal开始和ac交互:
目的是portal将用户名密码发给ac,这一过程通过ac和portal之间的三个报文实现:报文使用udp报文2000端口:
1)portal向AC发送认证请求,数据包的类型为01,字节数16
2) AC回应portal的认证请求,并发送挑战给portal ,类型02,字节数34
挑战方把一段随机字符串发送给被挑战方,被挑战方使用该字符串作为密钥加密字符后把被加密过的字符返回给挑战方,挑战方再使用自己的字符串进行解密得到密码。
由于每次
连接的随机字符串可能不通所以即使有个别情况下被监听也能够保证密码安全3)portal通过挑战回应发送用户名和密码给AC,类型02,字节数39
4. ac开始和radius交互:
目的是对用户名密码进行认证,利用radius协议,完成对用户
Radius协议介绍:
1.基本特点:
采用客户/服务器模式,AC充当NAS即客户端负责将用户信息传递给指
定的RADIUS服务器,然后处理RADIUS服务器的回应。
RADIUS服务器负责接收用户连接请求,
认证用户.
两者通过共享密钥来进行相互认证的,并且该密钥不会通过网络传送。
两者间传送的用户密码也是加密的。
RADIUS可支持多种加密方式,以匹配不同用户使用的加密方式。
选择使用RADIUS协议进行认证,客户端生成一个包含用户名,用户密码,客户端的ID号,以及用户接入的
端口号ID属性的接入请求报文。
当提供用户密码时,用户密码都被用MD5算法隐藏起来。
接入请求,无回应则可以重传,然后选择备用服务器
Sever根据请求中的内容匹配数据库,共享密钥是必须的,否则静默丢弃(不回应)。
有密钥之后匹配用户密码等信息。
任何条件不满足则回应拒绝报文,所有条件被满足返回包含一系列的用户配置信息的成功回应报文如服务类型(SLIP,PPP或者Login User)等。
可以采用PAP和CHAP认证方式
一.对于PAP认证方式,NAS获得PAP ID和密码,然后将它们做为接入请求报文中的
User-Name和User-Password属性发送出去。
NAS可以包含值为
Framed-User的Service-Type属性和值为PPP的Framed-Protocol属性,以提示
RADIUS服务器用户需要PPP服务
二.对于CHAP认证方式,NAS生成一个随机挑战字(16个字节比较合适)并发送给用
户,用户回应一个携带CHAP ID和CHAP用户名的CHAP回应。
NAS然后向RADIUS服
务器发送一个接入请求报文,该请求报文将CHAP用户名做为User-Name属性,
CHAP ID和CHAP回应做为CHAP-Password属性。
随机挑战字可以包含在
CHAP-Challenge属性中,或者如果是16个字节长度的话,它可以放在接入请求
报文的Request Authenticator域中。
NAS可以(MAY)包含值为Framed-User的
Service-Type属性和值为PPP的Framed-Protocol属性,以提示RADIUS服务器用
户需要PPP服务
三.RADIUS根据User-Name属性查找到用户密码,对CHAP ID字节,密码和CHAP挑战
字进行MD5加密获得挑战字,然后将加密结果和
CHAP-Password属性比较,如果匹配,服务器发送回接入成功回应报文,否则发
送回接入拒绝回应报文
四.如果RADIUS服务器不能完成请求的认证过程,必须(MUST)返回接入拒绝回应
报文,
重传:
若主备共享密钥相同,则转发给备用服务器的报文可以使用相同的ID和认证字。
但也可以更改id。
若属性未变化,则必须使用相同id,若变化,必须使用不同ID+字(相同会丢弃)
服务类型以及被服务的用户的信息
返回应答,表示计费报文已经收到
服务终止时,客户端会产生一个计费结束报文,该报文描述了服务类型以及一些可选的统计数据,譬如,服务总时长、输入和输出的字节数或者输入和
输出报文数。
该报文被发送到RADIUS计费服务器,计费服务器会返回应答,表
示计费报文已经收到
Code域1字节:radius报文类型,非法类型直接丢弃不做处理
1 接入请求报文
2 接入成功回应报文
3 接入拒绝回应报文
4 计费请求报文
5 计费回应报文
标识符域1字节:用于匹配请求和回应报文,很短时间内收到Identifier+sip+upd口相同的请求则认为是重复请求,不做回应。
当属性域改变或回应成功后,必须改变
长度域2字节:指报文域的总长度,规定20-4096,不足者填充,小于否则丢弃,多余则不处理多出的。
20值前四个域必须有。
属性域可选。
认证域16字节:
接入请求报文中,认证字的值是一个占位16个字节随机数,称作请求认证字
唯一性:在整个共享密钥生命周期中必须唯一,以防同密钥下重复请求能被攻击截获回应报文。
当标识符域变后认证字必须改变
请求报文:
用户名:包含NAS-IP-Address或者NAS-Identifier两者可选其一或都有
在RADIUS服务器范围内唯一地标识NAS,与sip区别:利用sip查询共享密钥,而不是
NAS-IP-Addres,两者作用相同,可只含其中之一
密码字段:User-Password和CHAP-Password选其一,PAP方式使用前者(明文方式),且会被md5算法隐藏:类型(2)2字节+2字节长度+16整数倍字节串=最小20字节串构造方法:
1 .密码用null(\0)填充到16的整数倍个字节长,
2.认证字+共享密钥做md5加密(任意字节串->16字节hash码)
1和2相异或得出的16字节作为串填入。
Md5特性(不可逆)
CHAP-Password
类型(3)2字节+长度(19)2字节+标识1字节+字符串16字节=19字节
NAS端口(物理而非传输层端口):NAS-Port或者NAS-Port-Type选其一,或都有,也可都没有(nas不关心端口)
服务类型Service-Type:用户请求的或者nas准备提供的服务类型。
双方匹配,否则按拒绝报文处理
Loging:nas连接到主机
Framed:双方启用某种如ppp链路(根据Framed-Protocol属性)
Framed-IP-Address:用户IP地址,可多个供sever选择
响应报文(成功和拒绝):若请求报文的属性域被sever认同,则返回。
Code02.标识符为返回拷贝。
回应认证字为:
Code+ID+Length+请求认证字+请求属性+共享密钥经过md5算法隐藏
Chap_password:用户回应的挑战值
Chap_challenge: 由NAS发送d的CHAP挑战
回应字=MD5(Code+ID+Length+RequestAuth+Attributes+Secret)
3.计费报文
包含为用户提供服务的计费的信息,如果服务器能够成功地记录下计费报文的话,必须(MUST)回应一个计费回应报文.
除了User-Password, CHAP-Password属性外,其它在接入请求和接入成功回应报文中有效的属性,在计费请求报文中同样有效
Acct-Status-Type : Start(计费开始)
2 Stop(计费结束)
3 Interim-Update(计费更新)
7 Accounting-On(计费开始)
8 Accounting-Off(计费开始)
Acct-Session-Id:便于在日志文件中匹配计费开始和计费结束记录的唯一的计费ID。
对于一个给定的会话,计费开始和计费结束记录必须(MUST)有相同
NAS-Port-Id(87)属于radius扩展属性:包含一个识别正在认证用户的NAS的端口的文本串
Class:在接入成功回应报文中,并做为计费请求报文的一部分不做修改的发送给计费服务器
5.稳定性测试:
用户端:用linux系统模拟多个用户访问portal,检查portal返回报文情况
Portal端:用errorcode模拟和ac的交互。
用户端是使用shell脚本,通过创建多个子接口,利用http_load发起http请求,http_load 命令典型用法:http_load -sip sip -p 10 –f 1000 url
以sip文件中地址做为源ip地址,以url文件中url地址做为目的地址,并行10个进程发起http请求。
总的访问次数为1000.
用户端脚本:test.sh
Portal端
多portal:在推页面的时候先给用户选择页面的权利
内置与外置:ac免去了网站与用户交流所需的许多功能。
ac处理机制有何不同
我们是unix的什么版本
302推送页面地址与实际地址有差异:包含nasid和ac名称等参数
无线集中和本地模式的portal区别
脚本上下线不能挑选
空闲时间
Nas的含义与作用:ac与radius交互时双方需要匹配的参数
Iptables链走向(非监听端口):不用匹配iptables,不用过cpu。
监听端口所有包在认证以后都得查iptables才通过吗?。