[Compatibility] 宿主 Mac 与上游网关存在 fake-IP 命名空间冲突 / Fake-IP namespace conflict between the host Mac and upstream gateway

[YTwsy]

中文

问题概述

当宿主 Mac 的上游网关使用 fake-IP DNS，而宿主 Mac 本地同时运行 OpenSurge/mihomo TUN 时，上游返回的 fake-IP 可能被本机 TUN 接管，但对应的域名映射只存在于上游网关。

这会造成两个独立 fake-IP 命名空间之间的所有权冲突：

上游网关的 fake-IP
  → 被宿主 Mac 本地 TUN 接收
  → 但本地 mihomo 没有对应映射
     或已经把相同 IP 分配给另一个域名

两台使用默认配置的 OpenSurge 网关串联，是该问题的典型必现场景：

Mac A：上游 OpenSurge 网关
  ↓ DHCP / DNS / 默认网关
Mac B：A 的客户端，同时运行本地 OpenSurge
  ↓ DHCP / DNS / 默认网关
下游设备

这里“必现”指冲突条件必然建立；Mac B 本机最终表现为完全断网、部分网站失败、错误分流或偶尔正常，仍取决于规则、出口和 fake-IP 缓存状态。

已确认现象

实际测试已经确认：

• Mac B 接管的下游设备可以正常访问网络。
• 风险集中在 Mac B 本机，因为它仍然使用 Mac A 作为系统 DNS，但其本机流量首先进入 B 自己的 TUN。

下游设备正常符合当前数据路径：

下游设备
  → B dnsmasq
  → B mihomo DNS :1053
  → B 生成的 fake-IP
  → B TUN

fake-IP 的生产者和消费者都是 B，因此不存在跨实例映射所有权错位。

两台 OpenSurge 串联时为什么必然建立冲突

默认配置同时满足以下条件：

1. Mac A 通过 DHCP 把自己下发为默认网关和 DNS。
2. Mac B 获得并继续使用 A 作为系统 DNS。
3. B 启动 OpenSurge 后，当前流程不会把 B 的系统 DNS 改为 B 自己的 DNS。
4. A、B 都固定使用 198.18.0.1/16 作为 fake-IP 池。
5. B 发往 A 局域网地址的 DNS 请求不会可靠进入 B 的 TUN DNS 劫持路径。
6. A 返回的 fake-IP 随后会被 B 的 TUN 路由接管。

相关实现：

• internal/dhcp/template.go：DHCP 将网关地址同时下发为 DNS。
• internal/controlapi/server.go：same-WiFi DHCP 流程设置静态 IPv4 时保留此前获得的 DNS。
• internal/mihomo/config.go：所有实例固定使用 198.18.0.1/16，并启用 TUN auto-route；局域网地址被排除在 TUN 路由之外。

mihomo 官方文档也注明，macOS 无法自动劫持发往局域网地址的 DNS：

https://wiki.metacubex.one/en/config/inbound/tun/

具体数据流

以 B 本机访问 example.com 为例：

B 本机查询 example.com
  → DNS 请求到达 A
  → A 返回 198.18.0.x
  → 映射 example.com ↔ 198.18.0.x 只存在于 A
  → B 本机连接 198.18.0.x
  → B TUN 接管连接
  → B 无法可靠恢复 A 所持有的域名映射

如果 B 没有这个 fake-IP 的映射，B 只能把它当作普通 IP：

• B 的域名规则无法匹配；
• 如果走 DIRECT，流量可能再次交给 A 并“碰巧可用”；
• 如果交给远端代理，远端通常无法访问 198.18.x；
• B 的实际出口可能与预期策略不一致。

如果 B 已将相同 fake-IP 分配给另一个域名：

A: 198.18.0.7 → example.com
B: 198.18.0.7 → example.net

B 可能按错误域名执行规则或建立连接，表现为错误代理组、错误出口、TLS/SNI 校验失败，或其他协议访问错误目标。

因此，同一个 fake-IP 网段不是唯一问题；真正的问题是不同实例拥有彼此独立的映射表，却处理了对方生成的 fake-IP。

