OpenPortal 网络准入认证计费系统 · Portal 认证 + RADIUS 计费一体化平台

文档说明 / ABSTRACT

一页看懂

这套系统解决什么问题、以什么方式接入、能带来什么。

本文档面向网络与信息化负责人，说明产品定位、核心能力、适用场景、实施方式与投入价值，可直接用于方案汇报、技术评审与招标答疑。全文以 V6 运营旗舰版为基准，涉及指标处标注了适用形态，避免脱离部署条件单独引用。

|---------------------------|------------------------------|---------------------------|
| 16+ 种认证方式 免登记到强实名 | 20+ 主流设备厂商 标准与私有协议并存 | 400+ 项功能迭代 版本持续演进 |

三个必须回答的问题

**·**它替代了什么：原本分散在 AC 自带认证、独立计费网关、外挂营销工具里的三套能力，收敛为一套系统，账号、策略、报表只有一份。

**·**它如何接入：旁路部署在核心层或云端，不在数据转发路径上，设备侧只配 Portal 地址、RADIUS 地址与共享密钥。

**·**它带来什么：实名可追溯满足合规要求，套餐计费把带宽变成可售卖商品，运行状态可观测让系统敢上生产。

适用版本 OpenPortalServer Operation Ultra V6 运营旗舰版

更新日期 2026 年 10 月

适用对象 网络与信息化负责人、系统集成商、项目实施与运维团队

CONTENTS

目录

++一页看懂++... 1

++产品概述++... 3

++1.1++++　产品定位++... 3

++1.2++++　系统组成与四层架构++... 4

++1.3++++　版本演进与承载能力++... 6

++1.4++++　能力边界++... 7

++核心功能++... 8

++2.1++++　能力全景++... 8

++2.2++++　认证接入：16+ 种方式，按场景组合++... 8

++2.3++++　计费运营：把网络资源变成可售卖的商品++... 10

++2.4++++　策略与带宽管控++... 11

++2.5++++　高可用与协议兼容++... 12

++应用场景++... 13

++3.1++++　场景总览++... 13

++3.2++++　教育++... 13

++3.3++++　医疗++... 14

++3.4++++　园区办公++... 14

++3.5++++　商业酒店++... 15

++3.6++++　文旅会展++... 15

++3.7++++　城市政务++... 15

++3.8++++　部分落地客户++... 16

++解决方案++... 17

++4.1++++　典型组网：旁路叠加++... 17

++4.2++++　认证流程：六步完成一次接入++... 18

++4.3++++　六类实名认证方案++... 19

++4.4++++　无感知与访客授权++... 20

++4.5++++　认证页运营++... 21

++4.6++++　实施要点与常见问题++... 21

++价值亮点++... 22

++5.1++++　六个价值点++... 22

++5.2++++　落地路径++... 23

++5.3++++　交付保障++... 23

++附录++... 24

++附录 A　端口与协议速查++... 24

++附录 B　术语表++... 25

01 / 05

产品概述

一套系统，替代认证、计费、营销三套孤岛。旁路接入现有网络，不改结构，只补能力。

--- 系统组成与架构　　　--- 能力边界　　　--- 版本与部署　　　

1.1　产品定位

在校园、医院、园区、酒店与公共区域，网络一旦从"少数人使用"变成"全员使用"，三个问题会同时浮上来：谁在上网、能上多久、该付多少钱。第一个是准入与合规问题，第三个是资源与结算问题，中间还夹着体验问题------认证页打不开、二次接入重复登录、支付到一半掉线。

多数项目用三套彼此独立的东西分别应付这三件事：无线控制器自带的 Portal 认证、独立的计费网关、外挂的营销页面。三套系统各自维护账号、各自出报表，运维要记三套后台，出了问题要三家一起定位。更麻烦的是，三套系统之间的数据对不上，账单争议往往无从查证。

OpenPortal 的做法是把三件事收敛进一套系统：Portal 认证服务器负责"进得来"，RADIUS AAA 负责"算得清"与"放得通"，运营模块负责"留得住"。系统旁路部署在现有网络之外，不改动转发结构，因此可以在一夜之间上线，也可以在一分钟之内回退。

它是什么

由 Portal 认证服务器、RADIUS AAA 计费服务器与数据库组成的一体化准入平台。旁路部署于核心层或云端，与现有 AC、BAS、防火墙通过标准 Portal 与 RADIUS 协议对接即可启用，终端侧不需要安装任何客户端，只要有一个浏览器。

