视频加载失败

Captive:绕过 MDM 网段封锁的超脑热点代理方案

2150 字
11 分钟
Captive:绕过 MDM 网段封锁的超脑热点代理方案

前言#

讯飞超脑作为智慧课堂的教师终端,其设计目标是为课堂教学提供投屏、课件分发、互动问答等标准化功能。然而,任何终端设备只要具备计算能力与网络接口,就存在被”重新定义用途”的可能。

在学生群体中,利用超脑部署本地 Web 服务以扩展课堂功能的做法由来已久。其基本路径是:在超脑上运行自定义后端服务,学生平板连接超脑热点后通过 192.168.40.x(40 网段)内网地址访问该服务。这套非官方方案在相当长的时间内有效运行,为学生自主开发的教学辅助工具提供了运行环境。

但这一路径在近期被彻底阻断。学生平板的 MDM 策略持续收紧,40 网段被列入访问黑名单。任何指向 192.168.40.x 的网络请求均被平板系统直接拒绝,基于超脑的本地服务部署方案自此失效。

MDM 的策略设计不可谓不严密——应用管控、网络过滤、安全策略层层叠加,试图将设备的每一种非授权行为纳入规制。然而,任何系统都存在边界。MDM 可以管控 IP 网段、限制应用安装,但无法在不破坏标准网络协议栈的前提下,干预 DNS 解析过程与 HTTPS 连接建立的全部细节。正是这些协议层面的设计空隙,为课堂网络的自助接入保留了最后一条技术通路。

Captive 正是基于这一思路开发的工具。它不试图绕过 MDM 的应用管控,也不依赖被封锁的 40 网段,而是利用 DNS 劫持与透明代理技术,在协议层开辟一条独立于 MDM 管控范围之外的接入路径。本文将完整阐述其技术原理与实现细节。

声明:本文所述方案仅供技术研究与学习交流,不鼓励任何违反所在机构设备管理规定的行为。使用者应充分了解相关风险并自行承担相应责任。

问题背景#

在超脑热点场景下,学生平板需要访问超脑上部署的本地 Web 服务,面临以下障碍:

  1. 网段封锁:MDM 策略禁止学生平板访问 40 网段(192.168.40.x)。这一限制是决定性的——无论超脑热点分配何种 IP,只要落入 40 网段,流量即被平板系统丢弃;
  2. 域名解析缺失:即使网段不被封锁,学生平板也无法将教学域名解析到超脑热点 IP,需要额外的 DNS 配置;
  3. HTTPS 强制:现代浏览器及 Web 应用普遍强制 HTTPS,本地部署的服务若缺乏有效 TLS 证书,请求将被浏览器直接拦截。

以上问题叠加,使得超脑本地部署的任何 Web 服务对学生平板完全不可达。

Captive 的设计思路#

Captive 的核心策略是:不依赖任何特定网段,通过 DNS 与 HTTPS 协议层的重定向实现透明接入。MDM 可以封锁网段,但无法封锁 DNS 解析流程与 HTTPS 连接建立的标准机制。Captive 正是利用这两个协议层面的必经环节完成流量劫持与转发。

工作流程如下:

  1. 连接热点:学生平板连接超脑开启的 WiFi 热点;
  2. DNS 查询:平板向超脑 DNS 服务器查询特定域名(如 spark.changyan.com);
  3. 劫持应答:Captive 拦截查询,返回超脑热点 IP;
  4. HTTPS 请求:平板向该 IP 发起 HTTPS 请求(目标域名仍为 spark.changyan.com);
  5. 代理转发:Captive 监听 443 端口,终止 TLS 加密后将请求转至本地 9001 端口服务;
  6. 响应返回:9001 端口服务的响应经 Captive 加密后返回平板。

整个过程中,学生设备只需连接热点、输入域名,访问链路自动建立。MDM 管控的 40 网段被彻底绕过。

系统架构#

服务组件#

服务端口协议功能
DNS Server53UDP拦截特定域名的 DNS 查询,返回热点 IP
Reverse Proxy443TCP终止 TLS,转发明文 HTTP 到 localhost:9001

DNS 劫持层#

Captive 启动本地 DNS 服务器,监听 UDP 53 端口。WiFi 热点开启时,DHCP 服务在分配 IP 地址的同时将 DNS 服务器地址指向超脑自身。学生平板连接后,所有 DNS 查询默认由超脑处理。