更广泛的影响范围

该问题不限定于两台 OpenSurge。上游还可能是：

• Surge 网关；
• 独立 mihomo 网关；
• 使用 fake-IP DNS 的旁路由；
• 企业 VPN、透明代理或其他会返回合成地址的上游网络。

只要宿主 Mac 使用上游 fake-IP DNS、本地 TUN 接管上游返回的地址，并且本地实例没有上游的映射表，就可能发生同类冲突。

如果上游 LAN、VPN 或实验环境本身使用 198.18.0.0/16 内的真实地址，也存在真实地址与本地合成地址之间的歧义。

198.18.0.0/15 是 IANA 分配给网络基准测试的特殊用途地址，不会正常出现在公网，但仍可能被实验网络或 VPN 使用：

https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

与 #16 的关系

该问题与 #16 都会产生“宿主 Mac 异常、下游设备正常”的现象，但根因不同：

• [Compatibility] macOS TUN-only 与第三方 DNS Network Extension 冲突 / Conflict with third-party DNS Network Extensions #16：第三方 DNS Network Extension 抢先处理宿主 Mac 的 DNS。
• 本问题：上游网关返回的 fake-IP 被本地 TUN 接管，造成跨实例映射所有权错位。

关联 Issue：

#16

---

English

Problem

A fake-IP namespace conflict can occur when the host Mac uses a fake-IP DNS service provided by its upstream gateway while also running a local OpenSurge/mihomo TUN instance.

The upstream gateway owns the domain-to-fake-IP mapping, but the returned address is intercepted by the host Mac's local TUN:

Fake-IP generated by the upstream gateway
  → intercepted by the host Mac's local TUN
  → local mihomo does not own the mapping
     or maps the same address to another domain

Two OpenSurge gateways using their default configuration form a deterministic trigger:

Mac A: upstream OpenSurge gateway
  ↓ DHCP / DNS / default gateway
Mac B: A's client and another OpenSurge gateway
  ↓ DHCP / DNS / default gateway
Downstream device

“Deterministic” means the namespace-conflict conditions are always established. Whether B experiences a complete outage, partial failures, incorrect routing, or accidental success still depends on its rules, selected egress, and mapping cache.

Confirmed observation

Actual testing confirms that devices managed by B continue to work.

Their fake-IP path remains local to B:

Downstream device
  → B dnsmasq
  → B mihomo DNS :1053
  → B fake-IP mapping
  → B TUN

The compatibility risk affects B itself because its system DNS still points to A while its local traffic is intercepted by B's own TUN.

Why chained OpenSurge gateways trigger the conflict

The default configuration satisfies all relevant conditions:

1. A advertises itself as the default gateway and DNS server through DHCP.
2. B continues using A as its system DNS.
3. Starting OpenSurge on B does not move B's system DNS to B's local DNS service.
4. Both instances use 198.18.0.1/16 as their fake-IP range.
5. DNS requests from B to A's LAN address are not reliably captured by B's TUN DNS hijack.
6. B's TUN subsequently intercepts the fake-IP returned by A.

The mapping belongs to A, while the intercepted connection is processed by B.

If B has no mapping for the address, domain rules may lose their hostname context. A raw DIRECT path may accidentally reach A and work, while sending the special-purpose address to a remote proxy will usually fail.

If B maps the same address to another domain, it may apply the wrong domain rules or connect to the wrong target.

Scope

The upstream gateway does not have to be OpenSurge. The same boundary can affect:

• Surge gateways;
• standalone mihomo gateways;
• fake-IP-enabled routers;
• VPN or transparent-proxy environments returning synthetic addresses.

A real upstream LAN or VPN using the local fake-IP range can create a related ambiguity between real and synthetic addresses.

Relationship to #16

Issue #16 concerns third-party DNS Network Extensions intercepting local DNS.

This issue concerns a different boundary: fake-IP responses generated by an upstream gateway entering another local TUN instance whose mapping table is independent.

#16