清华校园网认证笔记

Linux

清华校园网认证笔记

经历

故事发生在一个普通的夜晚，办公室电脑断网重连：

  1. “半身不遂”的连接：

    我在浏览器输入 login.tsinghua.edu.cn，页面跳转到了 https://auth4.tsinghua.edu.cn/...ac_id=159...。登录成功后，百度（IPv4）可以正常访问，但访问 知乎（IPv6）时，浏览器直接报错，提示无法连接。

  2. HSTS 的红牌警告：

    在试图摸鱼打开 zhihu.com 时，Chrome 并没有跳转到登录页，而是给出了一个鲜红的 HSTS 错误（连接不安全），且无法跳过。

  3. 失效的“万能钥匙”：

    我试图直接输入 auth6 的登录连接，回车后默认跳转到了 .../srun_portal_pc?ac_id=1...，系统竟然提示我“请清理浏览器缓存”，拒绝显示登录框。

  4. 神秘的解药：

    我访问了 http://www.gov.cn，这回浏览器没有报错，而是丝滑地跳转到了认证页面。这次我注意到，跳转后的地址是 auth6 开头，且参数是 ac_id=159。认证通过后，知乎终于能上了。

  5. 实锤：

    为了验证猜想，我在 Chrome 的 chrome://net-internals/#hsts 工具中删除了 zhihu.com 的 HSTS 记录。随后强制访问 http://zhihu.com（注意是 HTTP），这次它没有报错，而是成功被劫持到了正确的登录页。

经过和 Gemini 的对话以及一个古老的清华校园网文档，我大概理解了上面这个过程是怎么一回事，让 Gemini 把零散的对话沉淀成了一篇博客。

这到底发生了什么？

为什么“复制粘贴”的链接会失效？（关于 ac_id）

现象回顾：在办公室使用 ac_id=1 无法打开页面，必须用 ac_id=159。

技术揭秘：

ac_id 全称是 Access Controller ID（接入控制器 ID）。在清华校园网的架构中，它大概代表我们物理位置所属的网关区域。

根据《清华大学校园网使用简介》文档，清华校园网采用了物理分区架构，包括紫荆核心、图书馆核心、主楼核心等。 * ac_id=1：可能对应早期的某个默认网关。 * ac_id=159：对应我办公室所在的特定区域网关。

结论：认证系统不是一个巨大的单一入口。当你身在办公室（159区），却拿着 1 区的“通关文牒”去请求服务器，服务器查询 1号网关发现根本没有你的 IP 记录，逻辑报错，给出了误导性的“清理缓存”提示。

教训：不要收藏带参数的登录页 URL，让网关根据你的物理位置自动分配 ac_id 才是正解。

为什么 Auth4 和 Auth6 是分开的？

现象回顾：登录了 auth4 后，百度能上，知乎上不去。

技术揭秘：

清华校园网实行 IPv4 和 IPv6 双栈管理。

  • Auth4：负责 IPv4 的计费和准入。
  • Auth6：负责 IPv6 的准入。

文档中提到一个关键点：“认证成功后，依据 MAC，v4/v6 同时打开，仅适用于二层接入用户。” * 二层接入（宿舍）：直接经由多个交换机连接到主交换机，你在宿舍认证一次，系统因为能看到机器的 Mac 码，能顺藤摸瓜把你的 v4/v6 都开了。 * 三层接入（办公室/实验室）：经过了院系的路由器，主交换机无法得知我们机器的 Mac 码。在经过了路由器的复杂网络环境下，这种“联动”机制失效了。

结论：我在入口处（login.tsinghua.edu.cn）只完成了 IPv4 的认证。我的电脑系统（Windows/Mac）在访问知乎时优先选择 IPv6 通道，但此时我的 IPv6 并没有“买票”，所以被网关拦截。

HSTS：浏览器安全的“好心办坏事”

现象回顾：未认证 IPv6 时，访问知乎报错，无法弹出登录页。

技术揭秘：

校园网认证（Captive Portal）的核心原理是“中间人劫持”。当你未登录时，网关会拦截你的 HTTP 请求，伪装成目标网站，给你返回一个 302 重定向指令，跳到登录页。

但是，现代网络为了防止劫持，引入了 HSTS（HTTP Strict Transport Security） 机制。 * 知乎（Zhihu）：启用了 HSTS。浏览器记住了“知乎必须加密连接”。 * 冲突爆发：网关试图劫持知乎的请求时，无法提供知乎的合法证书。浏览器检测到证书不匹配，且因为有 HSTS 记录，严禁用户忽略警告继续访问。 * 结果：你甚至没有机会看到登录页，直接被“连接不安全”挡在门外。

这也解释了为什么我在 chrome://net-internals 清除 HSTS 记录后，强制用 HTTP 访问知乎就能跳转了——因为浏览器暂时“忘”了知乎需要加密，允许了网关的明文劫持。

为什么 http://www.gov.cn 是“神队友”？

现象回顾：访问 gov.cn 能成功触发跳转，没有报错。

技术揭秘：

虽然 www.gov.cn 支持 HTTPS，但它应该没有启用 HSTS。

流程：

浏览器发起 HTTP 请求 -> 网关（发现未登录） -> 拦截请求 -> 重定向到 auth6 登录页 -> 成功！

而对于 1.1.1.1 或 google.com 这种网站，浏览器内置了强制 HTTPS 策略，请求还没发出网卡就被浏览器自动升级成加密请求，网关根本没机会拦截。

总结与最佳实践

通过这次调试，我们理清了三个关键点：

  1. 物理位置决定 ac_id：不同区域（宿舍、教学楼、办公室）对应的网关 ID 不同，不要混用 URL。
  2. 网络层级决定认证方式：在三层网络环境下，IPv4 和 IPv6 需要分别认证。
  3. HTTP 是触发认证的唯一解：在 HSTS 普及的今天，想要快速弹出登录框，必须访问一个不支持 HTTPS 或浏览器不强制 HTTPS 的网站。