解决什么

上网身份不可知、认证方式碎片化、多厂商设备难统一、访客与临时人员失控、带宽资源无法计量与变现------五类问题一次收敛。每一条都能对应到具体的合规条款或运营诉求，而不是泛泛的"管理更方便"。

带来什么

实名可追溯、接入无感知、资源可计费、运营可增收、状态可观测。它既是合规底座，也是流量的运营入口：同一套认证页，既能承担实名留痕的义务，也能承担会员拉新与广告触达的职能。

表 1-1　产品定位速览

维度	一句话说明	对应业务问题
系统定位	Portal 认证 + RADIUS 计费的统一准入平台	三套孤岛合一，账单可对账
部署方式	旁路于核心层或云端，不改转发结构	不中断业务即可上线，故障可回退
适配范围	20+ 主流厂商，标准与私有协议并存	存量设备不淘汰，避免被单一厂商绑定
运营能力	套餐、支付、通知、续费形成闭环	网络从成本中心变为收入项
合规能力	实名认证、日志留存、审计对接	满足网络安全法与等级保护要求

1.2　系统组成与四层架构

系统由三部分构成：Portal 认证服务器负责接收终端请求、渲染认证页、校验身份；RADIUS AAA 服务器负责授权属性下发、计费采集与结算；数据库负责持久化，其中 MySQL 存业务配置与账号，MongoDB 存认证日志与长周期明细。三者可合并在同一台服务器上部署，也可按压力拆开。

图 1　系统四层架构：认证与计费收敛在核心层，运营能力向上生长

四层之间的关系可以用一句话概括：下面两层是既有的，上面两层是新增的。终端与接入层属于客户现网，系统只在核心层插入身份判断，在运营层叠加商业能力。这种"只加不改"的结构，是旁路部署能够成立的前提。

表 1-2　四层职责划分

层级	包含内容	在方案中的角色
终端层	手机、PC、平板、IoT、访客终端	只提供浏览器，不装客户端，降低推广阻力
接入层	无线 AC、BRAS/BAS、核心交换机、防火墙	认证的触发点与策略的执行点，由设备侧下发 ACL 与限速
核心层	Portal 引擎、RADIUS AAA、策略引擎、MySQL / MongoDB	身份判断与计费结算的唯一权威源
运营层	自助中心、在线支付、认证页管理、统计报表	把认证动作转化为可运营的触点与可结算的账单

部署形态

表 1-3　部署形态与承载环境

维度	支持方式
部署位置	核心层旁挂，或云端部署；多分支可集中认证、本地逃生
部署规模	单机、主备、分布式三种形态，按并发与可靠性要求选择
承载环境	客户自建服务器或云主机，Linux 与 Windows 均可
对接方式	标准 Portal 与 RADIUS 报文，无需在设备上装插件
协议端口	Portal 50100，RADIUS 认证 1812，RADIUS 计费 1813

1.3　版本演进与承载能力

产品按 V3、V5、V6 三代演进，每一代的重点不同：V3 解决"能不能认证"，V5 解决"能不能计费与统一账号"，V6 解决"能不能承载规模、能不能对接更多组织形态"。

表 1-4　三代版本的能力边界

版本	定位	关键能力
V3　普通版	Portal 协议认证基础能力	单机部署，满足中小场景的基本准入需求
V5　运营旗舰版	Radius 内核重构、计费策略体系	AD / LDAP 域认证、钉钉认证、人脸识别
V6　运营旗舰版	规模化承载与安全加固（当前版本）	微信小程序、企业微信认证，IPv6 双栈，MongoDB 分表，安全加固

V6 在版本迭代中继续加入 802.1X（EAP-MD5）与双因子／多因子混合认证，这也是对外表述为"16+ 种认证方式"的原因------内置方式已形成矩阵，新增方式按版本持续补充。

承载指标

表 1-5　单机或主备形态下的承载目标

指标	目标值	说明
认证处理能力	≥ 2000 次 / 秒	高峰时段集中认证的处理上限
并发在线	≥ 100,000	同时在线的终端规模
吞吐能力	≥ 2 Gbps	认证与计费报文的处理带宽

上表为单机或主备形态下的目标值。分布式部署可按区域水平扩展，满足总部---分支的集中管理诉求：总部统一认证、统一出账，分支保留本地逃生，链路中断时不影响本地接入。

1.4　能力边界

