Digital Garden

The Naked Swimmer of the fake-IP Strait: The DialPlan of tailscaled, the Disabled SNI Sniffing, and Two Postures of Crossing a TUN

2026-11-07 · ~4 min read · Tailscale · fake-IP · mihomo · routing conflict

After the reboot, the Tailscale login button became an ornament — pressed with no response, no error and no authentication popup. The complete causal chain of this case is the story of a fish swimming naked through the fake-IP strait.

I. Three Confirmations at the Surface

The simple answers were cleared first: the Tailscale service ran but was logged out (NoState) and login requests timed out; the Ninja core inet.exe ran with 7897 listening normally and TUN in command; the direct network was healthy (UDP through, DERP Los Angeles at 150ms). One layer deeper: the DNS of every adapter had been rewritten by the Ninja TUN to 198.18.0.2 (fake-ip), and controlplane.tailscale.com resolved to 198.18.0.29 — the control traffic was force-marched into the proxy. The boot-sequence deadlock was also traced: the Ninja TUN seized DNS and routes first → the automatic login at boot timed out through the proxy → the client fell into the logged-out state, and a logged-out client does not retry by itself, so it stayed in NoState. A third contest was waiting behind: Tailscale wanting to write its MagicDNS (100.100.100.100) back onto the adapters while Ninja overwrote them with fake-ip — the two sides fighting for the same ground.

II. The Naked Swimmer: The DialPlan and the Closed Sniffing

Service restarted, the proxy environment variable written into the service, logs turned page by page — the registration requests still timed out at ten seconds. A key detail surfaced: tailscaled keeps an internal DialPlan (a bare-IP list) and preferentially dials those addresses directly, bypassing the newly set proxy path. The controlled experiment nailed the mechanism of the conflict: 192.200.0.103 of the same segment connected in one second, 192.200.0.115 stalled ten, the domain through fake-ip connected — tailscaled holds bare IPs (its bootstrap DNS as a fallback, bypassing the fake-ip domain mapping), and when bare-IP traffic enters ninja-tun, the mihomo with sniff: false sees no domain and routes blindly by IP rules, landing exactly on the path that hangs. This is not a fault of Tailscale or of Ninja alone; it is the routing conflict of the two superimposed.

III. The Road-Lore of the Repair

The immediate recovery walked the path of removing armor before crossing: drop TUN → restore the master normal DNS → restart Tailscale → with the machine bare, registration connected at once, and one click in the browser finished the authorization. For coexistence, three choices: recommended, tailscale set --accept-dns=false (relinquish MagicDNS, let Ninja own DNS, connect devices by 100.x addresses — the steadiest); or add *.tailscale.com, *.ts.net and controlplane.tailscale.com to Ninja direct rules (letting Tailscale traffic bypass the proxy); or a permanent proxy configuration for the Tailscale service.

IV. The Geography of Two Postures

The geography of this case deserves its own page: the same destination, two postures of crossing the strait, utterly different fates — those carrying domains ride the fake-ip mapping and sail through (curl); those dialing bare IPs (the tailscaled DialPlan) strike the dead channel where sniffing is closed. The naive assumption of the fake-IP system is that all traffic asks for a domain first — but kernel-level daemons are precisely the naked swimmers who ask no domain and know only IPs. In a network that must coexist with a proxy, every process that refuses the domain system needs a shipping lane of its own.

Comments

← Digital Garden