ROS WEB认证链路解析：从门户模板到七步排障

简介：面向 RouterOS 热点 Web 认证场景的模板包，服务于需要部署公共场所无线接入认证的网络管理员与运维人员，围绕登录页定制、认证跳转和错误提示等环节，提供可直接参考的前端页面与配套素材。压缩包共 71 个文件，约 95KB，以 19 个 HTML 认证页面为主体，覆盖登录、登出、状态、重定向及多种认证入口；同时配有 21 张 JPG、18 张 PNG 和 8 个 GIF 图片素材，以及 CSS 样式表、MD5 脚本和一个 WISPAccessGatewayParam.xsd 参数定义文件，另有 2 个 TXT 错误说明，便于替换品牌元素并核对页面结构。已有 308 人学习，适合希望减少页面从零编写成本、对照完善热点认证流程的读者。借助这些页面模板、图片资源与错误提示文本，可搭建较完整的认证页原型，理解登录、跳转、状态查询与登出页面的组织方式，并据此调整样式、文案和参数文件，为热点认证部署与排错提供可复用参考。

1. 先把 ROS WEB 认证看成一条链路，跳出门户页的局限

“ROS WEB 认证”这几个字，很多人第一反应是“改登录页”：换个背景图、加个标志、把按钮颜色调一下，就以为完事了。真正配置过的人会发现，页面只是最外层，底下是一条完整链路：终端发出第一个请求，被认证网关识别并重定向，浏览器拿到门户页，表单提交凭据，服务端校验后写进在线表，流量才被放行。这条链路上有四个角色——发起请求的终端、负责拦截与放行的认证网关、存放账号和策略的用户库、展示给人的门户模板。四个角色任何一个配置错位，外部看到的现象都一样：网页打不开。所以下面按“链路全景 → 用户库与策略 → 门户模板 → 易错点 → 排障清单”的顺序一层层梳理，先建地图，再填细节。

2. 认证链路全景：一次登录要穿过的六个环节

链路视角的意义在于：任何一个“上不了网”的报障，都能被拆成六个环节里的某一段，逐段验证，而不是靠重装模板反复尝试。这六个环节依次是：终端拿到地址、流量被网关接管、首页请求被应答或重定向、凭据提交、服务端校验并写入会话、会话超时或登出后回收。中间任何一段断了，现象都很像，但排查动作完全不同。

2.1 未认证终端的流量被谁接住

认证网关上的热点服务会绑定在一个具体接口或网桥上，同时指定一段地址池给终端分配地址。终端启动后通过地址分配协议拿到地址，第一个数据包送到网关，服务立刻把它登记成一条“主机条目”，并把状态标成未授权。这时候它还没被拒绝，只是被“扣住”了：DNS 查询由网关自己应答，明文网页请求被改写成一个跳转响应，指向门户页。整个过程对终端是透明的，用户只看到浏览器自动跳了一下。

# 1) 看认证服务绑在哪个接口、用哪段地址池 /ip hotspot print detail # 2) 看终端有没有被识别成主机条目，authorized 列是第一现场 /ip hotspot host print # 3) 看当前在线会话，只有认证成功的才会出现在这里 /ip hotspot active print

三条命令分工明确。第一条里的接口字段决定“谁的流量会被接管”，地址池字段决定终端能拿到哪个网段的地址；如果接口绑错到内网上联口，就会出现“管理员自己也被要求认证”的尴尬。第二条的主机表是排查认证问题的第一现场：未授权说明终端已被识别但没通过认证；压根没有这条记录，问题就不在认证，而在二层可达性、地址分配或者接口绑定。第三条只显示已建立会话的用户，未认证终端永远不会出现在这里，所以拿它判断“有没有登录成功”最直接。

还有一个容易忽略的细节：终端如果是手动配置的静态地址，且不在地址池范围内，很多场景下它连主机条目都不会生成。这类问题表现为“输入任何网址都没反应”，跟认证配置一点关系都没有。

2.2 门户页是怎么被“送到”终端眼前的

把门户页送到终端面前有两种方式，它们经常同时开启，但触发条件不一样。