把不做什么说清楚，比罗列能做什么更能降低实施风险。以下四类工作不在这套系统的职责范围内，方案设计时需要由现网设备或其他系统承担：

**·**不做无线控制：不替代 AC 的射频管理、AP 纳管与漫游决策，系统的角色是告诉 AC "这个人可以放行"。

**·**不做出口网关：不承担 NAT、路由与流量整形，带宽限制以 RADIUS 属性形式下发，由设备执行。

**·**不做 DHCP 与 DNS 服务：地址分配与域名解析仍由现网设备完成，系统只处理认证与计费报文。

**·**不替代安全审计系统：提供完整的认证与计费日志并支持对接，但日志留存周期与合规判定由审计平台负责。

正是这条边界，决定了它能够旁路：只碰身份与账务，不碰转发。也因此，它不会成为新的单点故障------即使认证系统整体不可用，设备侧的逃生策略依然保证用户能上网。

02 / 05

核心功能

四大能力域，覆盖从"连上网"到"算清账"的全过程。

--- 认证接入　　　--- 计费运营　　　--- 策略管控　　　--- 运维保障　　　

2.1　能力全景

四个能力域之间有明确的因果链：认证解决"进得来"，计费解决"算得清"，策略解决"管得住"，运维解决"稳得住"。缺任何一环，系统都只能停留在"能用"而非"敢用"的阶段。

表 2-1　四大能力域

能力域	解决的问题	关键能力
认证接入	谁可以上网，以什么强度证明身份	16+ 种方式；账号、短信、域账号、社交账号、证件与人脸
计费运营	上网要付多少钱，怎么收	包年包月、时长、流量、买断；在线支付、充值卡、停复机
策略管控	能上多久、能跑多快、能看到什么	限速模板、ACL、VLAN 与 SSID 绑定、认证页分区推送
运维保障	出问题能不能发现、能不能快速恢复	心跳逃生、COA 踢线、备份恢复、分权与日志

2.2　认证接入：16+ 种方式，按场景组合

认证方式的多少不是目的，目的是在"实名强度"与"接入摩擦"之间找到该场景的平衡点。一个访客为了连 WiFi 去填身份证号，流失率会超过一半；而一个财务内网终端只做 MAC 绑定，又过不了等保。系统内置 16 种方式，并支持按 SSID、AP、IP 段、时间段分别指定，同一个网络里可以并存多种策略。

表 2-2　内置认证方式矩阵

认证方式	典型人群	关键能力
一键认证	开放区域、体验优先场景	广告页快速放行，认证即曝光
账号密码	员工、学生、会员体系	与既有账号体系对接，支持批量开户与自助改密
短信认证	访客、公共场所、临时人员	手机号即身份，验证码校验，可设次数限制与虚拟短信
访客扫码	内部人员授权的临时访客	员工生成一次性授权码，访客扫码即上网，责任可追溯
MAC 无感知	固定终端、长期用户	首次认证绑定 MAC 与账号，二次接入自动放行
AD / LDAP	高校、医院、大型企业	复用既有域账号，支持 uid / cn 与 memberOf 解析
CAS 单点	已建统一身份平台的组织	对接单点登录，一次登录全校通用
钉钉认证	组织内部员工	扫码或免密授权，自动建号并同步组织结构
企业微信	以企微为办公入口的企业	企微内静默授权，员工免登记接入
微信小程序	商场、酒店、园区对外服务	授权获取手机号，实现弱实名与会员绑定
微信公众号	需要沉淀粉丝的商业场景	关注即上网，认证页可挂载营销活动
飞书认证	以飞书为办公入口的组织	免登授权，自动建号并同步部门与人员
答题认证	普法、培训、考试场景	答题达标方可上网，题目与通过率可统计
视频倒计时	内容传播与告知场景	观看指定视频后授权，播放时长可校验
人脸识别	高安全区域、机房与要害部门	活体检测，可与门禁、考勤共用底库
身份证实名	政务大厅、公共场所	读取证件信息完成强实名，满足审计要求

V6 在此基础上继续加入 802.1X（EAP-MD5）与双因子／多因子混合认证。认证方式之间可以串联：同一 SSID 下先短信再人脸，或员工走域账号、访客走扫码，全部由策略决定，不需要改代码或定制开发。

