Mark the Linux TUN device unmanaged for NetworkManager so its connectivity probe does not enter the cluster

Problem

On Linux desktops running NetworkManager, the root daemon's TUN device (tel0) is adopted by NetworkManager the moment it appears. NetworkManager treats it as an externally configured connection and runs its device activation steps on it, including the ip-check connectivity probe: an HTTP request to the configured check URL (http://fedoraproject.org/static/hotspot.txt on Fedora) with the socket bound to the new device.

Because the socket is bound to tel0, the request leaves through the tunnel regardless of the routing table, with tel0's own address as source. The traffic-manager then dials the check host from inside the cluster. Every telepresence connect therefore sends two HTTP requests for an internet host into the cluster that nobody asked for. On a cluster without egress they fail; on one with egress they reach the host.

Observed on Fedora 44 with Telepresence v2.32.0 pre-release:

14:17:01.4254 INFO  rootd/server-grpc: Creating routing table with index 775 and priority 5209
14:17:01.4595 ERROR rootd/server-grpc: !! TUN⇄CLI TCP 246.246.242.106:49046 -> 35.90.167.38:80, Send failed: stream 0 canceled by remote with error code 0
14:17:01.4596 ERROR rootd/server-grpc: !! TUN⇄CLI TCP 246.246.242.106:49056 -> 35.90.167.38:80, Send failed: stream 4 canceled by remote with error code 0

35.90.167.38 is one of fedoraproject.org's addresses and 246.246.242.106 is tel0's address. The NetworkManager journal shows the device adopted at 14:17:01.4286 and reaching ip-check at 14:17:01.4470. Routing table 775 held only the cluster subnets, so no route explains the packets; only a device-bound socket does. The error lines themselves are a separate logging issue, fixed on the setup branch; this issue is about the probe reaching the cluster at all.

The probe fires once per device appearance. NetworkManager does not repeat it on tel0 because the device carries no default route, and it left the systemd-resolved configuration Telepresence wrote for the link untouched.

Proposal

Tell NetworkManager not to manage the device when the Linux VIF is created, so that neither the connectivity probe nor any other activation step, dispatcher script or DNS change applies to it. Two mechanisms exist:

• Runtime, over D-Bus. Set the device's Managed property to false on org.freedesktop.NetworkManager before the interface is configured and brought up. Nothing is written to disk and it lasts for the life of the device. github.com/godbus/dbus/v5 is already a dependency. When NetworkManager is not on the bus (containers, WSL, systemd-networkd hosts) the call fails and setup continues as today.
• Persistent, via a file. A [device] section with managed=0 in /etc/NetworkManager/conf.d/ or a udev rule setting NM_UNMANAGED=1. Applies before the device exists so there is no race, but it edits system configuration outside Telepresence's own files and must be removed on uninstall.

The runtime variant is the recommended one; the persistent form belongs in the docs for people who want it.

Considerations

• NetworkManager adopted the device 3 ms after creation and probed 18 ms later, so the D-Bus call must happen before the device is brought up and addressed, which reorders the current VIF setup. The existing behaviour must stay correct when the call fails.
• Linux-with-NetworkManager only; nothing changes for other platforms, and a unit test cannot exercise it.
• Some users may want NetworkManager to see the device, for dispatcher scripts or monitoring, so an opt-out setting may be warranted.
• The visible payoff is small on current evidence: one stray probe per connect. The value is correctness: tel0 is a point-to-point tunnel owned by another daemon, and NetworkManager's adoption of it is a heuristic guess whose activation steps assume a real link.

Workaround

# /etc/NetworkManager/conf.d/telepresence.conf
[device-tel0]
match-device=interface-name:tel0
managed=0

followed by systemctl reload NetworkManager.