Skip to content

fix: never send local endpoints if disabled #12138

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Feb 20, 2024
Merged

Conversation

deansheather
Copy link
Member

Endpoints gathered by scanning interfaces on the local computer (i.e. local addresses like 192.168.1.x) would get sent to peers via Tailscale Disco protocol, even if the server or client forbade sending endpoints with the server/client flags. This prevents sending any endpoints when blocked by the user or admin.

Previously, we only blocked sending endpoints in the coordination protocol and we blocked STUN servers from functioning, but these local IPs could still get sent via Disco.

Closes #10791

Copy link
Member

@kylecarbs kylecarbs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible for us to write a test for this?

@deansheather
Copy link
Member Author

I can write a test but I don't think it will reliably catch issues. There's no way to force endpoints to update without calling private tailscale methods, so the only way is to sleep and make sure they never appear.

I added multiple thorough tests for the underlying (*magicsock.Conn).SetBlockEndpoints() method when I implemented it, which use hidden APIs to settle things quicker.

require.Empty(t, node.Endpoints, "conn1 got endpoints")
case node := <-nodes2:
require.Empty(t, node.Endpoints, "conn2 got endpoints")
case <-time.After(testutil.WaitShort):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

timer gets reset each time we go around the loop, so we could wait for much longer than 10 sec.

But, I don't think we add much value by waiting for 10s. There are unit tests for tailnet.Conn blocking endpoints on node updates.

What wasn't covered prior to this is endpoints discovered via disco. The status tests you have below cover that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, yeah I guess I can just remove this section then. I do still think we should wait because we can't force it to gather local endpoints, unless you know a way to test this reliably?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we have tests that demonstrate that tailnet.Conn won't send endpoint in a Node update callback when blockendpoints is set.

E.g. TestNodeUpdater_setBlockEndpoints_different

Where we got the endpoints from (local, STUN, etc) is immaterial.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the node endpoint check but I still think the delay is required unless you know of another way to force disco endpoints to be gathered and sent immediately

@deansheather deansheather merged commit 9861830 into main Feb 20, 2024
@deansheather deansheather deleted the dean/block-endpoints branch February 20, 2024 05:51
@github-actions github-actions bot locked and limited conversation to collaborators Feb 20, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

test flake: scaletest: Test_Runner/NoCleanup: peer is connected directly
3 participants