|------------------------------------------------------------------------------------------------------------------------|
| 一条实践建议 认证方式的组合应跟着"责任"走，而不是跟着"技术"走。谁需要对上网行为负责，就由谁的身份来背书： 内部员工用组织账号，访客用邀请人授权，公共场所用手机号，要害区域叠加人脸。这样出问题时，日志里能直接定位到责任主体。 |

2.3　计费运营：把网络资源变成可售卖的商品

计费的本质是把网络资源定义成商品，并让"购买---使用---结算"三个动作都在线上闭环。系统提供五种计费模型，可以单独使用，也可以叠加使用。

表 2-3　五种计费模型

计费模型	结算方式	适用场景
包年 / 包月 / 包天	周期订阅，到期自动失效	宿舍、公寓、连锁门店、长期租户
时长计费	按实际在线时长结算	临时办公、会议、流动人群
流量计费	按上下行流量结算	流量敏感型场景、共享带宽经营
买断时长	一次性购买固定时长，到期失效	预付费卡销售、活动期临时套餐
套餐叠加	多套餐累加，按优先级套用	基础套餐 + 提速包 + 临时包的组合销售

营收闭环

从开户到结算，六个动作在系统内闭合，不需要人工介入：

表 2-4　营收闭环六步

步骤	动作	设计意图
01	自助注册 / 扫码开户	用户自助完成，减少前台工作量
02	选择套餐并在线支付	支付宝、微信、iPay 三种主渠道
03	认证放行并开始计时计量	支付成功即授权，无需等待人工开通
04	余额告警与欠费通知	阈值可配，提前触达避免体验断崖
05	续费或自动停复机	续费即时恢复，欠费按宽限期处理
06	账单与报表导出	按用户、套餐、区域维度出账，支持对账

支付渠道覆盖支付宝、微信与 iPay；充值卡以 CD-KEY 形式生成，可导出实体卡批量销售，适合校园与连锁门店的地推场景------这类场景里，线下售卡往往比线上支付更贴近用户习惯。

2.4　策略与带宽管控

策略不是开关，而是一组可组合、可例外、可逐级套用的规则。管理员面对的不是"限速 2M"这样一条配置，而是"研发组在工作日 9 点到 18 点限速 8M，其余时段不限；访客统一 2M；VIP 终端不限速"这样一组关系。

表 2-5　三类策略及其控制项

策略域	控制项	说明
接入控制	限速模板 / ACL 与 Framed-Pool / 多 VLAN 属性 / 二次代拨	限速粒度 250kbps，随 RADIUS 授权一次性下发，无需在出口设备逐条维护
身份与绑定	用户组绑定 BAS·NAS / VLAN·SSID·IP 段绑定 / NAS-IP 与端口绑定 / 终端类型识别	把"谁"和"从哪里接入"绑定，防止账号跨区域漫游使用
页面与体验	按 AP MAC 推送认证页 / 按 SSID·IP 段·时间段推送 / 延迟认证与倒计时授权 / 多终端自适应	同一套系统服务不同区域时，页面内容与语言可以完全不同

策略按四级优先级套用：终端类型 → 用户组默认策略 → 绑定策略 → 计费策略。管理员可对单个账号设置例外，例外只影响该账号，不破坏整体规则。这条设计的意义在于------运营规则可以被业务部门自己维护，而不必每次调整都找厂商改配置。

2.5　高可用与协议兼容

协议兼容决定对接成本，高可用决定上线风险。这两件事共同决定一套认证系统能不能真正进入生产环境。

运维保障

**·**Portal 心跳保活：设备与认证系统之间维持探测，失联自动触发逃生，用户不受影响。

**·**RADIUS 双认证透传与代理转发：多分支场景下由总部统一认证，分支保留本地代理与逃生。

**·**COA 踢线与在线解锁：策略变更、欠费停用、MAC 解绑均可在线生效，不需要用户重新连接。

**·**数据分表与长周期留存：MongoDB、MySQL 按时间分表，百万级明细查询仍可在秒级返回。

**·**备份与恢复：定时备份至 FTP，支持在线恢复；计划任务、系统日志、区域与角色权限分级管理。

表 2-6　协议与标准兼容清单

协议 / 标准	覆盖范围
Portal	标准 1.0 / 2.0 / 3.0，覆盖国内主流 AC 与 BAS
CMCC	V1 / V2 / V3 移动标准，适配运营商定制设备
RADIUS	RFC 2865 / 2866，支持 PAP、CHAP、EAP-MD5
WISPr / Wifidog	Ruckus、Aruba、ROS、TP-Link 等设备的标准对接方式
MAC 快速认证	MAC-Trigger / MAC-Auth 双通道，实现无感知二次接入
IPv6	Portal 与 RADIUS 双栈支持，认证页与计费同步适配
COA / DM	在线策略变更与强制下线，用于限速调整与欠费停机

