internal/tsutil: add Auto-VPN to toggle Tailscale based on Wi-Fi network

[gitzone83]

This is the Auto-VPN thing from #278, finally. Sorry it took so long to turn up.

Short version: it turns Tailscale off on Wi-Fi networks you've marked trusted and back on everywhere else — untrusted Wi-Fi, wired, no network at all, or an SSID it can't read. Off by default.

I built it to what we agreed in that thread rather than what I first proposed, so: NetworkManager only, no iwd backend, no gio.NetworkMonitor swap. If NM isn't on the bus the whole preferences group goes insensitive with a line explaining why, and the watcher just returns rather than spinning. The iwgetid fallback is gone too — you were right that it was never going to work inside the Flatpak. Settings are two GSettings keys in the existing preferences dialog.

Couple of things in #278 that are stale now: no iwgetid, and autowatcher.go came out around 400 lines rather than the ~315 I guessed, mostly the NM-availability handling and the concurrency stuff below.

You asked:

Just to be clear, this simply turns Tailscale on and off, not the exit node, right? Because that just doesn't seem that useful to me.

Yeah, on/off — same tsutil.Start()/Stop() path as the tray toggle.

The case I built it for is a laptop that moves around. At home I want the NAS and the printer on the plain LAN without going through the tunnel; on hotel or conference wifi I want it up and I don't want to have to remember. So it's peer-to-peer access being toggled, not exit node routing. I get that if you're mostly stationary this is less compelling.

An exit-node version would drop into the same machinery though — the trusted list and the watcher are unchanged, only the action differs. Say the word and I'll add it here or as a follow-up, whichever you prefer.

Mechanically it watches NetworkManager's StateChanged and PropertiesChanged, pulls the SSID off the active AP over DBus, checks it against the list. Network events get a 2s debounce so roaming doesn't thrash it, plus a 10s ticker for anything that changes without a signal. It checks actual VPN state before doing anything, so a settled state doesn't generate repeated calls. Anything it can't identify counts as untrusted and the tunnel comes up — I'd rather it be on when it shouldn't be than off when it should.

The concurrency was where the actual bugs were, so worth flagging. Settings changes, the debounce timer and the ticker can all land at once, and the original code checked its dedup state, dropped the lock, blocked on the poller, then acted — so two of them could both decide to act on the same transition. Evaluations are now serialised under their own mutex, and it's deliberately never held while taking the other one so Stop() can't wedge behind a running evaluation.

Two things fell out of that. GetIPN() hands back an unbuffered channel, so anything parked on it couldn't be released by Stop() at all — that read selects on the context now. And an evaluation already in flight would happily call back into UI state after teardown, so the context gets checked after the lock and again after Start/Stop returns.

There are tests for all three in autowatcher_test.go. I checked they actually fail against the old code rather than just passing — without the evaluation lock you get eight overlapping evaluations instead of one.

Testing was on Ubuntu 26.04.1, GTK 4.22.4 / libadwaita 1.9.1, Go 1.27, tailscaled 1.102.3. SSID detection matches what nmcli reports. Trusting the current network takes it Running -> Stopped, untrusting brings it back, and I confirmed both against tailscaled's own log rather than just the UI. I also sat there flapping trust/untrust every two or three seconds to try and provoke it: exactly one EditPrefs per action, no oscillation, and the ticker stays quiet once things settle. Empty and nil trusted lists are inert, as is a disabled watcher. build/vet/staticcheck are clean — staticcheck reports the same two pre-existing poller.go findings as master and nothing else. go test -race is clean.

One gap I should mention: I haven't actually exercised the debounce. Settings changes go through Reevaluate and skip it by design, so testing it properly needs a real network transition rather than clicking things in the UI.

For Flatpak it needs one permission in the flathub manifest, which I'll send separately if this lands:

  - --system-talk-name=org.freedesktop.NetworkManager

Without it you get the NM-unavailable path rather than anything broken.

Last thing, unrelated to this branch but relevant if you go to test it: master currently segfaults on startup against a 1.102.x daemon, which I wrote up in #290. I had that library bump applied locally while testing this; it's deliberately not in this PR.