UniFi - 使用第三方认证平台配置步骤及原理(仅内部人员借阅)

概览


本文描述了如何在 UniFi 控制器上与国内使用 cmcc 协议的第三方认证平台对接的问题。一般而言,使用unifi 全套设备,将自带 radius 认证功能和 portal 页面,不过很多大客户在企业内部都有自己的认证平台,那么就存在一个如何与外置的认证平台对接的问题。因为国内认证都要通过 cmcc 协议,所以我们需要安装一个对接 cmcc 协议扩展服务,来与外置认证平台通信。

注意事项&要求:
本文讲解了如何对接第三方认证平台,涉及到系统的安装,程序的执行等操作,所以仅对研发人员开放。

目录


  1. 认证过程解析
  2. 安装环境确认
  3. 安装 docker
  4. 安装扩展服务包
  5. 配置控制器
  6. 测试笔记

 认证过程解析


cmcc-radius.jpg

角色一:用户

是指用户连接到配置 radius 认证的 SSID 的笔记本、手机等终端。

角色二:UAP

是指发射此 SSID 的 AP。

角色三:第三方认证平台(下文中均简称radius)

是指企业中用于员工认证上网的服务器,包括 radius 功能 、portal 功能等,使用 cmcc 协议与 AC 通信。

角色四:中间件

是指安装在控制器上的扩展服务,他是一个更新程序需要我们自行部署,用于与第三方认证平台进行正常通信。

角色五:控制器

UniFi 的 AC 控制器,用于管控所有 UniFi 设备和通过 UniFi 连接上的客户端。

整个认证过程分为四个阶段:未认证、认证中、认证通过和下线

未认证阶段:用户连接 SSID 请求上网,控制器收到请求信息,发现该用户未进行认证,发送用户需认证的redirect 信息给中间件,中间件中存有认证地址的 URL ,并将携带该 URL 的 redirect 信息发送给 AP ,AP最终发给用户。

认证阶段:用户接到 redirect 信息,跳转至 URL 界面,填写相关的用户名密码信息,并发送给 radius,radius 服务器接收到信息与 radius 数据库对比,发现有匹配到的用户名密码后,发送信息给中间件,通知对方认证通过,可以授权,中间件将信息传递给控制器,控制器收到后,给该用户授权上网,并通知 radius 和 AP 已授权通知,AP 收到后通知用户认证通过,已授权。

认证通过阶段:当用户收到授权通知后会给控制器返回一个确认信息,控制器收到后变更用户状态为已授权状态,此时,中间件会一直监听控制器状态,每过15秒发送一次确认信息,发现用户状态变化,则马上发送 accouting 信息给 radius ,radius 服务器收到 accounting 信息后,变更计费状态。

下线阶段:有些第三方认证平台会有主动踢人下线的需求(DM),当 radius 主动取消一个用户的授权时,会通过中间件通知控制器,控制器会自动取消该用户的授权;同样当控制器主动取消该用户的授权,也会通过中间件通知 radius 用户的状态发生变化。

无感知功能:控制器默认一个终端授权后,MAC记录8小时,八小时内该设备无需认证直接放行,该时间根据radius赋值发生改变。在认证过程中可能会出现下面几种可能:1.控制器未授权+radius未授权;2.控制器未授权+radius已授权;3.控制器已授权+radius未授权;4.控制器已授权+radius已授权。

第一种状态:用户连接 SSID,会自动弹出或者手动浏览网页弹出portal页面输入用户名密码,登陆成功后访问互联网。

第二种状态:用户连接 SSID,会自动弹出或者手动浏览网页弹出portal页面显示success,然后访问互联网。

第三种状态:用户连接 SSID,直接上网

第四种状态:用户连接 SSID,直接上网

上述四种状态中,第一种状态为欸首次连接状态,剩下三种状态均属于无感知状态,其中第二种状态可以通过将控制器的 MAC 记录时间延长来实现不弹 success 页面。

警告: 整个认证过程均符合国际标准,但也存在企业的第三方认证平台使用的是自主研发的程序,过程中可能有些数据包的结构组成会有些差异导致连接不正常,所以需要用户具有自主研发和排错能力,便于项目的实施。

 

安装环境确认


返回顶部

经过测试承载控制器的系统最稳定的是:Linux 16.04

最稳定的控制器版本:5.6.40

我们可以通过官网一键脚本在 Linux 16.04 上部署 5.6.40 版本控制器。

控制器的扩展服务程序需安装在 docker 环境下,所以所安装的 Linux 系统需要支持安装 docker.

控制器与 radius 服务器需网络互通,使用到的端口有:TCP 80 1812 1813 2000 3478 3799;UDP:1812 1813 2000 3478 3799

控制器需联网最好在部署阶段可以提供 VPN(部分网站在国外)

全程配置需要 root 权限

 

用户提示:其实扩展服务不需要一定和控制器安装在一起,只需要扩展程序与控制器和 radius 服务器分别互通即可,因为扩展程序属于控制器程序,所以逻辑上我们会把它和控制器安装在一起。

安装 docker


返回顶部

在 Linux 16.04 上使用下面这条命令下载安装 docker:

curl -sSL https://get.docker.com/ | sh

使用下面这条命令下载安装 compose 文件:

sudo curl -L "https://github.com/docker/compose/releases/download/1.23.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

使用下面命令赋予 compose 权限:

sudo chmod +x /usr/local/bin/docker-compose

 

注意: 由于上述命令所下载的文件大都在国外,如果出现下载失败或下载缓慢的情况,建议结束重新下载,多次尝试,如果可以最好能够提供 VPN 供其下载。

 


安装扩展服务包


返回顶部

在 Linux 16.04 上使用下面这条命令下载安装扩展更新包然后解压:

wget http://112.64.233.204:12121/unifi-cmcc/unifi-cmcc-2019-01-16.zip

使用下面命令下载 docker-compose 文件:

wget http://112.64.233.204:12121/unifi-cmcc/docker-compose.yml

使用下面命令载入镜像:

docker load -i unifi-cmcc-2019-01-16.tar

使用下面命令编辑 docker-compose.yml 文件:

vim docker-compose.yml

编辑内容根据下表填写(加粗的内容为需修改内容):

SERVER-IP=控制器的IP地址
SERVER-PORT=控制器端口(默认8443)
SERVER-SITE-NAME=控制器站点名称(注意该名称是该站点在系统文件中的名称,你可以通过URL来截取,默认是default)
UNIFI-USER=控制器登陆用户名
UNIFI-PASS=控制器登陆密码
PORTAL-URL=PORTAL服务器的URL
PORTAL-WLANIP=PORTAL服务器的IP
REDISS-SERVER=127.0.0.1
REDISS-PORT=6379
REDISS-TIMEOUT=1
RADIUS-SERVER=RADIUS服务器的IP
RADIUS-AUTH-PORT=1812
RADIUS-ACC-PORT=1813
RADIUS-SHARED-SECRET=RADIUS的认证密钥
NAS-SERVER=扩展服务的安装IP地址(如果与控制安装在一起就是控制器的IP地址)
NAS-PORT=2000

根据上表修改完成后,使用下面命令,执行该程序:

docker-compose up -d 

执行程序后,可通过下列命令开启程序日志,方便检查: 

docker logs -f unifi-cmcc --tail 200

使用下方命令查看docker是否启用: 

docker ps

使用下方命令重启docker-compose: 都需要使用root权限

docker-compose down ; docker-compose up -d

 

 

 

注意: 由于上述命令所下载的文件均为中国区服务器提供,如果发现下载报错请及时发送邮件通知我们,我们的邮箱是:support.cn@ubnt.com。再修改compose 文件时,需要注意保存配置,该步骤需要使用 Linux 命令进行编辑。执行程序后如果尚未生效,可以尝试重启服务或系统。如有任何问题都可通过我们的邮箱与我们沟通,再次强调,本功能需有一定研发能力的工程师方可安装。

 


配置控制器


返回顶部

根据下方截图配置来宾策略:

1544776253_1_.jpg

根据下方截图配置无线网络:

1544777870_1_.png

  

注意: 本扩展程序是按照标准 cmcc 协议开发,所有字段、数据包大小等必须符合 cmcc 标准协议,如不符合标准需要对端进行调整。

 


测试笔记


返回顶部

笔记一:radius认证阶段的challenge包,双方大小不一致,导致CHAP认证无法通过

测试处理方法:在扩展服务中修改包大小。(已修复,从 14 -> 16)

笔记二:5.9.29版本控制器API接口变更,不会发送accounting包,导致认证平台无法正常计费

测试处理方法:将版本降至5.6.40 (未修复)

笔记三:由于扩展程序的包解析能力只能解析1024以内的包,超过部分无法解析,而对端发送的包大小超过了1024,导致解析不到session-timeout信息。 

测试处理方法:将包解析能力提升到65535 (已修复)

笔记四:扩展服务默认将 MAC地址的连字符“:”或“-”去掉,导致认证平台无法识别。

测试处理方法:将连字符加上。(已修复)

笔记五:控制器默认已授权用户上线不发送accounting信息,导致认证平台无法开始正常计费。

测试处理办法:在扩展服务上将判断该用户是否为已授权,是的话发送accounting包。(已修复)

笔记六:扩展服务默认用户下线后五分钟,将会主动将该用户信息从redis中删除,授权该用户再次登陆后,中间件检测redis中无信息,且由于用户已经授权,则不会触发accounting信息,导致日志服务器日志不正常。

测试处理办法:在扩展服务上添加判断已授权用户连接后查看redis,如果redis不存在,则重新存储。(已修复)

笔记七:由于有些用户的DHCP使用的是第三方服务器,响应时间和地址保留时间很短,导致已授权用户,在免授权时间内DHCP地址已经到期,再次登陆时,扩展服务检测到改用的IP地址为空或者错误,将不会开启计费,即使后面DHCP服务响应了,也不会再次触发IP地址的流程,最终导致日志服务器不正常。

测试处理办法:在扩展服务上添加流程,用户登陆后过30秒再开始计费判断流程。(不会影响用户体验但是计费信息会延迟30秒)