协议兼容的价值在于"存量不用换"。一家已经铺了三个品牌 AC 的园区，不需要为了统一认证而淘汰任何一台设备；私有协议与标准协议并存，才可能出现一次对接、长期复用的结果。

03 / 05

应用场景

六类典型场景，同一套系统，不同侧重点。

--- 教育　　　--- 医疗　　　--- 园区办公　　　--- 商业酒店　　　--- 文旅会展　　　--- 城市政务　　　

3.1　场景总览

同一套系统在不同行业里的"第一诉求"并不相同。教育与商业关心计费与转化，医疗与政务关心合规与追溯，文旅与赛事关心瞬时并发。抓住每个场景的核心矛盾，比堆砌功能更有效。

表 3-1　六类场景与解决方案组合

场景	核心矛盾	解决方案组合
教育	多运营商、多校区，开学季并发高，学生需自助缴费	账号 + 套餐计费 + 自助中心
医疗	门诊大厅访客密集，内网终端需强实名，等保合规	短信 / 身份证实名 + 分区策略
园区办公	员工免密接入，访客临时授权，多分支统一管理	AD 域 / 钉钉 / 企微 + 访客扫码
商业酒店	顾客体验优先，会员拉新，网络作为增值服务	一键 / 微信认证 + 广告与会员运营
文旅会展	瞬时大客流，临时网络，活动期集中保障	高并发认证 + 临时放行 + 多语言页面
城市政务	公共区域免费 WiFi，实名留痕，审计可追溯	实名认证 + 日志留存 + 审计对接

3.2　教育

教育场景的矛盾集中在两处。一是账号体系不统一：宿舍走运营商、教学楼走校园网、图书馆又是另一套认证，学生每换一个位置就要重新登录一次。二是开学季的瞬时并发：注册、缴费、认证三项操作堆在同一周，系统往往在这时暴露出容量问题。

方案上，用统一账号打通宿舍、教学区与公共区域，配合套餐计费把上网费从线下收费窗口搬到自助中心；开学季通过分布式部署与认证缓存承接峰值，避免集中注册把系统压垮。缴费记录与认证日志同源，学生申诉时有据可查。

已落地：北方民族大学、西南财经大学、唐山学院、湘南学院。

3.3　医疗

医院的特殊性在于"同一张网里有两类完全不同的用户"：门诊大厅的访客需要便捷上网，内网终端（HIS、PACS、移动护理）则需要强实名与严格分区。访客网络一旦与内网混在同一个 SSID，等保测评基本过不了。

方案上用短信或身份证完成访客实名，用分区策略把访客区、办公区、内网区在 SSID 与 VLAN 层面隔开，不同区域推送不同认证页、下发不同限速。内网终端走 MAC 绑定与域账号双重校验，接入位置与账号一一对应，日志可按人、按终端、按时间检索。

已落地：麻城市第二人民医院、天津市肿瘤医院、青岛大学附属医院。

3.4　园区办公

园区办公讲的是"无感"。员工每天进出，如果每次都要输账号密码，IT 部门的投诉电话不会停。但访客又必须有人背书，不能随便放行。这两件事看起来冲突，实际上是两套策略：员工走免密，访客走授权码。

方案上用 AD 域、钉钉或企业微信实现员工免密接入，首次绑定后长期有效；访客由内部员工生成一次性授权码，扫码即上网，授权记录可查、可随时回收。多分支场景下总部集中认证、分支本地逃生，链路中断不影响办公。

已落地：中国科学院深圳先进技术研究院、中国电建、猪八戒。

3.5　商业酒店

商业场景里，认证页是唯一一次"用户必须看"的广告位。顾客为了上网会停留 10 到 30 秒，这段时间的价值远高于任何信息流投放。因此这类项目的关键不是认证多安全，而是认证页多好用、能不能带来会员。

方案上用一键认证或微信认证把摩擦降到最低，认证页承载会员注册、优惠券与活动报名；后台按门店、按时段切换页面内容，总部统一管理素材、门店只做选择。网络本身则作为住客权益的一部分，按房型或会员等级下发不同带宽。

已落地：武汉 K11、澳门金沙度假区、哈尔滨杉杉奥特莱斯广场。