域名劫持这条路依赖终端愿意用网关做解析。一旦终端被写死了外部 DNS，或者系统开了加密 DNS，劫持就完全落空，用户看到的只是“一直在转圈”。补法是双管齐下：一是在地址分配里强制下发网关作为 DNS，二是把加密 DNS 相关的出口在防火墙上处理掉，让它回到明文解析上来。

重定向这条路只对明文网页请求有效。加密站点在认证前根本建立不了连接，浏览器给出的提示通常是“连接被重置”或者“无法访问此网站”，而不是跳转到门户页。这就解释了那个经典疑问：为什么有的用户说“能上网”，有的说“打不开”——他们访问的站点协议不同。

注意：把门户页本身配置成加密访问可以减少凭据明文传输的风险，但加密门户必须配好证书，否则用户会先撞上一个证书警告页，还没看到登录框就先被吓退。

2.3 放行状态在系统里到底长什么样

“已认证”不是一个抽象概念，它在系统里对应几个可以查到的具体字段。把这几个观察点记牢，判断故障位置会快很多。

会话结束有三种典型路径：用户主动点登出、空闲时间超过阈值被判定掉线、会话时长到期被强制下线。前两种是“温和”的，第三种是“硬”的，用户会突然发现网页打不开，需要重新登录。保活机制的作用是周期性确认终端还在线，保活间隔设得太长，终端已经走了系统还认为在线，占用会话名额；设得太短，网络稍有抖动就会误判掉线，用户频繁被踢。

3. 用户库与策略：账号、认证方式、限速模板三件套

用户库这一层决定“谁能进、进来之后什么待遇”。它由三部分组成：账号本身、账号所属的配置文件、以及认证方式。三者是引用关系而不是复制关系——账号只存凭据和模板名，具体策略全在模板里，改模板等于批量改所有引用它的账号。理解这一点，后面很多“为什么改了没生效”的疑问会自动消失。

3.1 用户配置文件里真正要改的就那么几项

配置文件参数很多，日常真正会动的就那么几个。把它们按“影响什么”分类记，比死记参数名有用。

# 建一个模板：每账号限 2 台设备、上下行各 4M、单次会话 8 小时 /ip hotspot user profile add name=stu-4m shared-users=2 rate-limit=4M/4M \ session-timeout=8h idle-timeout=10m keepalive-timeout=2m add-mac-cookie=yes # 建账号时只引用模板名，不重复写策略 /ip hotspot user add name=test01 password=Test@2024 profile=stu-4m

参数含义逐条说清：共享用户数限制的是“同时在线会话数”，不是“允许登录的设备总数”，第二台设备登录时第一台不会自动掉线，而是直接提示会话数已达上限；速率限制的第一个值是上行、第二个是下行，写成4M/4M只是碰巧对称，如果写成1M/8M就是上行 1M、下行 8M；会话时长到了会强制下线，用户需要重新认证；空闲时长靠流量判断，后台挂着不产生流量的程序不算活跃；绑定 MAC 记忆打开后，同一台设备在有效期内再次打开浏览器可以直接放行，省掉输密码这一步。

这组参数还有一个连带关系值得记住：共享用户数和绑定 MAC 记忆同时开启时，很容易出现“第二台设备提示名额已满，但用户坚称自己只登录了一次”——因为第一台设备的 MAC 记忆还占着一个会话，用户自己并不知道。

3.2 认证方式怎么选，选错会怎样

认证方式决定凭据怎么送到服务端，不同方式对页面文件的要求完全不同。

摘要式认证的流程要记牢：服务端先下发一个挑战值，页面脚本用挑战值和密码算出摘要，随表单一起提交。这意味着删掉页面里的摘要脚本，或者忘了把挑战字段写进表单，登录会一直失败，而报错信息看起来跟“密码错了”一模一样——这是最容易误判的一类问题。

提示：认证方式是一个列表而不是单选，同时开启多个方式时系统会按顺序尝试。排查时先确认这次到底命中了哪一种，否则会在错误的方向上改配置。

3.3 限速、计费与外部用户库的衔接

账号规模变多之后，本地用户库管理会变得吃力，这时候通常把认证和计费交给外部用户库。对接的关键是两件事：认证请求发得出去，计费报文回得来。

