CERNET 国际学术资源访问专用通道 技术架构分析
摘要
本文通过 DNS 解析测试、TLS 握手分析、路由追踪对比、源 IP 验证、流量中断行为观测等手段,对中国教育和科研计算机网(CERNET)部署的"国际学术资源访问专用通道"进行了系统性的技术分析。该系统基于 CERNET 主干网路由劫持、Apache Traffic Server(ATS)代理集群、IP Spoofing 配合 FlowSpec 流量工程实现了一套白名单制、具备全流量审计与实时内容篡改能力的学术资源访问代理体系。
一、系统组成与入口
该系统由以下组件构成:
- 门户站点:
scholar.edu.cn(WHOIS 注册方为清华大学),提供定制浏览器下载及相关资源入口 - 定制浏览器:基于常规浏览器,未做深层修改,仅内置自签名根证书(
Scholar Root CA v1和Scholar Service V2)和专用 DNS-over-HTTPS 地址 - 专用 DoH 服务器:
doh.scholar.work(ICP 备案主体为长安通信科技有限责任公司,系 CNCERT 全资子公司) - 代理集群:劫持使用 IP 段
205.164.50.20x(AS18779, EGI Hosting, Santa Clara),物理部署于 CERNET 主干网内部
客户端侵入性极低:不安装 VPN 客户端、不修改系统代理配置、不加载内核模块,仅通过根证书信任和 DNS 指向两项变更实现流量引导。
二、DNS 控制层
doh.scholar.work 维护一份域名白名单。白名单内域名(包括 Google、Wikipedia、GitHub、Docker Hub、YouTube 及部分学术出版商等)解析至 205.164.50.20x 段地址;白名单外域名返回正常解析结果。
这一层实现了域名级的选择性隧道(split tunneling),仅被批准的域名流量进入代理通道。
三、CERNET 主干网路由劫持
3.1 路由对比测试
对代理 IP 205.164.50.201(TCP 443)与同 AS 相邻网段 IP 205.164.49.254 分别进行路由追踪,结果如下:
205.164.50.201(代理入口,TCP 443):
205.164.49.254(同 AS 邻段,ICMP):
3.2 分析
两个目标 IP 同属 AS18779,但 RTT 差异接近 200ms。205.164.50.201 在第 8 跳(CERNET 北京核心节点 101.4.112.97)之后即到达,实际 RTT 约 35ms,表明其从未离开中国大陆。205.164.49.254 则经过正常的国际路由(CERNET 香港 → Cogent 洛杉矶 → 圣何塞),RTT 约 234ms。
此外,该劫持仅对 TCP 443 端口生效,其他端口和协议组合不触发。
结论:CERNET 在其主干路由器上对 205.164.50.200-205.164.50.209 网段实施了基于端口的策略路由或 BGP 劫持,将该网段的 TCP 443 流量截留至部署在 CERNET 内部(推测位于北京)的代理集群。使用名义属于美国 AS 的地址空间可能是为了避免与 CERNET 自有地址段的路由策略产生冲突。
四、代理服务层
4.1 代理软件识别
对不可达域名的连接超时响应暴露了代理软件特征:
该错误页面的格式、措辞和 HTTP 头部特征与 Apache Traffic Server(ATS) 的默认错误模板一致。
需注意,此处 anthropic.com 返回 502 并非"域名被拒绝访问"的表现。ATS 接受了 TLS 连接并完成了握手,说明该域名位于白名单内;502 是 ATS 无法连接至上游服务器(可能是远端主动拒绝或 TLS 握手失败)。真正不在白名单中的域名,ATS 在 TLS 握手阶段即拒绝连接,不会返回任何 HTTP 响应。
4.2 TLS MITM
代理对客户端使用 Scholar Service v1 证书进行 TLS 终止。该证书的 SAN 列表包含大量域名。代理解密客户端请求后,以代理自身身份向上游目标发起独立的 TLS 连接。
该根证书文件如下:
一个旁证:客户端侧协商结果为 TLS 1.2,而当前主流站点(如 Cloudflare 托管的 anthropic.com)均支持 TLS 1.3。这说明客户端握手的对象是 ATS 而非目标服务器。
同时浏览器内包含一个未观察到使用的 Scholar Service V2 根:
五、MITM 内容审计与篡改
代理并非仅被动记录流量,而是在必要时对内容实施实时篡改。
5.1 YouTube 访问控制
YouTube 域名处于白名单内,但 ATS 中间件对其实施了路径级的访问控制。几乎所有直接访问路径——包括首页、搜索功能、直接访问 /watch 页面——均被中间件拦截并返回 HTTP 403 阻断页面。
唯一可行的观看路径为:通过 https://scholar.edu.cn/ytb/#/home 提供的视频列表进入指定上传者的频道页面,再从频道页面打开视频。仅部分视频可正常播放。
这意味着代理在 HTTP 层对请求 URL 进行了实时匹配与过滤,而非简单的域名级放行/拦截。
5.2 Wikipedia 首页内容删除
Wikipedia 部分条目页面可正常访问,但中文 Wikipedia 首页经过实时内容篡改:首页各栏目(特色列表、你知道吗、新闻动态、历史上的今天等)中的 所有文字内容被移除,仅保留配图和超链接框架。
该篡改具有实时性——各栏目的条目数量与正常版本一致,显示内容并非静态替换页面,而是代理对上游响应进行了实时的 DOM 级处理后再转发至客户端。
六、出口路由与 IP Spoofing + FlowSpec 机制
6.1 出口 IP 行为差异
针对不同目标站点,代理的出站源 IP 表现出两种不同行为:
保留用户原始 IP(Google、Wikipedia 等):
此处 219.x.x.x 为测试终端所在高校的 CERNET 出口 IP。该结果通过两种独立方法交叉验证:一是 Google 显示的客户端 IP;二是登录 Gmail 后在另一终端查看账号活动记录中的登录 IP,确认目标服务器确实看到的是该高校 IP 而非代理服务器地址。
使用代理自有出口(Docker Hub、OpenAI 等):
Docker Hub 看到的是另一个 CERNET 段 IP 42.247.113.x,位于北京。对 OpenAI 的测试则显示使用了一个香港 PCCW 出口 IP。
6.2 IP Spoofing + FlowSpec 流量工程模型
综合以上行为,推断代理出站采用 IP Spoofing 配合 FlowSpec/策略路由的流量牵引 实现源 IP 保留:
- 用户与代理集群建立连接
- 代理以用户原始 IP 为源地址(IP Spoofing)向目标服务器发起上游连接
- 代理同时通过 FlowSpec 或等效的流量工程机制,在 CERNET 主干路由器上注入规则,将匹配
(用户IP, 代理源端口)的回程流量牵引至代理集群 - 目标服务器的响应报文目的地址为用户 IP,在途经 CERNET 主干时被 FlowSpec 规则捕获并导向代理
- 代理接收上游响应,经审计/篡改后转发至用户
由于代理部署在 CERNET 主干网内部,CERNET 路由器不会对来自自身基础设施的源地址进行 uRPF/BCP38 过滤,IP Spoofing 可以成立。
6.3 流量中断行为验证
在对 Wikipedia 进行大文件传输测试时,中途主动断开客户端连接,观测到以下现象:
- 客户端断开后,代理释放会话资源,对应的 FlowSpec 牵引规则随之撤销
- 上游 Wikimedia 服务器因连接突然中断而执行 TCP 重传
- 重传报文目的地址仍为用户原始 IP,但由于 FlowSpec 规则已撤销,这些报文不再被牵引至代理,而是沿正常路由直接送达用户终端
- 用户终端因此收到大量来自 Wikimedia 服务器的非预期报文
该现象与 IP Spoofing + FlowSpec 模型完全吻合:FlowSpec 规则存续期间,回程流量被代理截获;规则撤销后,回程流量回归正常路由直达用户。
6.4 出口选择逻辑
综合各站点测试结果,代理出口策略推断如下:
| 条件 | 出口方式 |
|---|---|
| 目标可经 CERNET 国际链路直达且不封锁教育网 IP | IP Spoofing 保留用户源地址,经 CERNET 国际出口直连 |
| 目标需特殊路由或对大陆 IP 有限制 | 使用代理自有出口节点(如北京 CERNET、香港 PCCW 等) |
| 域名不在白名单中 | TLS 握手阶段拒绝连接 |
| 域名在白名单中但上游不可达 | 返回 ATS 502 错误 |
6.5 开个洞?:Google Cloud PTR 域名
测试发现 *.bc.googleusercontent.com(Google Cloud Engine 实例的 PTR 反向域名)的所有子域均位于代理白名单中。理论上,若攻击者控制一台 GCE 实例,可以令其 PTR 域名解析至该实例 IP,进而通过代理访问任意自定义服务。
然而,该 PoC 无法完成。因为未知原因,代理服务器无法与 GCP 实例正常建立 TCP 连接。在 GCP 上只能收到首个 SYN 包,然后双方都在疯狂重传,最后 502 Broken Pipe。推测为 FlowSpec 未命中或牵引规则有其他白名单限制。
七、访问控制与管理架构
根据公开信息检索,系统准入控制与域名管理可能涉及多个层级:
- DoH 与策略控制:
scholar.work由长安通信运营(CNCERT 全资公司),负责 DNS 白名单维护与核心策略 - 门户与主干网运维:清华大学/赛尔网络作为 CERNET 运营方,负责
scholar.edu.cn门户及主干路由配置 - 学校级准入:各高校需逐级申请开通,部分学校需通过面向学生的需求问卷调查论证必要性。开通后,代理集群根据源 IP 所属学校进行认证
八、完整数据流
九、总结
该系统是一套部署于 CERNET 主干网层面的白名单制学术资源访问代理,其技术架构具有以下特点:
- 网络层控制:利用 CERNET 主干网运营方权限实施路由劫持和 FlowSpec 流量工程,无需在用户终端部署重客户端
- IP Spoofing 透明代理:通过源地址伪造配合 FlowSpec 回程牵引,对部分目标站点实现源 IP 透传,代理对目标服务器接近透明
- 全流量 MITM:所有经代理的 HTTPS 流量均被终止和重新加密,具备完整的内容审计、过滤和实时篡改能力
- 多级出口策略:根据目标站点的可达性和限制情况,动态选择 IP Spoofing 直连或代理出口节点转发
- 行政与技术双重管控:域名白名单、学校准入、内容过滤策略等均由中央层面统一控制
声明:本文所有测试仅通过正常访问和网络抓包进行现象观测,未对目标系统实施任何主动攻击、渗透或逆向工程。分析结论基于可观测现象的合理推断,仅供技术参考,存在不完善部分,不构成对系统实际实现的确定性描述。文中数据反映的是 2026 年 4 月初的系统状态,后续可能发生变更。所有测试均为真实执行,通过 LLM 进行文本润色和匿名化处理。