简介面向商场、酒店、银行、图书馆等公共场景的无线网络建设与运营需求这份资源提供了一套完整的WebPortal无线接入认证解决方案适合网络工程师、IT运维人员和方案规划人员参考。文档从项目背景与需求分析入手梳理了传统无线接入在安全、稳定性和用户管理方面的痛点并围绕安全性、易用性、可扩展性等原则展开设计。内容涵盖方案拓扑、SMS短信认证、认证页面自定义、用户上网时长/流量/速度控制、广告推送及统计分析等特色功能同时介绍了蓝海卓越室外/室内AP与Portal服务器等配套产品并附有商场、银行、图书馆、宽带运营商等典型客户案例。资源为单份docx文件容量987KB结构清晰便于对照实际项目进行方案设计或编写技术方案。已有271人学习下载对正在规划可运营Wi-Fi网络或需要撰写无线认证解决方案的技术人员而言具有直接参考价值。1. WebPortal无线接入认证为什么说它不是“弹个页面”那么简单很多企业园区、酒店、商场的无线网络都在用 WebPortal 无线接入认证用户连上 WiFi 后自动打开一个登录页输入手机号或账号密码通过后才能访问互联网。这个体验看起来就是“弹了个网页”但背后牵涉 DHCP、DNS 重定向、HTTP 拦截、RADIUS 认证、ACL 动态下发和会话老化管理。如果没把这些链路想清楚上线后最常见的三个问题是认证页弹不出来、认证成功但流量不放行、用户频繁掉线重认证。这篇文章面向正在做无线网络交付的运维和集成工程师讲清楚 Portal 方案怎么选、怎么配置、参数怎么调以及我实际调试中踩过的坑。2. 无线接入认证的组网架构Portal、RADIUS、AC/AP 三者的认证链路Portal 认证在无线网络里通常由“终端—AP—AC—Portal服务器—RADIUS服务器”组成。C端用户不看这些但方案能不能稳定落地取决于这三个实体之间的通信细节。下面先选型再走一遍认证流程最后说网络规划。2.1 三种常见方案选型本地 Portal、外部 Portal 还是云 Portal常见做法有三种。本地 PortalAC 或者一台小服务器内置 Portal 页面适合单一园区、几百个终端的规模。好处是调试快不依赖外部链路坏处是页面定制能力弱短信发送、第三方登录对接都很麻烦。如果方案里明确写了“WebPortal”通常默认页面由 Web 服务承载本地 Portal 往往就是嵌入式 Web 服务。外部 Portal独立一台 Web 服务器Nginx/Apache/Tomcat承载认证页AC 只负责把未认证用户的 HTTP 请求重定向过去。这个形态最主流也是 WebPortal 无线接入认证的核心Portal 页面与网络接入控制解耦。它的适用场景是有品牌定制、对接短信平台、需要统一多分支入口的企业。云 Portal页面部署在云端各地 AC 直接将用户请求重定向到云端域名。适合多分支连锁、总部集中认证。但要注意分支出口到云端的链路一旦抖动用户就会弹不出页面或认证超时。我一般建议分支侧保留一份本地页面作为逃生通道。选型参数可以这样判断考虑点本地 Portal外部 Portal云 Portal单点容量较低可水平扩展视云端容量页面定制弱强强部署位置AC 内/旁挂内网/旁挂公网离线容灾无外部依赖依赖局域网依赖专线/公网典型部署小型园区中型企业/酒店多分支连锁选择时主要看两件事Portal 页面是否要频繁改版以及认证失败时允不允许网络不可用。多数情况我会选外部 Portal开发方便后续换短信通道也不动 AC 配置。2.2 认证流程里的四个关键角色DNS、HTTP 重定向、RADIUS、会话老化一次标准流程是这样终端关联 APDHCP 拿到 IP默认网关和 DNS 正常但 AC 侧没有给这个终端下发放行 ACL。用户打开浏览器输入网址HTTP 请求经过 AC 时被拦截AC 返回 HTTP 302 到 Portal 服务器地址。Portal 服务器回送登录页面用户提交账号密码后Portal 服务器通过 RADIUS 协议发送 Access-Request 给 RADIUS 服务器。RADIUS 校验通过返回 Access-Accept同时携带下发给用户的策略属性如 Filter-Id、Session-Timeout。AC 收到 Accept 后在硬件表项里写入该终端的 ACL 放行规则并启动会话计时Portal 页面跳转到“认证成功”提示页。这里面最容易出问题的不是第 4 步而是第 2 步。现在用户打开手机动不动就是 HTTPS 网站而 AC 劫持的是 HTTP 报文HTTPS 请求无法读取域名只能按 IP 放行或再等用户主动访问 HTTP。所以我在做组网时会给未认证用户一个 DNS 策略强制把已知 Portal 域名解析到 Portal 服务器同时把访问外部网络的 HTTP 请求重定向到 Portal 地址。RADIUS 属性里常用参数有这些Session-Timeout单次认证的总时长单位秒通常设 8640024 小时或按访客场景设 4808 小时。Acct-Interim-Interval计费更新周期一般 300 秒到 600 秒。太短增加服务器压力太长会导致 AC 侧会话被提前老化。Filter-IdACL 编号认证通过后交换机/AC 依据它找放行规则。Idle-Timeout空闲超时单位秒常用 600 到 1800。这个参数决定用户挂机多久会被踢下线。我见过不少配置把 Session-Timeout 设成 7200结果视频看两小时准时掉线用户骂骂咧咧。后面 4.3 小节会专门讲这个。2.3 落地前的网络基础VLAN 划分与 IP 地址规划Portal 认证要求终端在认证前就能访问 DNS 和 Portal 服务器否则重定向后页面打不开。所以网络规划的第一件事是划分 VLAN访客 WiFi 用单独 VLAN员工 WiFi 用另一个 VLAN二者在三层上隔离。常见做法是给访客 VLAN 分配一个独立的 IP 网段例如 172.16.100.0/23网关放核心三层交换机或 AC 上。Portal 服务器和 RADIUS 服务器放在管理网段终端到它们的路由要提前打通。注意不要在访客 VLAN 里加访问管理网段的静态路由只放行 UDP 1812/1813 和 TCP 80/8080Portal 页面端口即可。然后是转发模式。Portal 认证和流量转发方式有关我通常建议访客网络用集中转发AP 把业务流量封装到 ACAC 做 Portal 拦截和 ACL 下发逻辑清晰。如果园区规模大、流量大的场合用本地转发业务流量从 AP 直接走Portal 服务器也可以通过“AC——AP——交换机——Portal服务器”路径访问但必须在每台设备上配置重定向规则麻烦不少。在 AC 上启用 Portal 前先确认 SVI 和 DHCP 配置。下面是一段接口配置示意用的伪 CLI实际厂商命令会不同# 访客网段三层接口 interface vlan 100 ip address 172.16.100.1 255.255.255.0 dhcp server select subnet dhcp server dns-list 8.8.8.8 114.114.114.114 # 指向 Portal 服务器的路由 ip route 10.10.0.0 255.255.255.0 172.16.0.1这段配置的逻辑先给访客 VLAN 配置网关和 DNS再确保 AC/三层交换机到 Portal 服务器所在网段可路由。这里的 DNS 建议配两个避免第一个失效后终端解析不了 Portal 域名。3. 把 Portal 方案落地从 AC 侧模板到 RADIUS 联调步骤这一章是实际配置阶段。我会把 AC 上的 Portal 模板、RADIUS 对接、以及联调验证步骤拆开讲。每一条配置后面解释为什么要这么设。3.1 AC 上的 Portal 认证模板配置与参数详解不同厂商 AC 的命令差异较大但抽象出的对象是共通的Portal 服务器模板、认证模板、无线服务绑定。第一步定义 Portal 服务器。外部 Portal 方案下AC 要告诉终端重定向到哪个地址# 创建 portal 服务器模板 wlan portal server name portal-url http://10.10.0.10:8080/portal/ portal-key plain Portal123 disable-https-redirect参数说明portal-url是认证页地址AC 会把未认证终端的所有 HTTP 请求重定向到这个地址portal-key是 AC 与 Portal 服务器之间的共享密钥用于重定向请求的 URL 签名校验disable-https-redirect是关闭 HTTPS 劫持在有些版本里默认不开启开了反而会引发证书告警。多数情况下直接关掉 HTTPS 劫持让终端用户看到“认证成功”提示后自己点浏览器即可。第二步在无线服务模板上绑定 Portal 认证wlan service set visitor ssid Visitor security open portal enable portal server name user-isolate enable这里security open表示访客 SSID 不做 WPA2 加密因为 Portal 本身就负责身份认证加密反而增加连接门槛。不过现在手机系统会提示不安全介意的可以改成 WPA2-PSK 再叠 Portal 认证但两层认证会让用户困惑我不推荐。参数上注意user-isolate enable是用户二层隔离防止访客互相访问。这个在酒店、企业访客场景几乎是必开项后面第 5 章会再讲。3.2 RADIUS 服务器侧认证、计费与属性返回Portal 服务器收到用户账号密码后并不是自己确认而是通过 RADIUS 找后端认证。所以 RADIUS 侧要先加好 NAS。这里的 NAS 通常是 AC 或者 Portal 服务器取决于方案里谁发起 RADIUS 请求。常见做法是 Portal 服务器既做 Web 页面又做 RADIUS 客户端。在 FreeRADIUS 里常见配置是client 172.16.0.2 { # Portal 服务器 secret Portal123 shortname portal nastype other }然后在 users 文件里给测试账号设置认证属性和下发策略testuser Cleartext-Password : 123456 Filter-Id visitor-policy, Session-Timeout 86400, Acct-Interim-Interval 300说明Filter-Id是一个字符串AC 会拿这个字符串去匹配自己的用户策略字典Session-Timeout让 AC 在 24 小时后强制断线重认证适合访客网络Acct-Interim-Interval让终端每小时上报一次流量统计Portal 后台才能看到实时在线时长和流量。联调时最容易出错的是共享密钥不一致或者 RADIUS 端口被策略拦截。RADIUS 认证用 UDP 1812计费用 UDP 1813这两个端口在防火墙上必须放行且客户端源地址不能做 NAT——很多分支企业把 Portal 服务器放在管理网段而做了 NAT结果 AC 收到 Access-Request 源地址变了直接丢包。3.3 模拟终端联调用最小命令验证认证链路配好后不要急着拿真机开蹭先在 PC 上模拟终端验证链路。我会在终端侧做三步验证第一步确认未认证时访问 HTTP 是否被重定向curl -I http://1.1.1.1如果 AC 和 Portal 都配好了应该看到一个302 Location: http://10.10.0.10:8080/portal/。没有 302 就去查 AC 的 portal server 是否绑定到服务模板或者 AC 上的重定向规则没有生效。第二步用 RADIUS 测试工具验证账号radtest testuser 123456 172.16.0.2:1812 Portal123FreeRADIUS 自带 radtest如果返回Access-Accept说明 RADIUS 链路通、共享密钥对。如果返回Access-Reject看 RADIUS 日志里的Module-Failure-Message多半是用户密码错误或者没有匹配到群组。第三步打开 FreeRADIUS 调试模式看真实的认证流程日志radiusd -X调试日志会打出 Access-Request、Access-Accept 以及 AC 发来的计费报文。三个步骤配合使用可以在拿手机测试前就把链路问题解决。联调完后再用手机连 WiFi 验证。这时候要留意iOS 和 Android 对 Portal 的探测行为不太一样这在第 4 章说。4. Portal 认证翻车现场五个必踩的坑和排查方法这一章是重点每一条都是我实际交付中踩过或者帮别人擦过屁股的。都是按现象、原因、解决步骤写。4.1 弹不出认证页面DNS 劫持与 HTTPS 的“漏网之鱼”现象用户连上 WiFi打开微信可能不说话但打开浏览器访问百度或点开朋友圈里的链接页面一直转圈没有弹 Portal。原因有两个。第一AC 的重定向规则只匹配 HTTP 流量而用户习惯直接输 HTTPS 地址AC 无法解出域名只能看到目的 IP没法判断要不要将用户重定向到 Portal。第二终端连上 WiFi 后使用 DHCP 下发的 DNS 解析 Portal 服务器的域名但某些运营商私有 DNS 或终端的私有 DNS 覆盖了它导致请求 Portal 域名解析失败。解决我们在 AC 的 Portal 配置中打开“预认证域名放行”把portal.企业.com加入免认证域名白名单。同时把未认证用户的 443 出站流量全部丢弃只保留 80 和 DNS 放行这样即使终端先发 HTTPS 请求也会因为没有路由而走回自动探测流程。手机系统检测到网络受限后会自动弹出“需要登录”的系统气泡用户点头即可打开 Portal 页。这是标准做法可以接受。4.2 认证成功后仍然无法上网ACL 下发与 UDP 方向现象Portal 页面显示认证成功随后跳转但用户打开网页就是加载不出来微信也发不了消息。原因认证通过后 AC 下发的 ACL 只放行了 TCP 80/443但终端访问网页前先要 DNS 查询。DNS 报文是 UDP 53如果 ACL 没放行域名解析失败页面自然打不开。还有一种情况ACL 放行的目的地址写的是任意源到任意目的但反向流量没有建会话表项或者设备开了“会话检测”ICMP 没放行导致用户以为彻底不能上网。解决在认证通过的授权策略里至少要放行# 认证后用户策略示例 rule 5 permit udp any any eq 53 rule 10 permit icmp any any rule 15 permit tcp any any eq 80 rule 20 permit tcp any any eq 443注意规则顺序UDP 53 必须放在前面因为如果命中后面的permit tcp 任意不会管 UDP。另外如果 AC 下发 ACL 的“入方向”没有放那技术指标再高也没用。一般要同时在 L3 接口和无线服务绑定地方各做一次匹配。4.3 客户端频繁掉线会话超时与 RADIUS CoA/DM 的配合现象访客网络用得好好的每隔一段时间就掉线提示重新认证而且掉线时间往往一模一样比如每 2 小时一次。原因RADIUS 服务器在认证成功时给 AC 返回了Session-Timeout7200AC 严格执行到时间就拆会话。很多网管不知道Session-Timeout的含义照抄了模板里的数值。另外Portal 服务器自己的会话表也可能设置了一个独立超时两边的计时基准不同导致 AC 先断。解决不要在 RADIUS 侧随意下发Session-Timeout除非明确要限制单次在线时长。如果确实要限制可以把两个地方调成一致。更重要的一点RADIUS 计费更新周期Acct-Interim-Interval不能太长我一般设 300 秒这样 AC 知道终端还活着。如果会话被异常终止还要靠 Radius 的 CoA (Change of Authorization) 机制让 Portal 服务器主动向 AC 发送端口 3799 的报文来踢人或调整策略。别忘了在 AC 侧开启 CoA 功能并放行 UDP 3799。4.4 手机连上 WiFi 但打不开页面Android 与 iOS 的系统检测差异现象同一套 PortaliPhone 连上后几秒就弹出“需要登录”不少安卓手机却死也不弹用户手动打开浏览器访问百度才出来。原因iOS 和 Android 都内置“网络连通性探测”机制。iOS 访问captive.apple.com域名Android 访问connectivitycheck.gstatic.com/generate_204或connectivitycheck.android.com期望得到特定的响应码来判断网络是否受限。如果 AC 把这些探测请求当成普通 HTTP 拦截并重定向Android 的检测逻辑会认为“重定向了说明有 Portal 需要登录”于是弹出系统提示但有些 AC 把探测请求直接丢弃或返回连接错误Android 就以为网络不通不触发系统提示。解决把这两个域名加入“免认证域名白名单”并且让 AC 对它们的 HTTP 请求返回 302 到 Portal 页面。注意白名单要加完整路径比如connectivitycheck.gstatic.com和generate_204否则 Android 最新版本仍有可能绕过。实测中iOS 比 Android 好伺候只要放行了captive.apple.com即可。4.5 认证完成但后台记录的 IP 对不上DHCP 触发的一个黑匣子问题现象Portal 后台显示“用户 A 在线”但打开网管一看这个 IP 已经分给了用户 B。在线用户列表里 IP 与 MAC 错位导致审计时只能看时间定位不到人。原因终端在认证前通过 DHCP 拿到 IP认证后又去续租或换地址。如果 AC 上的 IP-MAC 会话表没有跟着更新Portal 服务器抓的 IP 还是老地址。另一个常见来源是终端重启后重新 DHCP 申请但 AC 的 Portal 会话还保留着旧 IP 的条目。解决在接入交换机和 AC 上同时开启 DHCP Snooping并把终端 IP 与 MAC 绑定写入动态表项。更彻底的做法是开启“Portal 认证前 IPoE”或者用 AC 做 DHCP Server让 AC 在发租约时就记住 IP-MAC 对应关系。Portal 后台取地址时不直接用认证报文的源 IP而用 DHCP Snooping 表里当前 IP 对应的 MAC。这条解决后纠纷会少很多。5. 运营与安全层面的加固白名单、授权策略和逃生通道Portal 认证能控制上互联网但一个合格的方案必须考虑打印机、监控、访客隔离和页面合规这些细节。这一章讲怎么把方案用得更稳。5.1 终端白名单与 MAC 免认证打印机、监控、挂墙设备不弹页面打印机、摄像头、门口音乐盒这类设备没法输账号需要绕过 Portal 认证。常见的做法是 MAC 免认证AC 上配一个免认证 MAC 表命中后直接放行不再重定向。wlan mac-auth user MAC-print* action permit service-template visitor这个配置的核心不是命令而是流程MAC 白名单适合内网已知设备未知设备尽量不要配通配 MAC否则等于给网关开了后门。另外很多设备支持 MAC 随机化移动终端就不要加到白名单了只有固定终端可以。实际部署中建议打印机等设备固定在一个 SSID使用 WPA2 连接再做 MAC 认证或者干脆放到员工 VLAN 并用 RADIUS MAC 认证叫 MAC Authentication Bypass, MAB。这样即使管理后台也能追踪到是哪个终端。5.2 访客网络的流量隔离与带宽控制Portal 认证通过后用户不能“为所欲为”。至少要做两件事二层隔离和带宽限制。二层隔离在 AC/AP 上表现为user-isolate它让同一 VLAN 下的终端不能互访防止有人开热点甚至抓包。带宽控制每个用户限制为下行 2Mbps上行 2Mbps看视频足够但不至于占用太多出口。可给 VIP 或员工设置更高带宽。授权策略要结合账号角色。RADIUS 服务器可以根据用户 group 下发不同的 Filter-Id对应到 AC 上不同带宽模板。例如wlan user-profile visitor-bw inbound-rate 512 # 单位 kbps上行限速 512kbps outbound-rate 512 # 下行 512kbps参数说明很多现场的投诉“太卡了”不是因为 Portal 认证有问题而是带宽限得太狠。访客场景可以把下行放宽到 2~5Mbps上行限制 1Mbps办公场景则不限制但做流量优先级。注意 AC 的限速单位不同有的配 bps有的配 kbps全部配完后用大流量测试一遍别根据显示数字猜。5.3 Portal 页面合规与逃生通道的取舍Portal 认证页往往承载着告知责任。常见做法是在首页展示“上网须知”和“免责声明”用户勾选后才能继续登录。这不仅是合规要求也是网络管理员给自己留的免责证据。后台要保留认证日志至少一段时间包括成功和失败的尝试。注意别把密码明文写进日志免得泄漏。逃生通道指的是未认证用户也能访问的一小部分资源比如“如何连接 WiFi”的说明页、设备升级服务器、或紧急联络页面。实现上就是域名白名单在 AC 的 pre-authentication 规则里放行特定目的 IP/域名。设计逃生通道时要注意“逃生”不等于“绕过”只放行运营商客服和本网络帮助页不能放行游戏更新服务器或视频 App 的 IP否则用户发现只要访问这些域名就能白嫖互联网认证系统就形同虚设。我一般把逃生通道做成静态的免认证 ACL只包含三个条目DNS、Portal 服务器 IP、说明页服务器 IP。然后通过反复测试验证未认证状态下能打开说明页但无法访问任意公网 IP。这一步在验收时很有说服力。6. 最后调试用抓包定位 Portal 认证失败的关键路径一个亟待解决的问题是用户说“连不上网”但 Portal 后台又显示他认证成功矛盾数据怎么查最有用的工具是抓包。按照链路四步走每步看关键报文。第一步在终端侧抓包看 DHCP 是否取得合法 IP。如果终端没有拿到 IPAC 上任何 Portal 策略都不会生效。第二步在 AC 的上联口做镜像过滤终端 MAC 的 HTTP 请求看是否有 302 重定向。第三步在 Portal 服务器抓 UDP 1812 端口看 Access-Request 是否到达、Access-Accept 是否返回。第四步如果前三步都没有问题就在 AC 上执行display portal user伪命令查看在线会话表确认 ACL 是否已经下发。抓包命令可以用 tcpdumptcpdump -i any host 终端MAC and port 53 or port 80 or port 1812 -w portal-debug.pcap参数说明-w保存 pcap便于后续用 Wireshark 打开。重点看三段DNS 应答的源端口是否来自 DHCP 下发的 DNS 服务器这里往往能发现 DNS 被劫持HTTP 响应是不是 302 且Location指向 PortalRADIUS 报文的识别符和校验值是否连续共享密钥错误会导致 Access-Accept 突然消失。我吃过一次亏有一次报表显示认证成功但现场用户全部上不了网抓包才发现 AC 下发的 ACL 里有一个规则把 80 端口给拒绝掉了而测试机恰好用了 443所以测试通过、真实用户翻车。这件事之后我养成了两个习惯一是联调时除了测试浏览器还要用curl http://baidu.com和curl https://baidu.com各跑一遍二是在收尾前把 Portal 白名单、免认证 MAC、逃生通道的导出结果贴在项目文档里。如果你照着这里的排查顺序走一遍80% 的 WebPortal 无线接入认证问题都能定位到具体环节。希望帮到你。本文还有配套的精品资源点击获取