3.6　文旅会展

文旅与会展的极限场景是"两小时内涌入几万人"。这类项目平时流量很低，活动期瞬间打满，按峰值配置资源意味着长期浪费，按均值配置又必然在关键节点崩掉。

方案上以高并发认证为基础，配合临时放行策略：活动期间对特定区域、特定时段放宽认证要求，活动结束后自动收回；认证页支持中、英、日、韩多语言，按终端语言自动匹配。系统在活动期可临时扩容，活动结束后缩容，成本随用随付。

已落地：北京国家会议中心、第七届世界军人运动会、世运会、GCUC 全球联合办公峰会。

3.7　城市政务

公共区域免费 WiFi 的约束来自监管：必须实名、必须留痕、必须可审计。同时对市民的服务体验又不能太差，一个需要填五项信息的认证页，实际使用率会非常低。

方案上用短信或身份证完成实名，把认证动作压缩到一次验证码；日志长期留存并支持对接审计平台，按监管要求提供查询接口。网络侧按区域划分策略，政务大厅、公园、公交站点可分别设置认证方式与使用时长。

已落地：深圳福田区政务 WiFi、北京市大兴区法院、甘孜州政务网、i-hefei 合肥。

3.8　部分落地客户

以下客户按行业分组列出，可作为同类项目的参考。完整的对接案例与设备型号清单可向售前索取。

表 3-2　部分落地客户

行业分组	客户
教育与医疗	上海视觉艺术学院 / 唐山学院 / 西南财经大学 / 北方民族大学 / 瑞金医院卢湾分院 / 天津市肿瘤医院 / 青岛大学附属医院 / 成都市第三人民医院
商业与文旅	北京国家会议中心 / 武汉 K11 / 澳门金沙度假区 / 华美达安可酒店 / 郑州大商道国际购物中心 / 乐汇城 / 新光天地 / 水善汇
园区与政企	碧桂园 / 中国电建南国置业 / 好莱客家居 / 猪八戒网 / 甘孜州政务网 / 上海农业银行 / 上海普用科技 / 小鹿开门
城市与大型活动	武汉城市 WiFi（中兴合作）/ i-hefei 合肥 / D-Guiyang 贵阳 / 兰州移动 / 第七届世界军人运动会 / 世运会 / GCUC 全球联合办公峰会 / 智慧金岭

04 / 05

解决方案

从组网到流程，从实名到体验，给出可直接施工的方案。

--- 典型组网　　　--- 认证流程　　　--- 六类实名方案　　　--- 无感知与访客　　　

4.1　典型组网：旁路叠加

系统不串接在数据链路中，而是旁挂在核心层或云端，仅通过 Portal 与 RADIUS 报文与网络设备交互。这个结构带来的直接好处是：上线不需要割接，故障可以直接回退，认证系统的可用性不再等于网络的可用性。

图 2　旁路组网：认证系统不在转发路径上，设备侧仅需配置三个参数

表 4-1　组网四个关键判断

维度	说明
部署位置	核心层旁挂或云端；多分支可集中认证、本地逃生
对接工作量	设备侧仅需配置 Portal 地址、RADIUS 地址与共享密钥
高可用	主备或分布式，单点故障不影响转发，支持心跳逃生
扩展路径	统一认证平台后续可承接 OA、门禁、有线无线一体化接入

设备侧配置清单

对接的复杂程度决定了项目周期。下表是设备侧通常需要完成的项目，多数型号都在 20 分钟内可以配完：

表 4-2　设备侧对接配置清单

配置项	取值 / 说明
Portal 服务器地址	认证系统对外服务地址，需设备三层可达
Portal 端口	50100（可改），需在设备侧填写一致
RADIUS 认证地址	IP:1812，需配置共享密钥
RADIUS 计费地址	IP:1813，用于起止报文计时计量
免认证网段	认证系统自身与认证页静态资源地址，避免认证页打不开
逃生策略	认证系统失联时设备侧放行，保证业务连续性

4.2　认证流程：六步完成一次接入

一次完整的接入会经过六个动作，从终端发起请求到计费结算结束。理解这条链路，是排查"认证不通过"类问题的前提。

表 4-3　认证流程六步