Captive 的 DNS 服务维护一个预设的目标域名列表(如 spark.changyan.com)。查询命中时,直接返回超脑热点的内网 IP;未命中则向上游 DNS 服务器递归查询。

这一机制的关键在于:DNS 解析是网络通信的必经环节,MDM 无法在不破坏标准网络协议的前提下干预这一过程。Captive 在此环节完成流量导向,后续所有通信均不涉及 40 网段。

HTTPS 反向代理层#

Captive 监听 TCP 443 端口,处理流程如下:

  1. TLS 终结:使用本地生成的自签名证书终止 TLS 加密连接;
  2. 协议降级:将解密后的 HTTP 请求转发至 localhost:9001;
  3. WebSocket 透传:识别 Upgrade: websocket 请求头,建立 WebSocket 代理隧道,支持实时互动应用;
  4. 响应回传:9001 端口的响应经 Captive 重新加密后返回学生平板。

关键点:spark.changyan.com 在此方案中仅作为入口域名标识,实际请求被反向代理到本地 9001 端口。学生平板看到的域名保持不变,但实际通信对象是超脑本地服务。

核心实现#

证书生成#

由于需要处理 HTTPS 流量,必须为拦截域名生成自签名证书。Windows 系统下通过 PowerShell(管理员权限)执行:

Terminal window
New-SelfSignedCertificate -DnsName "spark.changyan.com","ai.changyan.com" -CertStoreLocation "Cert:\LocalMachine\My" -NotAfter (Get-Date).AddYears(5)

学生平板首次访问时需手动接受证书警告。这是本方案唯一的客户端交互成本。

服务启动#

以管理员身份执行启动脚本:

Terminal window
start-hotspot-redirect.bat

管理员权限系 DNS 服务绑定 53 端口所必需——Windows 将 1024 以下端口视为系统保留端口,非管理员进程无权绑定。

功能特性#

特性说明
零客户端配置学生平板无需安装软件或修改网络设置
协议全覆盖支持 HTTPS 与 WebSocket,适配现代 Web 应用
开机自启通过 Windows 计划任务实现系统启动时自动运行
进程守护内置看门狗机制,服务崩溃后自动恢复
热点监控自动检测热点状态,断线后触发服务重启
静默运行所有服务后台运行,不干扰超脑正常教学功能

部署步骤#

环境要求#

  • 硬件:讯飞超脑(Windows 10 / 11 64 位系统)
  • 运行环境:Node.js >= 18.0.0
  • 权限:管理员权限

安装与启动#

Terminal window
git clone https://github.com/ClassIntra/captive.git
cd captive
npm install

完成证书生成后,以管理员身份执行:

Terminal window
start-hotspot-redirect.bat

连通性验证#

学生平板连接超脑热点,访问 https://spark.changyan.com,接受证书警告。若本地 9001 端口服务正常运行,页面应正常加载。此时检查平板网络连接状态,可发现实际通信 IP 为超脑热点 IP(通常为 192.168.137.1),完全不涉及被封锁的 40 网段。

扩展性说明#

Captive 的设计与后端服务解耦——它仅依赖 9001 端口,不关心该端口上运行的具体服务。任何监听 9001 端口的 Web 应用均可通过 Captive 暴露给热点下的设备。新增或修改拦截域名,编辑项目配置中的 targetDomains 列表即可。

总结#

MDM 策略的持续收紧使得基于 40 网段的传统方案不再可用。但系统策略的严密程度终究受限于网络协议本身的设计边界——DNS 解析与 HTTPS 握手作为标准网络栈的必经环节,其协议行为无法被选择性关闭。

Captive 正是利用这一协议层面的固有特性,以 DNS 劫持与透明代理的组合实现了一种轻量级绕过方案。它不依赖任何特定网段,不涉及 MDM 策略的直接对抗,仅通过协议层的重定向完成流量导入。整个方案对学生完全透明,对超脑的正常教学功能无任何干扰,是一种低成本、高可靠的技术替代路径。


项目地址:https://github.com/ClassIntra/captive

支持与分享

如果这篇文章对你有帮助,欢迎分享给更多人或打赏支持!

打赏
Captive:绕过 MDM 网段封锁的超脑热点代理方案
https://www.linearteam.top/introduce-for-captive/
作者
Nevino
发布于
2026-09-03
许可协议
CC BY-NC-SA 4.0

评论区

文章目录

WELCOME欢迎来到 Nevino

很高兴在这里遇见你。