Who Can Open a Shared Local Service?

A private URL still needs an access model. Suppose a developer shares a local status page with another device in their tailnet. TSLink can give that page a named tsnet node, but it does not decide all authorization on its own.

Start with the tailnet

Tailscale policy determines which devices and identities can reach the service's node. A first tslink share 3000 --name status --json may return needs_login and an authorization URL. Approving that node enrolls it in the tailnet; it does not grant every internet visitor access.

For an HTTP proxy or file service, TSLink's --allow option can further filter requests by Tailscale identity. Without --allow or a people policy, callers allowed by Tailscale policy can reach it. People grants, expiry and deny records still apply when configured. Raw TCP does not have TSLink's HTTP identity headers or --allow check; use tailnet policy and authentication in the target service.

Check the local hop and host

The tailnet leg uses Tailscale/WireGuard. Proxy/file HTTP uses Tailscale HTTPS at the service node, while the hop to a local backend may be plaintext. Each service's separate tsnet identity is network segmentation; services on the same host are not isolated as processes. A sensitive backend still needs its own appropriate authorization and host safeguards.

Public exposure is an explicit, different path: Funnel requires both --funnel and --public. TSLink's tailnet identity restriction is not a public-web authentication layer. Review the security boundary documentation before using either path for sensitive data.

Install TSLink v0.1.1. Quick Start shows the first private share and approval sequence.