Tailscale 开启后邮箱离线：一次 Split DNS 与 DNS 重绑定保护排障

最近遇到一个很有迷惑性的网络问题：Mac 上只要开启 Tailscale，系统邮件里的 Exchange 账户就会离线；关闭 Tailscale DNS 后，邮箱恢复，但 MagicDNS 设备名又无法解析。偶尔把 Tailscale DNS 关掉再打开，两边还能同时正常一阵。

最后确认，这不是 Tailscale 与 Exchange 直接冲突，而是下面几层状态叠在了一起：

1. 邮箱域名使用 Split DNS，校内 DNS 返回内网地址，公共 DNS 返回公网地址。
2. OpenWrt 的 DNS 重绑定保护拦截了校内 DNS 返回的私网地址。
3. Tailscale 开启 DNS 接管后，经由本地路由器查询，拿不到完整的邮箱解析结果。
4. macOS DNS resolver 和缓存让故障呈现出“关开一次又好了”的随机感。
5. 公网地址在校内发生 NAT 回环，访问落到了出口设备，进一步制造了证书问题。

本文记录这次排障过程。文中的域名、IP、设备名和证书信息均已替换为示例值。

故障现象

网络中同时有两类解析需求：

• Tailscale 的 MagicDNS，用来解析 Tailnet 内的设备名；
• 单位内部邮箱域名，需要通过内部 DNS 解析到内网 Exchange。

关闭 Tailscale DNS 时，邮箱可以使用，但 MagicDNS 失效；开启后，MagicDNS 正常，邮箱却提示无法连接服务器。

更反直觉的是，切换一次 Tailscale DNS 状态后，邮箱可能短暂恢复。这很容易让人把问题归因于 Tailscale 客户端不稳定。

第一层检查：先分清路由问题和 DNS 问题

排查这类故障时，不要只看 Mail 的“离线”提示。应该分别检查：

# 查看 Tailscale 当前状态
tailscale status

# 查看 macOS 的 DNS resolver
scutil --dns

# 使用系统解析接口查询
dscacheutil -q host -a name mail.corp.example

# 直接询问本地路由器
dig @192.168.1.1 mail.corp.example

# 直接询问公共 DNS
dig @1.1.1.1 mail.corp.example

# 直接询问 Tailscale DNS 转发器
dig @100.100.100.100 mail.corp.example

当时得到的结果可以概括为：

内部 DNS：mail.corp.example -> 10.0.1.20
公共 DNS：mail.corp.example -> 203.0.113.10
本地路由器：返回不完整结果，或标记为 blocked

这说明网络链路本身未必有问题，异常集中在 DNS 路径。

这里还有一个容易忽略的点：dig 的结果不一定等于 macOS 应用最终使用的结果。Mail 通常通过系统 resolver 查询，而不是直接调用某个 DNS 服务器。因此，dig 能查到地址、Mail 仍然离线并不矛盾。

第二层检查：识别 Split DNS

同一个域名在内外网返回不同地址，就是常见的 Split DNS：

校内：
mail.corp.example -> 10.0.1.20

公网：
mail.corp.example -> 203.0.113.10

这种设计本身很正常。内网客户端应该连接私网 Exchange，校外客户端则通过公网入口访问。

最初为了绕过解析失败，我给 Mac 设置了公共 DNS。这样确实能得到公网地址，却引出了新问题：Mac 身处内网，通过公网 IP 访问邮件服务时，流量触发了 NAT 回环，最终落到了出口防火墙或错误的反向代理。

所以“公共 DNS 能解析”只能证明记录存在，不能证明这个结果适合当前网络。

证书警告是结果，不一定是根因

切到公网解析后，Mail 弹出了自签名证书警告。进一步检查：

openssl s_client \
  -connect 203.0.113.10:443 \
  -servername mail.corp.example </dev/null

公网路径返回的证书不包含邮箱域名，而内网地址返回的是有效的通配符证书。访问 Exchange Web Services 时，两条路径的响应也不同：

curl -vkI https://mail.corp.example/EWS/Exchange.asmx

对真实 Exchange 来说，未携带凭据时返回 401 Unauthorized 往往是正常现象：服务已经可达，只是在等待认证。若返回出口设备的普通 400、错误证书或完全不同的页面，就应先检查流量落点。

