Learn Tailscale - Core Concepts & Key Architecture

#Introduction

In episode 1 you understood why Tailscale exists. Now we get into the most technically important part: how Tailscale works behind the scenes. You don't have to memorize protocol details, but understanding the architecture will save you in the troubleshooting episode (18) and when designing a production tailnet (21).

Episode 2 dissects Tailscale's main architecture: the concept of a tailnet as an encrypted mesh network, the strict separation between the control plane and the data plane, the NAT traversal mechanism with DERP relay fallback, and the core components running on every device — the tailscaled daemon, the tailscale CLI, MagicDNS, and node keys.

#Architecture Behind the Scenes

#What Is a Tailnet

A tailnet is a private virtual network connecting all devices owned by one organization. Every device that joins is called a node. All nodes are connected in a mesh network: each node has a direct tunnel to every other node, rather than going through a central hub. This means a connection between two nodes keeps working even if another node goes down.

tailscale status
tailscale ip

The output of tailscale ip shows your node's IPv4 address (100.x.x.x) and IPv6 address (fd7a:115c:a1e0::x) inside the tailnet.

#Control Plane vs Data Plane

Two concepts you must understand:

• Control plane: Tailscale's coordination server, which manages public keys, configuration, authentication, and tells every node about its peers. The control plane never carries your traffic.
• Data plane: the WireGuard connection between nodes. All actual traffic — SSH, HTTP, file transfer — flows directly between nodes, encrypted end-to-end with WireGuard.

Control plane: keys, config, authentication (coordination only)
Data plane:   encrypted traffic between nodes (WireGuard)
 
Node A <----------------------------> Node B
          direct WireGuard tunnel

The reason for this separation: the control plane can be optimized for fast coordination, while traffic security and latency depend on the direct path between nodes.

#NAT Traversal and DERP Relay

Two devices behind NAT usually can't connect to each other directly. Tailscale handles this in stages:

1. Each node sends a connection to the control plane, which shares the public address and local address (endpoint) of other nodes.
2. Nodes try NAT traversal — using hole punching techniques so two devices behind NAT can open a direct connection.
3. If that fails (symmetric NAT, strict network), traffic is routed through the DERP relay (Detour Encrypted Routing Protocol) — a relay server that forwards encrypted traffic between nodes.

tailscale ping node-server

Output like pong from node-server (100.101.102.103) via DERP(ams) means the connection is going through a relay, while via direct means a direct connection succeeded.

#Core Components on Every Device

#The tailscaled Daemon and the tailscale CLI

Every node runs two programs:

• tailscaled: the background daemon that manages WireGuard, state, and the connection to the control plane.
• tailscale: the CLI for interacting with the daemon, such as tailscale up, status, and set.

systemctl status tailscaled --no-pager
tailscale version

On Linux, this daemon is managed by systemd and stores its state in /var/lib/tailscale/tailscaled.state.

#MagicDNS

MagicDNS is a built-in DNS service that gives every node a hostname of the form <name>.<tailnet-name>.ts.net. You don't need to remember 100.x.x.x IPs — just use the hostname:

ssh devnull@node-server.tailnet-name.ts.net

Resolution is automatic: every node in the tailnet can reach every other by name. We cover the full details in episodes 5 and 10.

#Node Keys and Identity

Every node has a node key (public and private) generated automatically the first time you run tailscale up. This node key is what gets authenticated to the control plane and is used by WireGuard for encryption. There's also node key expiry: node keys have a validity period (180 days by default) so unused devices don't accumulate forever.

#Key Concepts at the Tailnet Level

#Tags, ACLs, and Policies

Inside the tailnet, you can assign tags to nodes (for example tag:server, tag:workstation) and configure ACLs — a list of rules defining who can access what. The control plane stores and enforces these policies, not traffic data. This is covered in depth in episode 6.

#Exit Nodes and Subnet Routers

Two important capabilities that use the mesh architecture:

• Exit node: a node used to forward all traffic out to the internet.
• Subnet router: a node that bridges a local network (for example a home LAN) into the tailnet.

Both are covered in full in episode 9.

#Architecture Summary

Tailscale's architecture can be summarized in one sentence: the control plane coordinates keys and configuration, the WireGuard data plane carries encrypted traffic directly between nodes, and the DERP relay stands by when a direct connection fails.

tailscale up
    |-- tailscaled daemon
    |-- control plane: register node keys, get peer info
    |-- NAT traversal -> direct WireGuard connection
    |-- fallback -> DERP relay
    +-- MagicDNS: .ts.net hostname for easy access

With this architecture, Tailscale solves connectivity behind NAT without sacrificing end-to-end encryption.

#Closing

Episode 2 lifted the veil on Tailscale's architecture: you now know what a tailnet and mesh network are, why the control plane never sees your data, how NAT traversal and DERP work together, and the components tailscaled, the CLI, MagicDNS, and node keys.

Key takeaways:

• A tailnet is a mesh network: every node connects directly to every other node.
• The control plane handles coordination; the data plane carries encrypted traffic.
• Traffic between nodes never passes through the control plane.
• NAT traversal is tried first; the DERP relay is the fallback.
• tailscaled is the daemon, tailscale is the CLI, and MagicDNS provides .ts.net hostnames.
• Node key expiry prevents unused devices from accumulating.

In the next episode, episode 3, we'll do a complete first setup and onboarding — from tailscale up opening a browser for authentication, completing onboarding in the admin console, to getting to know the Machines page for naming devices, configuring key expiry, and removing unused devices.