daemon: recover at once when this node's IP address changes

[TeoSlayer]

Pull Request

Summary

When a running node's IP address changed, nothing in the daemon noticed. Recovery waited for other nodes' timeouts: measured on v1.14.0-rc.1, messages failed in both directions for 23–32s, an open stream stalled ~40s, and the registry held the old address for minutes. This makes the node detect the change and announce itself.

Changes

• Detection. Once a second the daemon asks the kernel which source address it would use toward the beacon (a connected UDP socket; nothing is sent). That changes exactly when the daemon's own path changes and ignores unrelated interfaces (Docker bridges, VPNs that do not take the route, link-local addresses). No route reads as "offline" and triggers nothing; the same address coming back triggers nothing.
• Recovery, in latency order: re-register with the beacon; send one authenticated probe to every tunnel peer so each learns the new source address at once (repeated at +1s and +3s only for peers that have not answered); then a fresh registry connection — the pooled ones are bound to the old address, which is why the moved node's own sends failed for ~30s — and a re-registration.
• NAT. A NATed node cannot see its public address change locally. The beacon's discover reply, previously discarded, is now parsed; a changed observed IP runs the same recovery (bounded by the 60s beacon keepalive). Port-only changes are ignored.
• Rate limit. Recoveries are at least 10s apart, doubling to a 2-minute cap and resetting after 10 quiet minutes, so a flapping interface costs a handful of re-registrations and then one every two minutes.
• The beacon+registry re-registration that soft recovery and resume each had inline is now one routine, reestablishTransport, shared with the watcher.
• New event tunnel.addr_changed.

Peers need no update: the measurements below used a patched moved node with unpatched peers.

Measured (three nodes and a registry on one Docker network, one node moved to a new address)

	Before	After
Peer → moved node	first success +32s	under 1s, no failures
Moved node → peer	failures until ~+30s	no failures
Node with no tunnel, 10s after the move	30s timeout (registry had the old address)	0.2s, direct
Subscription on the moved node, 1 publish/s	2 lost, first delivery +37s	60/60, gap ~2s
Registry learns the new address	2m46s	milliseconds after detection

Detection fired 0.16–0.8s after the address appeared. Three disconnect/reconnect cycles on the same address triggered nothing; eight moves in 26s produced two recoveries.

Limits

• The NAT path has unit tests only; it was not run against a real NAT. A source-port-only change and compat (WSS) mode are untested; the watcher is off in compat mode.
• Only the route toward the beacon is watched; a change affecting only peers reached through another interface is not detected.
• Several real moves within ten minutes raise the gap, so a fourth or fifth can wait up to two minutes and behaves as before meanwhile.
• A recovery re-reports every trust pair: roughly 3 + N registry calls for N trusted peers.
• The integration harness runs on loopback and cannot change an address; the integration test points a peer's entry at a dead address and checks the recovery corrects it. The move itself was reproduced in Docker.
• An exported Daemon.RecoverFromAddrChange() exists for that test and is not rate-limited.

Test Plan

• go build ./..., go vet ./..., unit suite with GOWORK=off
• pkg/daemon/zz_addrwatch_test.go, tests/zz_addr_change_recovery_test.go
• Full go test -parallel 4 -count=1 ./tests/: one failure, TestManualSnapshotTrigger, which binds fixed port 127.0.0.1:18080 held by another process on the test machine; it fails the same way on main there

Checklist

• New code includes the SPDX license header
• go.mod / go.sum unchanged
• CHANGELOG updated

🤖 Generated with Claude Code