8 Commits

Author SHA1 Message Date
Jordan Whited
0841477743
net/udprelay{/endpoint}, all: move ServerEndpoint to independent pkg (#15934)
ServerEndpoint will be used within magicsock and potentially elsewhere,
which should be possible without needing to import the server
implementation itself.

Updates tailscale/corp#27502

Signed-off-by: Jordan Whited <jordan@tailscale.com>
2025-05-09 11:29:36 -07:00
Jordan Whited
7e2630235f
feature/relayserver: consider relay:server node attribute for enablement (#15901)
Updates tailscale/corp#27502

Signed-off-by: Jordan Whited <jordan@tailscale.com>
2025-05-07 09:15:33 -07:00
Brad Fitzpatrick
068d5ab655 feature/taildrop: move rest of Taildrop out of LocalBackend
Updates #12614

Change-Id: If451dec1d796f6a4216fe485975c87f0c62a53e5
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
Co-authored-by: Nick Khyl <nickk@tailscale.com>
2025-05-06 20:41:27 -07:00
Brad Fitzpatrick
3bc10ea585 ipn/ipnext: remove some interface indirection to add hooks
Now that 25c4dc5fd70 removed unregistering hooks and made them into
slices, just expose the slices and remove the setter funcs.

This removes boilerplate ceremony around adding new hooks.

This does export the hooks and make them mutable at runtime in theory,
but that'd be a data race. If we really wanted to lock it down in the
future we could make the feature.Hooks slice type be an opaque struct
with an All() iterator and a "frozen" bool and we could freeze all the
hooks after init. But that doesn't seem worth it.

This means that hook registration is also now all in one place, rather
than being mixed into ProfilesService vs ipnext.Host vs FooService vs
BarService. I view that as a feature. When we have a ton of hooks and
the list is long, then we can rearrange the fields in the Hooks struct
as needed, or make sub-structs, or big comments.

Updates #12614

Change-Id: I05ce5baa45a61e79c04591c2043c05f3288d8587
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
2025-04-25 09:03:39 -07:00
Brad Fitzpatrick
3d8533b5d0 ipn/{ipnext,ipnlocal}: add a SafeBackend interface
Updates #12614

Change-Id: I197e673666e86ea74c19e3935ed71aec269b6c94
Co-authored-by: Nick Khyl <nickk@tailscale.com>
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
2025-04-24 14:48:58 -07:00
Jordan Whited
c28fda864a
feature/relayserver: use PeerAPIHandler.Logf() (#15765)
This was recently added, use it to be consistent.

Updates tailscale/corp#27502

Signed-off-by: Jordan Whited <jordan@tailscale.com>
2025-04-22 10:53:58 -07:00
Jordan Whited
92027d7ae0
feature/relayserver: wire up profile/prefs changes (#15714)
The relay server is still permanently disabled until node attribute
changes are wired up in a future commit.

Updates tailscale/corp#27502

Signed-off-by: Jordan Whited <jordan@tailscale.com>
2025-04-17 09:24:11 -07:00
Jordan Whited
37f5fd2ec1
feature/{condregister,relayserver}: implement the skeleton for the relayserver feature (#15699)
This feature is "registered" as an ipnlocal.Extension, and
conditionally linked depending on GOOS and ts_omit_relayserver build
tag.

The feature is not linked on iOS in attempt to limit the impact to
binary size and resulting effect of pushing up against NetworkExtension
limits. Eventually we will want to support the relay server on iOS,
specifically on the Apple TV. Apple TVs are well-fitted to act as
underlay relay servers as they are effectively always-on servers.

This skeleton begins to tie a PeerAPI endpoint to a net/udprelay.Server.
The PeerAPI endpoint is currently no-op as
extension.shouldRunRelayServer() always returns false. Follow-up commits
will implement extension.shouldRunRelayServer().

Updates tailscale/corp#27502

Signed-off-by: Jordan Whited <jordan@tailscale.com>
2025-04-16 09:50:48 -07:00