步骤	动作	说明
01	终端接入	连接 SSID 或网口，从 DHCP 获取地址
02	Portal 重定向	设备将首次访问重定向至认证页
03	身份核验	按策略选择短信、钉钉、账号密码等方式完成校验
04	RADIUS 授权	下发 ACL、限速模板、VLAN 等属性，设备据此放行
05	计费采集	Accounting 起止报文计时计量，写入明细库
06	下线 / 续费	超时、欠费、主动下线与自动复机，形成闭环

三个关键设计

**·**无感知：二次接入走 MAC 快速认证，1 秒内放行，用户不感知认证页的存在。

**·**临时放行：在线支付期间按策略短时放行，避免支付中途因认证超时而中断。

**·**逃生：认证系统失联时设备侧自动放行，业务不中断，恢复后自动补录日志。

4.3　六类实名认证方案

选型的判断标准只有一个：谁在用网。内部员工优先复用既有账号体系，访客优先手机号，对外服务优先小程序，已经用钉钉、企微或飞书办公的组织直接走组织内免登。实名强度越高，接入摩擦越大，不必要地提高强度只会降低使用率。

表 4-4　六类实名方案对照

方案	适用对象	关键能力	落地要点
短信认证	访客、公共场所、临时人员	手机号即身份，验证码校验，可配置虚拟短信与次数限制	对接短信网关，支持阿里云、移动 MAS、联通与电信 SMGP
钉钉认证	组织内部员工、钉钉办公企业	扫码或免密授权，自动新建实名账户并同步组织结构	需企业自建应用 AppID / AppSecret 与回调域名
企业微信认证	企业内部、以企微为办公入口	企微内授权静默登录，员工免登记接入	需配置企业微信应用与可信域名
飞书认证	以飞书为办公入口的组织	飞书内免登授权，自动新建实名账户并同步部门与人员	需企业自建应用 AppID / AppSecret 与回调地址
微信小程序	商场、酒店、园区对外服务	授权获取手机号，实现弱实名与会员绑定	需小程序备案、服务器域名与业务域名配置
AD / LDAP 域	高校、医院、大型企业	复用既有域账号，支持 uid / cn 与 memberOf 解析	需域控只读账号与网络可达；可扩展 CAS 单点登录

4.4　无感知与访客授权

"少打扰"和"管得住"是两件事，但常常被混为一谈。无感知解决前者，访客授权解决后者，两者需要同时具备。

无感知认证

系统提供 MAC-Trigger 与 MAC-Auth 双通道：首次认证时把 MAC 与账号绑定，二次接入由设备侧直接发起MAC 快速认证，1 秒内放行。为防止 MAC 伪造，校验时叠加浏览器指纹，形成 MAC + 指纹的组合判断；同时支持无感知累计时长与有效期管理，到期自动失效，避免"一次绑定终身有效"。

访客授权

访客不需要自己登记，由内部人员背书：员工登录自助中心生成一次性授权码，访客扫码即上网。授权可按时长与次数限定，记录可查、可随时回收。这条链路把责任放在了邀请人身上，既满足了"可追溯"，又避免了前台替访客填表的低效流程。

4.5　认证页运营

认证页是用户每次上网都必须经过的一屏，也是整套系统里唯一具备"媒体属性"的位置。系统的认证页采用模板化编辑，业务人员可以自助维护，不需要研发介入。

**·**内容可配：轮播图与广告位在后台管理，按活动周期上下线。

**·**分流可配：按区域、时段、SSID 切换不同页面，商场不同楼层可以推不同内容。

**·**组件可插：微信关注、问卷、答题、视频等组件按需启用。

**·**终端自适应：iOS、Android、PC 浏览器均自动适配，不必为每种终端单独做页面。

4.6　实施要点与常见问题

以下问题在实施中出现频率最高，多数与配置有关而非系统缺陷，可作为联调阶段的自查清单。

表 4-5　实施常见问题速查

现象	常见原因与处理
认证页打不开	设备侧未放行认证服务器地址或认证页静态资源，检查免认证网段配置
反复要求认证	MAC 无感知未启用，或绑定关系被终端随机 MAC 打断，检查终端隐私设置
认证通过但无法上网	RADIUS 授权属性与设备侧不匹配，核对 ACL 编号与 VLAN 定义
计费不出账	Accounting 未开启或共享密钥不一致，抓包确认 1813 端口报文
认证系统离线后全网断网	未配置逃生策略，应在设备侧启用失联放行
多分支认证慢	分支回总部认证链路延迟，可启用本地代理转发或就近部署

05 / 05

价值亮点

六个理由，回答"为什么是我们"。