# 外部用户库：只对热点认证服务生效，不影响其他登录入口 /radius add service=hotspot address=10.0.0.9 secret=RadSecret01 timeout=3s # 让指定热点模板走外部认证，并开启计费上报 /ip hotspot profile set [find name=hsprof1] use-radius=yes radius-accounting=yes

第一条里的服务限定字段很关键，不加就会把其他管理入口的认证也一并送出去，后果是管理员自己被锁在门外。密钥必须两边完全一致，多一个空格都会导致请求被丢弃，而现象是“一直提示认证失败”，看不出是密钥问题。超时时间决定外部库无响应时多久放弃等待，设太长会让用户盯着转圈，设太短会在外部库偶尔慢一下时误判失败。第二条开启计费上报后，会话开始、周期上报、会话结束三类报文会依次发出，外部系统靠这三类报文算时长和流量；只开认证不开计费，账单永远是零。

本地用户库和外部库可以并存，这时候要注意同名账号的处理顺序——两边都建了同一个账号，到底以哪边为准，取决于模板里的先后配置。这类问题排查起来很费时间，规范做法是从一开始就约定：要么全本地，要么全外部，不要混用。

4. 门户模板：登录页、错误页、跳转页各管一段

门户模板不是“一个页面”，而是一组页面，每个页面负责链路里的一个时刻。只改登录页不改错误页，用户密码输错时会看到一个默认的、风格完全不同的提示页，体验直接断裂。模板目录里通常包含登录页、重复登录页、已登录提示页、登出页、错误页、状态页、跳转页，以及给特定客户端用的若干规范文件和一个摘要脚本。

4.1 模板目录与变量占位符

模板文件放在认证服务的模板目录下，各版本路径略有差别，但文件构成基本一致。页面本身是静态的，能显示动态内容全靠占位符——服务端在返回页面之前，把占位符替换成当前这次请求的真实值。

这套占位符的价值在于“不用自己拼参数”。很多人图省事，在表单里手写一个固定路径当提交地址，本机测试能过，换个部署环境就全挂——因为提交入口是跟具体服务实例绑定的，必须由占位符动态给出。

4.2 登录表单必须提交的字段

<!-- 提交地址必须用占位符，不要手写固定路径 --> <form name="login" action="$(link-login-only)" method="post" onSubmit="return doLogin()"> <!-- 认证成功后跳回的原始地址 --> <input type="hidden" name="dst" value="$(link-orig)" /> <!-- 弹窗模式下必须带上，否则跳转行为异常 --> <input type="hidden" name="popup" value="true" /> <!-- 摘要认证的两个隐藏字段，缺一个就会一直认证失败 --> <input type="hidden" name="chap-id" value="$(chap-id)" /> <input type="hidden" name="chap-challenge" value="$(chap-challenge)" /> <input type="text" name="username" value="$(username)" /> <input type="password" name="password" /> <input type="submit" value="登录" /> </form>

字段逐个解释：提交地址用占位符，保证门户页部署在哪台设备上都能正确提交；dst记录用户认证前想去的地方，没有它，认证成功后用户会落到一个空白页，得自己重新输入网址；popup用于弹窗式认证窗口，缺了它可能出现“登录成功了但原窗口还是打不开”；chap-id和chap-challenge是摘要认证的关键，少了它们，服务端拿不到挑战值就无法校验摘要，返回的提示往往只有“用户名或密码错误”这一句，极具误导性。

如果页面里带了摘要脚本，提交前要先在脚本里把密码算成摘要再填回表单，绝不能明文提交后又在服务端比对摘要。这一步的典型失误是脚本引入路径写错——页面看起来一切正常，点登录就是失败，控制台里才看到脚本 404。

4.3 页面与错误提示的对应关系

错误提示按来源可以分成几类：凭据不匹配、会话数超限、账号已过期或额度耗尽、当前服务不可用。这几类在服务端是不同的判定，但页面上的处理方式可以统一——用条件标记控制一个提示区的显隐，把原始错误文本放进去，同时给一句人话解释。只显示原始文本，用户看不懂；只显示“登录失败”，运维人员又拿不到线索。

注意：模板改动后不一定立即生效，部分文件需要重新加载认证服务，浏览器还可能缓存旧页面。改完先在无痕窗口验证一次，能省掉大量“明明改了却没变”的自我怀疑。

