简介这份资源面向网络管理员与RouterOS使用者聚焦ROSRouterOS的Web认证Hotspot功能帮助解决公共场所无线接入的授权与访问控制问题。压缩包共71个文件约95KB以19个html登录与状态页面、21个jpg与18个png界面素材、8个gif图标为主另含css样式、js脚本、xsd参数定义及txt错误说明构成一套可直接套用的认证页面模板。内容覆盖登录、注销、状态、重定向、广告跳转等页面并附带错误提示与参数校验文件便于按品牌需求替换logo、背景与文案快速搭建热点认证入口。已有306人学习下载适合需要定制ROS Web认证登录界面、理解认证流程与页面结构的中初级网络运维人员参考也可作为Radius或本地认证部署时的前端素材与排错对照。1. ROS WEB认证一张被低估的知识地图很多人第一次接触 ROS WEB 认证以为它只是路由器上勾一个选项、填一个密码的事。真到要给别人讲清楚、或者排一个认证失败的故障时才发现自己脑子里根本没有地图认证页面从哪来、账号密码存在哪、跳转流程怎么走、放行规则谁先谁后全是黑匣子。梳理下来会发现ROS WEB 认证其实是一条完整的链路——从客户端发起 HTTP 请求到路由器拦截并重定向再到认证页提交、后台校验、放行上网每一环都有明确的配置点和排错入口。它适合两类人一类是正在系统学 RouterOS 网络配置、想把认证模块吃透的人另一类是已经配过、但一遇到“认证页打不开”“认证成功还上不了网”就卡住的人。这张地图的价值在于它把零散的菜单项串成一条可复现的流程让你知道每一步在干什么、错了该看哪里。2. 认证链路拆解从请求拦截到放行上网2.1 认证的整体数据流ROS WEB 认证的本质是把“未认证用户”的流量先拦下来逼他完成一次身份确认再决定放不放行。整条链路可以拆成五个阶段每个阶段对应 RouterOS 里不同的配置模块。第一阶段是客户端发起请求。用户连上网络后浏览器或 App 会发出 HTTP 请求。注意这里的关键是 HTTP不是 HTTPS——因为认证拦截依赖对明文请求的重定向HTTPS 流量在认证前通常是被直接拒绝或放行的这一点后面易错点会专门讲。第二阶段是拦截与重定向。RouterOS 的 hotspot 服务监听在指定接口上未认证用户的请求会被它捕获然后返回一个重定向响应把浏览器导向认证页面。这个页面可以放在路由器本地也可以指向外部服务器。第三阶段是认证页提交。用户在页面上输入账号密码表单提交到认证服务。这一步涉及登录页的 URL、提交方式、以及是否携带原始目标地址参数。第四阶段是后台校验。RouterOS 拿提交的凭据去比对本地用户库、Radius 服务器或其它认证源。校验通过后会在 hotspot 的活跃用户表里生成一条记录。第五阶段是放行。认证通过的用户被加入允许列表流量正常转发同时系统开始计时、计流量为后续的会话管理和计费做准备。把这五段记住排错时就能按顺序定位是没拦截到还是拦截了但页面没出来还是页面出来了提交没反应还是提交了但没放行。每一步都有对应的查看命令和日志入口。2.2 核心配置模块与参数RouterOS 里和 WEB 认证直接相关的配置集中在/ip hotspot这一棵树下。梳理下来最常打交道的几个模块如下表。模块作用关键参数hotspot server定义认证服务绑定的接口与地址池interface、address-pool、profilehotspot profile定义认证方式与页面行为login-by、html-directory、radiushotspot user本地账号密码name、password、profile、limit-uptimewalled-garden认证前允许访问的地址dst-host、actionip binding绕过认证的例外address、type、bypassedlogin-by这个参数值得单独说。它决定用户可以用什么方式认证常见取值包括http-chap、http-pap、cookie、https等。选http-chap时密码不以明文传输兼容性好选cookie则允许用户在一段时间内免重复登录。多个方式可以用逗号组合但组合顺序会影响页面呈现的登录选项。html-directory指向认证页面的存放目录。默认是hotspot目录里面有一整套模板文件包括login.html、status.html、logout.html、error.html等。想改认证页外观就是改这些文件想让页面提交到自定义后台就要动login.html里的表单 action。walled-garden是认证前的白名单。用户还没登录时默认什么都不能访问但认证页面本身、以及页面依赖的静态资源CSS、JS、图片必须能加载否则页面就是白板。把这些资源的域名或 IP 加进 walled-garden是认证页能正常显示的前提。2.3 认证页与后台的交互方式认证页不是静态展示它要和 RouterOS 的后台服务完成一次交互。理解这个交互才能改页面、接外部认证。默认模板里login.html的表单会提交到路由器自身的认证处理地址。表单里通常包含这几个字段username、password以及一个隐藏字段用来携带用户原本想访问的地址。提交后RouterOS 的 hotspot 服务接收请求校验凭据然后根据结果返回成功页或错误页。如果要接外部认证比如自建的认证服务思路是把表单 action 指向外部地址由外部服务完成校验后再通过 RouterOS 提供的接口把用户标记为已认证。这一步涉及的东西比较多包括认证服务的回调地址、共享密钥、以及用户会话的同步。梳理下来会发现外部认证的难点不在认证本身而在“认证完之后怎么让 RouterOS 知道这个人可以放行了”。一个常见的做法是外部服务校验通过后调用 RouterOS 的 API 或通过 Radius 协议回传认证结果。Radius 方式更标准适合多台设备统一认证的场景API 方式更灵活适合和自有系统深度集成。选哪种取决于你的认证源在哪、要不要跨设备。# 查看当前 hotspot 活跃用户确认认证是否生效 /ip hotspot active print # 查看 hotspot 服务状态与绑定接口 /ip hotspot print detail # 查看认证相关日志排错时最常用 /log print where topics~hotspot这三条命令是排认证问题的基本功。active print看有没有生成活跃会话hotspot print detail看服务有没有正常起来、绑没绑对接口log print看认证过程中到底报了什么。很多“认证没反应”的问题日志里其实写得清清楚楚只是没去看。3. 认证方式与账号体系本地、Radius 与外部源3.1 本地用户库的配置要点本地用户库是最简单的认证源账号密码直接存在 RouterOS 里。适合用户量小、不需要跨设备统一的场景。配置一个本地用户核心是/ip hotspot user下的几个参数。name和password是凭据profile决定这个用户认证后享受什么策略限速、限时长等limit-uptime控制总在线时长limit-bytes-in/out控制流量额度。这些限制参数在做访客网络、临时账号时特别有用。梳理下来本地用户库最容易忽略的是“用户绑定的 profile 和 hotspot 服务绑定的 profile 是不是同一个”。如果用户身上的 profile 和服务上的 profile 不一致认证可能通过但策略不生效表现为“能上网但限速没起作用”。排查时先对一下这两个 profile 名称。另一个点是账号的批量管理。用户多了以后手工加账号不现实通常用脚本导入。导入时注意字段顺序和分隔符格式错了会整批失败而且报错信息不一定直观。3.2 Radius 认证的接入方式当用户量上来、或者有多台设备需要统一认证时本地库就不够用了这时候上 Radius。RouterOS 作为 Radius 客户端把认证请求转发给 Radius 服务器由服务器统一校验。接入 Radius 的配置分两块一是在/radius下添加服务器地址和共享密钥二是在 hotspot 的 profile 里把use-radius打开并指定用哪个 Radius 服务器。共享密钥两边必须一致不一致的表现是认证请求发出去但没回应日志里能看到超时。Radius 认证的排错比本地库复杂因为链路多了一跳。定位思路是分段确认先确认 RouterOS 能不能连上 Radius 服务器网络通不通、端口开没开再确认共享密钥对不对最后确认 Radius 服务器那边有没有收到请求、返回了什么。只看 RouterOS 的日志往往不够还要看 Radius 服务端的日志。3.3 外部认证源的对接思路有些场景下认证源既不是本地库也不是标准 Radius而是自建的用户系统。这时候对接方式就比较灵活常见的有两种。一种是让 RouterOS 继续走 Radius但在 Radius 服务器和自建系统之间做适配把自建系统的校验逻辑包装成 Radius 响应。这种方式对 RouterOS 透明改动最小。另一种是绕过 RouterOS 的认证流程由外部系统直接管理用户的放行状态。具体做法是外部系统在用户校验通过后通过 RouterOS 的 API 把用户加入 hotspot 的 IP binding 允许列表或者直接生成一个活跃会话。这种方式灵活但耦合深RouterOS 版本升级时要留意 API 兼容性。两种思路没有绝对优劣取决于你的认证源改造成本和运维习惯。梳理下来如果自建系统已经支持 Radius 协议优先走第一种如果完全不支持、又不想改再考虑第二种。4. 易漏点与易错点认证失败时先查这几处4.1 认证页打不开的常见原因认证页打不开是最高频的问题。表现是用户连上网络后浏览器一直转圈或者报错根本看不到登录框。第一个易漏点是 walled-garden 没放行认证页依赖的资源。认证页本身能加载但页面里的 CSS、JS、字体文件如果不在白名单里页面就会样式错乱甚至白屏。补的办法是把这些资源的域名逐个加进 walled-garden或者干脆把认证页做成不依赖外部资源的单文件。第二个易漏点是 DNS 没放行。用户还没认证时DNS 查询也可能被拦截导致域名解析不了页面自然打不开。检查 walled-garden 里有没有放行 DNS 服务器地址或者确认 hotspot 的 DNS 配置是否正确。第三个易漏点是接口绑错了。hotspot 服务要绑在用户实际接入的那个接口上绑错了就拦截不到流量表现是“能上网但从来不弹认证页”。用/ip hotspot print detail确认 interface 字段。4.2 认证成功但无法上网的排查顺序认证通过了活跃用户里也能看到记录但就是上不了网。这种问题比打不开页面更隐蔽因为表面上看认证是成功的。先查 IP 地址和路由。认证通过后用户会从 hotspot 的地址池里拿到一个 IP如果地址池配错、或者和现有网段冲突用户可能拿到地址但路由不通。确认地址池范围、网关地址、以及 NAT 规则有没有覆盖这个网段。再查防火墙规则。有时候防火墙里有一条规则把认证后用户的流量也拦了或者 NAT 的 out-interface 配错。排查时临时把防火墙规则禁用掉试一下能快速定位是不是规则问题。最后查 profile 里的限速和策略。如果 profile 里配了限速但数值填错比如填了 0 或者单位写错可能表现为完全上不了网。把限速临时去掉看是否恢复。4.3 HTTPS 与重定向的兼容问题这是一个特别容易翻车的点。WEB 认证的重定向依赖对 HTTP 请求的拦截但现在的网站大量使用 HTTPS。用户访问一个 HTTPS 站点时请求是加密的RouterOS 没法在中间插入重定向通常只能直接拒绝或放行。表现就是用户访问 HTTP 站点会弹认证页访问 HTTPS 站点却直接报错或超时让人以为认证坏了。实际上这是机制决定的不是配置错误。应对思路有几个一是引导用户先访问一个 HTTP 页面完成认证比如在通知里写明二是在 walled-garden 里放行必要的 HTTPS 站点让用户在认证前也能访问三是启用 hotspot 的 HTTPS 登录选项让认证页本身走 HTTPS减少混合内容的问题。梳理下来最稳妥的还是第一条——给用户一个明确的 HTTP 入口。4.4 会话保持与超时设置的坑用户认证后会话能保持多久、什么时候需要重新认证由几个超时参数控制。这些参数配得不合理会出现“刚认证完没多久又要重新登录”或者“人走了会话还挂着占资源”的情况。session-timeout控制单次会话的最长时长到点强制重新认证。idle-timeout控制空闲多久后断开。keepalive-timeout控制心跳检测的间隔。这三个参数要配合使用session-timeout 太长会导致资源占用太短会频繁打扰用户idle-timeout 太短会让用户切个标签页就掉线。还有一个容易忽略的是 cookie 登录的有效期。如果启用了 cookie 认证cookie 的有效期和 session-timeout 是两套逻辑配不好会出现“cookie 还有效但会话已经超时”的矛盾状态。建议把两者的时长对齐减少困惑。5. 复习清单把认证链路走一遍再查漏复习 ROS WEB 认证最有效的方法不是背菜单而是拿一台设备把整条链路从头走一遍每走一步问自己“这一步在干什么、错了看哪里”。下面这份清单可以当作走查顺序。复习项自检问题对应命令/入口服务绑定hotspot 绑对接口了吗/ip hotspot print detail地址池地址池范围和网关对吗/ip pool print认证方式login-by 选对了吗/ip hotspot profile print认证页页面能正常加载吗浏览器直接访问白名单认证页资源放行了吗/ip hotspot walled-garden print账号用户 profile 和服务一致吗/ip hotspot user print放行认证后有活跃会话吗/ip hotspot active print日志认证过程报了什么/log print where topics~hotspot走查的时候建议每改一处配置就重新测一次不要一次改一堆再测否则出了问题不知道是哪处引起的。这是血泪经验——批量改配置看起来快排错时反而慢。还有一个习惯值得养成把认证页的模板文件先备份一份再改。改坏了能快速还原不用重新配一遍。模板文件不大备份成本很低但能省下大量恢复时间。# 备份 hotspot 目录下的认证页模板 /file copy hotspot hotspot-backup # 确认备份存在 /file print where name~hotspot这两条命令在动手改页面前执行一遍相当于给自己留了后悔药。改完页面发现样式崩了、表单提交不了直接把备份目录换回去就行。最后说一个查漏补缺的具体技巧把认证流程拆成“拦截、展示、提交、校验、放行”五段每段单独测。比如想确认拦截有没有生效就故意访问一个 HTTP 站点看会不会跳转想确认提交有没有到达就看日志里有没有收到认证请求。分段测比整体测更容易定位问题也更适合复习时逐个模块确认掌握程度。从那以后我每次配认证都强制自己先走一遍这五段确认每段都有对应的日志或状态可看再去做页面定制和外部对接。希望帮到你。本文还有配套的精品资源点击获取
