Tailscale Architecture

Tailscale provides device identity, key distribution, access policies, address and DNS management, and the ability to automatically find available transport paths on top of WireGuard. The most direct way to understand it is to trace "a laptop accessing a company server's HTTPS service": first determine who the other party is and whether the connection is allowed, then decide how the encrypted packets reach their destination, and finally handle application authentication and business operations.

Control Plane and Data Plane

The coordination service associates login identities, node public keys, and network configurations, distributing the necessary information to clients. Normal forwarding of business packets does not require asking the coordination service for every packet; clients perform encryption, routing, and filtering based on the state they have obtained. Centralized coordination and peer-to-peer communication are not contradictory.

There are three types of data transmission paths: direct UDP between nodes, DERP relays, and Peer Relay within the tailnet. They can all carry WireGuard ciphertext between nodes, so the statement "user data does not pass through the coordination service" holds true. However, it cannot be further written as "user data will never pass through any central server". Connection Types

Mesh indicates that nodes can establish overlay network connections with each other according to policy; it does not require all devices to maintain all pairwise active sessions continuously upon boot. With 100 devices, there are 4,950 potential pairs; if only each client accesses two servers, the actual active relationships are determined by business needs. Public key distribution, path discovery, and business traffic are not the same kind of overhead.

Identity: Login Credentials Do Not Equal Tunnel Private Keys

When joining the network, devices generate keys locally; users log in via an identity provider or use an auth key for non-interactive registration. The control plane associates identity with devices and node public keys, then distributes information according to configuration. Node private keys remain at the endpoint and should not be sent to other peers or management servers. Tailscale Identity

Servers with tags participate in policies under their tag identity. It is not accurate to simply think that tagging a server is just adding a display note to a username. Tag granting authority itself must be managed; otherwise, if a device can be tagged with high privileges, it may change the resources it can access. Identity and Tags

End-to-end encryption still relies on "the public key obtained indeed belongs to the node that should be trusted." Tailnet Lock adds the condition that node public key acceptance must be signed by a trusted node, reducing the risk of the control plane arbitrarily inserting nodes; it does not solve problems such as compromised endpoints, excessive application permissions, or all available network paths being blocked. Tailnet Lock Whitepaper

Path Establishment: Available Paths First, Then Continuously Strive for Direct Connection

The common establishment process is to first obtain a usable relay channel via DERP, while exchanging discovery information and probing candidate addresses; once the direct connection is successful, it switches to direct UDP. If the direct connection cannot be established, capable clients can use available Peer Relay; otherwise, they continue to use DERP. Here, it is important to distinguish between "expected path priority" and "the path the first packet actually takes"; relays should not be written as the last step appearing only after all probing is completely finished. Connection Establishment Timing

NAT traversal requires satisfying both address mapping and ingress filtering conditions. STUN helps observe external mappings but does not create arbitrary open ingress for the local machine; probing from both ends can prompt the gateway to establish state allowing return traffic, but complex NAT, multi-layer gateways, and UDP restrictions may still cause direct connections to fail. Help from port mapping protocols does not mean the device has obtained a public IP unconstrained by firewalls. Basic mechanisms can be found in Ports and NAT.

DERP carries not only encrypted business packets but also DISCO discovery messages; therefore, "accessing DERP" itself does not prove that all current business traffic goes through the relay. Clients save the DERP map and select the appropriate relay region; regional distance and link conditions affect actual performance. DERP Servers

Peer Relay is a device configured as a relay within the tailnet. It requires a compatible client version, reachable relay UDP ports, and corresponding usage permissions. A single ordinary node located on the public network will not automatically cause all peers to treat it as a relay. Peer Relays

How to Estimate Relay Latency

Assume the direct one-way propagation from A to B is 20 ms. When going via R, A→R is 15 ms and R→B is 35 ms. Assuming symmetric return and ignoring queuing: the direct RTT is 40 ms, and the relay RTT is 100 ms. This is a teaching budget for given paths, not a fixed performance metric for DERP or Peer Relay. Real throughput is also affected by packet loss, congestion, CPU, bandwidth, and outer transport layers.

nodes = 100
assert nodes * (nodes - 1) // 2 == 4950
paths_ms = {'direct': [20], 'relay': [15, 35]}
rtt_ms = {name: 2 * sum(hops) for name, hops in paths_ms.items()}
assert rtt_ms == {'direct': 40, 'relay': 100}
# Three serial request round-trips; does not include handshake, computation, queuing, or transferring large objects.
assert 3 * (rtt_ms['relay'] - rtt_ms['direct']) == 180
print('Potential connection count and given path delay budget passed')

Authorization: Understand Network Connectivity and Business Permissions Separately

