前言
讯飞超脑作为智慧课堂的教师终端，其设计目标是为课堂教学提供投屏、课件分发、互动问答等标准化功能。然而，任何终端设备只要具备计算能力与网络接口，就存在被”重新定义用途”的可能。
在学生群体中，利用超脑部署本地 Web 服务以扩展课堂功能的做法由来已久。其基本路径是：在超脑上运行自定义后端服务，学生平板连接超脑热点后通过 192.168.40.x（40 网段）内网地址访问该服务。这套非官方方案在相当长的时间内有效运行，为学生自主开发的教学辅助工具提供了运行环境。
但这一路径在近期被彻底阻断。学生平板的 MDM 策略持续收紧，40 网段被列入访问黑名单。任何指向 192.168.40.x 的网络请求均被平板系统直接拒绝，基于超脑的本地服务部署方案自此失效。
MDM 的策略设计不可谓不严密——应用管控、网络过滤、安全策略层层叠加，试图将设备的每一种非授权行为纳入规制。然而，任何系统都存在边界。MDM 可以管控 IP 网段、限制应用安装，但无法在不破坏标准网络协议栈的前提下，干预 DNS 解析过程与 HTTPS 连接建立的全部细节。正是这些协议层面的设计空隙，为课堂网络的自助接入保留了最后一条技术通路。
Captive 正是基于这一思路开发的工具。它不试图绕过 MDM 的应用管控，也不依赖被封锁的 40 网段，而是利用 DNS 劫持与透明代理技术，在协议层开辟一条独立于 MDM 管控范围之外的接入路径。本文将完整阐述其技术原理与实现细节。
声明：本文所述方案仅供技术研究与学习交流，不鼓励任何违反所在机构设备管理规定的行为。使用者应充分了解相关风险并自行承担相应责任。
问题背景
在超脑热点场景下，学生平板需要访问超脑上部署的本地 Web 服务，面临以下障碍：
- 网段封锁：MDM 策略禁止学生平板访问 40 网段（
192.168.40.x）。这一限制是决定性的——无论超脑热点分配何种 IP，只要落入 40 网段，流量即被平板系统丢弃； - 域名解析缺失：即使网段不被封锁，学生平板也无法将教学域名解析到超脑热点 IP，需要额外的 DNS 配置；
- HTTPS 强制：现代浏览器及 Web 应用普遍强制 HTTPS，本地部署的服务若缺乏有效 TLS 证书，请求将被浏览器直接拦截。
以上问题叠加，使得超脑本地部署的任何 Web 服务对学生平板完全不可达。
Captive 的设计思路
Captive 的核心策略是：不依赖任何特定网段，通过 DNS 与 HTTPS 协议层的重定向实现透明接入。MDM 可以封锁网段，但无法封锁 DNS 解析流程与 HTTPS 连接建立的标准机制。Captive 正是利用这两个协议层面的必经环节完成流量劫持与转发。
工作流程如下：
- 连接热点：学生平板连接超脑开启的 WiFi 热点；
- DNS 查询：平板向超脑 DNS 服务器查询特定域名（如
spark.changyan.com）； - 劫持应答：Captive 拦截查询，返回超脑热点 IP；
- HTTPS 请求：平板向该 IP 发起 HTTPS 请求（目标域名仍为
spark.changyan.com）； - 代理转发：Captive 监听 443 端口，终止 TLS 加密后将请求转至本地 9001 端口服务；
- 响应返回：9001 端口服务的响应经 Captive 加密后返回平板。
整个过程中，学生设备只需连接热点、输入域名，访问链路自动建立。MDM 管控的 40 网段被彻底绕过。
系统架构
服务组件
| 服务 | 端口 | 协议 | 功能 |
|---|---|---|---|
| DNS Server | 53 | UDP | 拦截特定域名的 DNS 查询，返回热点 IP |
| Reverse Proxy | 443 | TCP | 终止 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 端口，处理流程如下：
- TLS 终结：使用本地生成的自签名证书终止 TLS 加密连接；
- 协议降级：将解密后的 HTTP 请求转发至
localhost:9001； - WebSocket 透传：识别
Upgrade: websocket请求头，建立 WebSocket 代理隧道，支持实时互动应用； - 响应回传：9001 端口的响应经 Captive 重新加密后返回学生平板。
关键点：spark.changyan.com 在此方案中仅作为入口域名标识，实际请求被反向代理到本地 9001 端口。学生平板看到的域名保持不变，但实际通信对象是超脑本地服务。
核心实现
证书生成
由于需要处理 HTTPS 流量，必须为拦截域名生成自签名证书。Windows 系统下通过 PowerShell（管理员权限）执行：
New-SelfSignedCertificate -DnsName "spark.changyan.com","ai.changyan.com" -CertStoreLocation "Cert:\LocalMachine\My" -NotAfter (Get-Date).AddYears(5)学生平板首次访问时需手动接受证书警告。这是本方案唯一的客户端交互成本。
服务启动
以管理员身份执行启动脚本：
start-hotspot-redirect.bat管理员权限系 DNS 服务绑定 53 端口所必需——Windows 将 1024 以下端口视为系统保留端口，非管理员进程无权绑定。
功能特性
| 特性 | 说明 |
|---|---|
| 零客户端配置 | 学生平板无需安装软件或修改网络设置 |
| 协议全覆盖 | 支持 HTTPS 与 WebSocket，适配现代 Web 应用 |
| 开机自启 | 通过 Windows 计划任务实现系统启动时自动运行 |
| 进程守护 | 内置看门狗机制，服务崩溃后自动恢复 |
| 热点监控 | 自动检测热点状态，断线后触发服务重启 |
| 静默运行 | 所有服务后台运行，不干扰超脑正常教学功能 |
部署步骤
环境要求
- 硬件：讯飞超脑（Windows 10 / 11 64 位系统）
- 运行环境：Node.js >= 18.0.0
- 权限：管理员权限
安装与启动
git clone https://github.com/ClassIntra/captive.git
cd captive
npm install完成证书生成后，以管理员身份执行：
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 策略的直接对抗，仅通过协议层的重定向完成流量导入。整个方案对学生完全透明，对超脑的正常教学功能无任何干扰，是一种低成本、高可靠的技术替代路径。
发表回复