QWRT/OpenWrt 接入北工大校园网后无法打开认证页：一次 DNS Rebind 问题排查记录
最近拿到一台刷了 QWRT 的路由器，想把北京工业大学宿舍里的有线校园网直接接到路由器 WAN 口，让路由器完成校园网接入，然后下面的电脑、手机都通过路由器上网。
一开始看起来一切正常。QWRT 的 WAN 使用 DHCP 客户端后，可以正常拿到学校分配的地址，例如 172.21.13.x/24，默认网关是 172.21.13.254，DNS 也能正常获取到 172.21.0.21 和 172.21.201.22。从这些信息来看，网线、WAN 口、DHCP、网关都没有问题。
但实际使用时却出现了一个很奇怪的现象：路由器已经拿到了校园网地址，却打不开 lgn.bjut.edu.cn 登录页面，my.bjut.edu.cn 之类的校内服务也无法访问。电脑直接插宿舍网口则完全正常。
最初怀疑过很多方向，包括校园网是否限制路由器、MAC 地址绑定、DHCP Client ID、IPv6、校园网认证状态，甚至怀疑 QWRT 内部是否运行了 Clash、Mihomo 之类的透明代理。但后面的测试证明，这些都不是根因。
真正的突破口出现在 DNS。
在 QWRT 上直接指定北工大的 DNS 查询：
nslookup my.bjut.edu.cn 172.21.0.21能够得到完整结果：
my.bjut.edu.cn canonical name = faw235v4.bjut.edu.cn
Name: faw235v4.bjut.edu.cn
Address: 172.21.96.235查询校园网认证地址也正常：
nslookup lgn.bjut.edu.cn 172.21.0.21可以解析到：
172.30.201.10
172.30.201.2这说明学校的 DNS、本机到校园 DNS 的网络连接，以及这些校内域名本身都是正常的。
问题出现在通过 QWRT 自己的 DNS 查询时：
nslookup my.bjut.edu.cn 127.0.0.1返回结果很有意思。它能够得到：
my.bjut.edu.cn canonical name = faw235v4.bjut.edu.cn但后面的 172.21.96.235 消失了，最终提示：
No answer也就是说，QWRT 的 dnsmasq 已经从学校 DNS 收到了 CNAME，但最终的 A 记录却被过滤掉了。
继续检查 QWRT 的 dnsmasq 配置：
uci show dhcp.@dnsmasq[0]发现其中有：
rebind_protection='1'到这里原因基本明确了。
OpenWrt/QWRT 默认开启 DNS Rebind Protection，也就是 DNS 重绑定保护。这是一项正常的安全机制：如果一个普通域名突然解析到 192.168.x.x、10.x.x.x、172.16.x.x 这样的私有地址，dnsmasq 会认为这个响应可能是在尝试进行 DNS Rebinding 攻击，因此把结果过滤掉。
问题在于，北京工业大学的校园网本身就大量使用私有地址。
例如：
my.bjut.edu.cn
→ faw235v4.bjut.edu.cn
→ 172.21.96.235而校园网登录地址：
lgn.bjut.edu.cn
→ 172.30.201.10
→ 172.30.201.2这些 172.21.x.x、172.30.x.x 地址都属于 172.16.0.0/12 私有地址范围。
对于北工大校园网来说，这是正常的内部 DNS 设计；但对于 OpenWrt 的 dnsmasq 来说，却长得非常像 DNS Rebind，于是被默认的安全策略过滤掉了。
这也解释了为什么 QWRT 明明能够拿到正确的校园网 DNS，却依然提示域名解析失败。DNS 请求实际上已经发到了学校服务器，学校也返回了正确结果，只是在返回过程中被路由器自己拦掉了。
最终解决办法并不是关闭 DNS Rebind Protection，而是给北工大的域名加白名单。
在 QWRT 的 LuCI 管理页面中进入：
网络 → DHCP/DNS找到 DNS 重绑定保护相关设置。保持“DNS 重绑定保护”开启，然后在“域名白名单”或者 Rebind Domain Whitelist 中加入：
bjut.edu.cn保存并应用即可。
对应的命令行配置是：
uci add_list dhcp.@dnsmasq[0].rebind_domain='/bjut.edu.cn/'
uci commit dhcp
/etc/init.d/dnsmasq restart这样做的含义很简单：DNS Rebind Protection 继续正常工作，但是对于 bjut.edu.cn 以及其子域名，允许 DNS 返回校园网中的私有 IP。
配置完成后，再执行：
nslookup my.bjut.edu.cn 127.0.0.1就可以正常得到：
my.bjut.edu.cn canonical name = faw235v4.bjut.edu.cn
Name: faw235v4.bjut.edu.cn
Address: 172.21.96.235lgn.bjut.edu.cn 也可以正常解析到 172.30.201.x，校园网内部门户和认证页面随即恢复正常。
整个问题其实和路由器是否能接校园网没有关系。QWRT 从一开始就已经正常接入了北工大的网络：DHCP 正常，网关正常，校园 DNS 也正常。真正的问题只是 OpenWrt 默认的安全策略和学校内部 DNS 的设计发生了冲突。
这个问题还有一个很典型的特征：直接指定校园 DNS 查询时正常，通过 OpenWrt 自己的 127.0.0.1 或 LAN DNS 查询时却只得到 CNAME、最终 A 记录消失。如果在其他高校、公司内网或实验室网络里遇到类似情况，尤其是内部域名会解析到 RFC1918 私网地址时，可以优先检查 dnsmasq 的 DNS Rebind Protection。
另外，这也能解释为什么在电脑上使用 Clash、Mihomo、Fake-IP、DoH 或 TUN 模式时，校园网认证页有时打不开。北工大的部分校园网服务依赖学校内部 DNS，如果 DNS 被代理软件接管，域名就可能无法得到正确的内网地址。对于这类网络环境，校园网认证域名和学校 DNS 最好始终走直连。
最终稳定配置其实很简单：WAN 继续使用 DHCP 自动获取地址、网关和 DNS，dnsmasq 正常作为路由器的 DNS 转发服务，DNS Rebind Protection 保持开启，只把 bjut.edu.cn 加入可信白名单即可。这样既保留了 OpenWrt 原本的安全保护，又能够正常使用北工大的校园网内部 DNS。