这里不应该急着永久信任自签名证书。证书警告是在提醒客户端“你连接的可能不是预期服务器”。强行信任只能隐藏警告，无法修正错误的 DNS、NAT 或反向代理。

根因：DNS 重绑定保护拦截了合法的私网结果

路由器启用了 dnsmasq 的 DNS 重绑定保护。它会阻止公共或上游域名解析到 RFC 1918 私网地址，用来抵御 DNS rebinding 攻击。

在这个网络中，上游内部 DNS 合法地返回：

mail.corp.example -> 10.0.1.20

路由器却把这个结果当成可疑响应拦截了。Tailscale 开启 DNS 接管后，系统查询经过 Tailscale DNS 转发器和本地上游，最终也继承了这个被拦截的结果。

至于“关开 Tailscale DNS 后短暂恢复”，原因是切换动作会重新注册 macOS resolver，并影响缓存与解析优先级。只要缓存里还留有正确的内网地址，邮箱就能暂时连接；缓存失效后，故障会再次出现。

最小修复：只对白名单域名允许私网解析

长期修复方式是在 OpenWrt 中保留全局 DNS 重绑定保护，同时只为可信的内部域名增加例外。

先备份配置：

cp /etc/config/dhcp /etc/config/dhcp.backup

然后增加白名单并重启 dnsmasq：

uci add_list dhcp.@dnsmasq[0].rebind_domain='/corp.example/'
uci commit dhcp
/etc/init.d/dnsmasq restart

/corp.example/ 会覆盖根域名及其子域名，例如：

corp.example
mail.corp.example
autodiscover.corp.example
*.corp.example

只应添加确实由自己或可信组织控制的域名后缀。不要关闭全局重绑定保护，也不要把过大的公共域名加入白名单。

在 LuCI 中，对应设置通常位于 DHCP/DNS 的 DNS 重绑定保护相关选项中，不同 OpenWrt 版本的页面名称可能略有差异。

修复路由器后，将 Mac 的 Wi-Fi DNS 恢复为自动：

sudo networksetup -setdnsservers Wi-Fi Empty
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Tailscale DNS 可以继续开启，MagicDNS 也无需牺牲。

端到端验证

修复后，不要只验证一次 dig。至少检查以下四层：

1. 本地路由器能否返回邮箱的正确内网地址；
2. Tailscale DNS 转发器能否得到同样结果；
3. macOS 系统 resolver 能否解析；
4. TLS 证书和 Exchange 端点是否正确。

示例命令：

dig @192.168.1.1 mail.corp.example
dig @100.100.100.100 mail.corp.example
dscacheutil -q host -a name mail.corp.example
curl -I https://mail.corp.example/EWS/Exchange.asmx

最终应看到：

• 邮箱域名解析到预期的内网地址；
• TLS 证书包含邮箱域名且验证有效；
• EWS 返回符合预期的认证响应；
• Tailnet 设备名仍能通过 MagicDNS 解析。

这次排障留下的经验

第一，VPN 开启后某个应用失效，不代表 VPN 改坏了路由。DNS 接管、分流规则和系统 resolver 更值得优先检查。

第二，在 Split DNS 环境中，改用公共 DNS 可能让现象暂时变化，也可能把流量带到完全错误的入口。诊断时要同时比较内部 DNS、公共 DNS和应用实际使用的系统解析结果。

第三，证书错误经常是“连错服务器”的证据。看到自签名证书时，先核对域名、IP、SNI 和服务响应，再决定是否涉及信任配置。

第四，缓存造成的“偶尔恢复”最容易干扰判断。每次切换 DNS 后，都要明确区分配置状态、resolver 状态和缓存状态。

第五，安全功能的例外应该尽量收窄。为一个可信域名添加 DNS 重绑定白名单，影响范围远小于关闭整个网络的重绑定保护。

最后，这次问题可以压缩成一条链路：

Split DNS 返回私网地址
        ↓
OpenWrt 重绑定保护拦截
        ↓
Tailscale DNS 转发到异常上游结果
        ↓
macOS resolver/缓存让现象时好时坏
        ↓
改用公共 DNS 又触发 NAT 回环和证书错误

真正有效的修复点在路由器的域名级白名单。底层 DNS 路径正确后，邮箱、MagicDNS 和证书验证可以同时恢复正常。