Two Faults in Superposition: NinjaDesktop TUN Offline and Tailscale Boot Silence, the Dead Adapter Left by a Fixing Agent, and Four Automatic Rescue Gates

One night closed two stacked network faults — and the way they were closed was to make every rescue gate automatic.

I. Fault One: Fifty-Two Minutes of Tailscale Boot Silence

The log timeline restores it cleanly: at 00:34:49 the Tailscale service started, but WantRunning=false — Tailscale is stopped; at 00:37:29 the first login was context-canceled, and for fifty-two minutes there was not one retry; at 01:29:47 the master switched it on by hand and it recovered at once. The root is the two-piece structure of Tailscale on Windows: the service (tailscaled) and the desktop side (tailscale-ipn.exe) each mind their own half, and the desktop side had no autostart entry (absent from the Run registry) — after every boot the backend sat in Stopped until clicked.

II. Fault Two: The Dead Adapter Left by a Fixing Agent

More hidden was the second: a fixing agent disabled the ninja-tun adapter outright, while the kernel tun.enable stayed true and dns-hijack any:53 kept hijacking every DNS query — the result was only DNS dies while routing lives: ping 223.5.5.5 succeeded (routes fine) while every nslookup timed out (queries dropped into the dead adapter). What the master saw as no network was name resolution dead. Worse, the app API still reported tun_enabled=true, lying about the state — the gap between appearance and reality is exactly what makes such faults vicious.

III. Four Automatic Rescue Gates

The fixes landed as four gates, each field-tested: ① a Run key for the Tailscale desktop autostart (raised at boot; the backend no longer sits in Stopped); ② a new task TailscaleBootFix (logon plus 90 seconds — if the backend is still stuck, tailscale up rescues it); ③ tunfix.ps1 gained an adapter-not-Up check — whoever disables the TUN adapter gets it replayed within a minute; ④ netfix.ps1 rewritten to trust only the real adapter state — no longer fooled by the app API tun_enabled=true. The acceptance was all live runs: manual Disable-NetAdapter on ninja-tun killed DNS at once; run tunfix and the adapter came Up, DNS recovered, baidu 200; manual tailscale down left the backend Stopped; run tsfix and it auto-upped to Running with a direct line to the Mac. Terminal state: baidu 200 / google 200, Tailscale via 192.168.5.21:41641 in 2ms, TUN Up, sshd Running, and four tasks all Ready.

IV. The Expectation of the Next Reboot

A normal reboot should now recover fully automatically; the worst case has backstops too — a TUN route exclusion is patched within six seconds (event-triggered), a stuck Tailscale is rescued within ninety. The true product of the night was not fixing two faults but replacing wait-for-the-master-to-notice with faults queuing themselves for repair by stopwatch: every gate tested, every gate automatic, every gate logging.