--- 兼容　　　--- 体验　　　--- 合规　　　--- 变现　　　--- 可运维　　　--- 总成本　　　

5.1　六个价值点

技术能力需要翻译成业务语言，才能进入决策。下面六条，每一条都对应一类决策人最关心的那件事。

表 5-1　六个价值点及其对应决策人

价值点	对谁重要	说明
兼容广	网络负责人	20+ 主流厂商、标准与私有协议并存，一次对接长期复用，避免被单一设备厂商绑定
体验好	业务与用户	无感知二次接入、支付期临时放行、多终端自适应页面，把认证对业务的打扰降到最低
合规稳	安全与合规	16+ 种认证方式覆盖弱实名到强实名，日志留存与审计对接，满足网络安全法与等保要求
能变现	经营与财务	套餐、支付、充值卡、通知形成完整营收闭环，把网络从成本中心变成收入项
可运维	IT 运维	心跳逃生、主备分布式、备份恢复与区域权限，让系统敢上生产、能长期跑
总成本低	决策层	一套系统替代认证、计费、营销三套孤岛，硬件要求低，部署与培训周期短

5.2　落地路径

常规项目按四步推进，完整周期约两周。其中第 2、3 步（系统部署与联调上线）在标准场景下可以压缩到一小时内完成------前提是设备清单明确、网络环境已就绪。两周与一小时之间的差距，主要来自评估阶段的策略确认与上线阶段的灰度放行。

表 5-2　四步落地路径

步骤	工作内容	交付物
第 1 步　现状评估	设备型号与协议梳理；认证方式与实名策略确认；并发与存储规模测算	对接方案与设备清单
第 2 步　系统部署	单机或主备环境搭建；域名、证书、短信与支付配置；数据初始化与账号导入	可运行环境与配置文档
第 3 步　联调上线	AC / BAS 侧 Portal 与 RADIUS 配置；认证页模板定制与发布；灰度放行与逃生演练	联调记录与逃生验证报告
第 4 步　运营优化	套餐与计费策略调优；报表与告警接入；运维培训与文档交付	运营手册与培训记录

5.3　交付保障

**·**远程 + 现场支持：常规问题远程处理，割接与联调阶段可安排现场支持。

**·**完整文档：部署手册、配置说明、运维手册、接口文档随项目交付。

**·**对接案例库：同类设备与同类场景的对接经验可直接复用，缩短联调时间。

**·**版本持续迭代：当前为 V6 运营旗舰版，功能按版本持续演进，已交付项目可平滑升级。

交付不是终点。认证系统的价值随运行时间增长------数据越久，报表越有参考价值；策略越细，运营空间越大。因此我们更倾向于把项目做成长期协作，而不是一次性验收。

APPENDIX

附录

端口、协议与术语速查，供实施与运维阶段直接查阅。

附录 A　端口与协议速查

表 A-1　服务端口与协议

服务	默认端口	协议	说明
Portal 服务	50100	HTTP / HTTPS	接收终端认证请求，渲染认证页
RADIUS 认证	1812	UDP	Access-Request / Accept / Reject
RADIUS 计费	1813	UDP	Accounting-Request 起止报文
COA	3799	UDP	在线策略变更与强制下线
管理后台	自定义	HTTP / HTTPS	建议限制源地址，不对公网开放
数据库	3306 / 27017	TCP	MySQL / MongoDB，建议仅本机或内网访问

附录 B　术语表

表 B-1　常用术语

术语	含义
Portal 认证	终端被重定向到认证页完成身份校验的接入方式，无需安装客户端
RADIUS	远程认证拨号用户服务，用于认证、授权与计费（AAA）的标准协议
AC / BAS	无线控制器 / 宽带接入服务器，是 Portal 与 RADIUS 的客户端侧设备
COA	Change of Authorization，在线变更授权属性，用于调整限速或强制下线
MAC-Trigger	由设备检测到新 MAC 后主动发起认证，实现无感知接入
逃生	认证系统不可用时设备侧放行流量，保证业务连续性
Framed-Pool	RADIUS 属性之一，用于下发地址池或限速参数
宽限期	欠费后保留的缓冲时段，期间仍可上网但会持续提醒

OPENPORTAL

让每一次接入都可信

Portal 认证　·　RADIUS 计费　·　实名准入　·　运营增值

本文件内容以 V6 运营旗舰版为基准编写，指标数据与所支持的协议以实际交付版本为准。