5. 易错点：Web 认证里最容易出问题的五处

免认证名单漏了门户自身的依赖资源。漏的原因很直观：只想着“要把认证页放出来”，忘了页面还要加载样式表、图标、脚本，甚至第三方字体。这些东西如果不在免认证名单里，页面会加载成一个没有样式的裸表单，用户第一反应是“这系统坏了”。补法是打开浏览器开发者工具的网络面板，把门户页加载时所有非本域请求列出来，逐条加进名单，顺带把支付、短信验证这类外部依赖也一起放进去。

加密站点造成的“部分能上网”误判。用户说“我明明没登录却能打开某个网站”，实际是浏览器缓存了之前的页面，或者终端走了另一条协议通道。这类误判最消耗时间，因为你去查配置，配置本身没错。补法是现场用无痕窗口、换一个从没访问过的域名复现，同时在会话表里确认这个终端到底有没有会话条目——没有会话却能访问，说明它命中了免认证名单或者绑定了免认证。

共享用户数与设备记忆打架。现象是用户反复报“说我名额满了，可我只登了一次”。原因是上一台设备的记忆凭据还在有效期内占着会话，用户换了设备自己没意识到。补法有两条：把记忆有效期调短，或者干脆对流动性大的账号关闭记忆功能；同时在重复登录页上把当前在线设备数列出来，让用户自己看到是哪台设备占着名额。

模板改了但系统还在用旧的。三个原因叠在一起：文件传错了目录、认证服务没重新加载、浏览器缓存了旧页面。三者现象完全一样，都是“改了个寂寞”。补法是固定一套验证流程——先确认文件时间戳变了，再重新加载服务，最后用无痕窗口加禁用缓存的方式打开。三步都过一遍，剩下的才是真问题。

速率限制的方向和单位写反。写法是“上行/下行”，很多人按“下载/上传”的直觉填，结果上下行颠倒，用户测速时发现下载被卡得死死的。单位也容易错，写成不带后缀的数字会被当成另一套单位理解，实际效果差出一个数量级。补法是配置完立刻做一次双向测速，上行和下行分别测，别只测下载。

6. 排障与复习清单：七步定位法

链路摸清之后，排障可以固化成七个动作，顺序从下往上，避免一上来就改配置。第一步，确认终端拿到了地址：地址分配表里有没有这条记录，地址段对不对。第二步，确认终端出现在主机表里：没有就回到二层和接口绑定，有但一直未授权，继续往下。第三步，确认门户页能否打开：打不开先查免认证名单和域名应答，能打开但样式错乱，说明静态资源被拦。第四步，确认表单提交到了正确入口：地址栏在提交后有没有变化，没变化就是表单地址写死了。第五步，确认服务端有没有收到凭据：认证日志里有没有对应的失败记录，一条都没有，说明请求根本没到。第六步，确认会话表有没有生成条目：生成了但用户说打不开网页，问题在放行后的策略，不在认证。第七步，确认会话是怎么结束的：主动登出、空闲超时还是时长到期，三种原因的处置完全不同。

# 按七步顺序走一遍，每条命令对应一步，别跳步 /ip hotspot host print detail # 第 2 步：有没有被识别 /ip hotspot active print detail # 第 6 步：会话有没有建立 /log print where topics~"hotspot" # 第 5 步：服务端收到什么

命令后面跟详细模式，是为了看到完整字段而不是被截断的摘要；日志过滤按主题关键字抓，避免被无关记录刷屏。三条命令的执行顺序就是排查顺序，先看识别、再看会话、最后看日志，因为日志里的失败记录只有在请求真正到达时才会出现。

复习的时候，把下面这张表过一遍，能答上来的打勾，答不上来的回到对应章节。

我自己最初接触这套东西时犯过一个很低级的错：页面改完就直接让用户试，用户说还是老样子，我回头又改了一遍样式，来回折腾了半小时，最后发现是文件传到了上一级目录。从那以后，我每次动模板都强制走一遍“看时间戳、重载服务、无痕验证”这三步，再也没在这上面浪费时间。这份笔记里的链路图、参数表和七步定位法整理成了一份可直接对照的复习版本，需要的话在文末取用。希望帮到你。

本文还有配套的精品资源，点击获取