Current Tailscale documentation describes network-layer and application-layer capabilities using grants, while ACLs are still supported. Network-layer authorization can express "the engineering group can connect to TCP 443 on devices with the web tag"; it does not automatically make that user an administrator of the Web application. Grants, ACL

The following is an independent minimal policy example; usernames must be replaced with actual tailnet members; assume the destination device has legally obtained tag:web. When appending to an existing policy, other broad allow rules will still take effect; this single rule should not be understood as overriding or revoking existing permissions.

{
  "groups": {"group:engineering": ["alice@example.com"]},
  "tagOwners": {"tag:web": ["autogroup:admin"]},
  "grants": [
    {
      "src": ["group:engineering"],
      "dst": ["tag:web"],
      "ip": ["tcp:443"]
    }
  ]
}

This example allows the matching subject to initiate specified connections; return traffic is handled according to already allowed connections. It does not authorize the server to arbitrarily create new connections to the client, nor does it grant TCP 22. tagOwners manages who can assign tags, not who is allowed to connect to these devices. Grants Syntax

Application-layer app capabilities require corresponding application integration recognition; any traditional web service will not automatically implement that business permission just because a capability name appears in the policy file.

Addresses, MagicDNS, and Routing Are Three Different Things

A device's Tailscale address is an address within the overlay network, not its current public IP address on the Wi-Fi exit. When changing networks, the outer endpoint can change; the application continues to use the same node name or overlay address, reducing dependency on the underlying location, but it is still subject to node registration and address lifecycle constraints.

MagicDNS generates names for tailnet devices, allowing users to access them using device names. Name resolution answers "what is the target address," routing answers "which interface or gateway to hand it to," and access policies answer "whether it is allowed." After adding traditional subnets to the tailnet, their existing internal domain names are not necessarily automatically registered by MagicDNS; usually, internal DNS and split DNS configuration are also required. MagicDNS, Subnet Routers

Subnet Routers, Exit Nodes, and Relays: See Who Terminates WireGuard

When accessing traditional servers, the subnet router resolves the inner IP packet and then sends it into the target network. If the application uses HTTPS, application-layer TLS can continue to protect the connection to the server; if sending plain HTTP, the latter half will not be automatically encrypted just because the first half had WireGuard.

Linux kernel routing and userspace netstack routing describe how to forward after decryption. The former forwards inner packets by the kernel; the latter handles connections in userspace. One cannot infer that Tailscale necessarily hands WireGuard encryption/decryption to wireguard.ko just because it is in "kernel mode". Kernel vs. netstack

Subnet accessibility usually requires satisfying routing publication and approval, client adoption of corresponding routes, policy allowance, and forwarding/return path establishment. Default SNAT makes the traditional server see the router's address, simplifying the return path; after disabling SNAT, the target network must know how to return to the original source. Preserving source IP and having no-config return routes are not two effects that can be obtained for free simultaneously. Subnet SNAT

Coordination Service Offline: Different Fates for Existing Communications and Management Changes

Clients cache keys and filtering rules, so communication between existing nodes may continue when the control plane is unreachable. It is not permanently autonomous: key expiration, endpoint changes, insufficient cache, or all relays being unreachable may affect connections; new device onboarding, key refreshing, new policy propagation, and revocation cannot be completed through normal processes. Coordination Server Down

This also explains an easily overlooked phenomenon: when the control plane is interrupted, old business continuing to run is an availability advantage, but when administrators want to tighten access immediately, old policies still being executed becomes a change propagation problem. Failure handling must observe both connectivity and the freshness of policies.

When the Control Plane Disconnects, Which Operation Fails First?

Maintaining valid cache and direct connection, only disconnecting the coordination service, the blue business path still exists; but control refresh is already unavailable. Continue to remove the direct connection to observe if the relay can still carry traffic; only when valid state or all paths are lost does it touch the data plane premise here.

Locate Based on Evidence, Not Just Seeing "relay" and Changing Configuration

The following commands are for manual diagnostics; ping and netcheck will initiate network probes.

tailscale status
tailscale ping <peer-name>
tailscale netcheck

The direct, relay, and peer-relay descriptions in status describe the currently observed paths, which can change over time. The default tailscale ping is used for Tailscale layer discovery/connectivity checks, and is not the same test as ordinary ICMP or accessing business TCP ports; one success does not prove HTTPS certificate validity or API authorization correctness. Ping Types

To troubleshoot a failed access, you can sequentially record: the address resolved by name, client routing and node status, actual transmission path, target port reachability, and TLS/application errors. If only large responses fail, continue to check MTU and packet loss; if relay works but direct does not, observe UDP reachability and NAT conditions; if an HTTP 403 is received, return to application authentication and authorization evidence, rather than repeatedly adjusting penetration ports.