tailscale-tutoroal-vpn

@amitmund August 18, 2026

Tailscale Tutorial — Secure Connectivity Across Every OS

Tailscale creates a private, encrypted mesh network (a "tailnet") between your devices, no matter where they physically are — home, office, cloud VM, phone on mobile data. It's built on WireGuard, so every connection is point-to-point encrypted, and it handles NAT traversal automatically so you rarely need to open firewall ports or configure a traditional VPN server.

1. How It Actually Works

  • WireGuard under the hood — Tailscale doesn't invent its own crypto; it orchestrates standard WireGuard tunnels between your devices.
  • Coordination server, not a traffic relay — Tailscale's control servers only help devices discover each other and exchange keys. Actual data traffic goes directly between your devices (peer-to-peer) whenever possible — it doesn't route through Tailscale's infrastructure.
  • DERP relays as fallback — if a direct peer-to-peer connection can't be established (strict NAT/firewall on both ends), traffic falls back to an encrypted relay server. This still can't be read by Tailscale — it's encrypted end-to-end — but it does add latency versus a direct path.
  • MagicDNS — every device gets a stable name like laptop.your-tailnet.ts.net that resolves correctly no matter which network it's actually on.
  • 100.x.x.x addresses — each device gets a fixed private IP in the 100.64.0.0/10 (CGNAT) range that stays the same regardless of physical location or Wi-Fi network.
   Your Laptop (Wi-Fi at a café)                Your Home Server
        │                                              │
        └──────────── encrypted WireGuard ─────────────┘
                    (direct, or via DERP relay
                     if direct isn't possible)

   Both devices found each other via Tailscale's
   coordination server, which only exchanged keys —
   it never sees your actual traffic.

2. Create Your Account & Tailnet

  1. Go to tailscale.com and sign up — you can use Google, Microsoft, GitHub, Apple, Okta, or a work SSO/email identity provider instead of a new password.
  2. Signing up automatically creates your tailnet (your private network).
  3. The free personal tier supports up to 100 devices and 3 users — plenty for personal/home-lab use.

3. Installing on Each OS

Windows

  1. Download the installer from https://tailscale.com/download/windows.
  2. Run the .msi installer — it installs a system tray app and a background service.
  3. Click the Tailscale icon in the system tray → Log in → authenticate in the browser window that opens.
  4. Once connected, the tray icon shows your device is online and lists other devices on your tailnet.

Alternative install via winget:

winget install tailscale.tailscale

macOS

Option A — Mac App Store (simplest, sandboxed): 1. Search "Tailscale" in the App Store and install. 2. Open it, click the menu bar icon → Log in.

Option B — Homebrew (standalone, more configurable):

brew install --cask tailscale

Then open Tailscale from Applications and log in via the menu bar icon.

Option C — CLI-only install (useful for headless Macs / Mac minis used as servers):

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Linux (Debian/Ubuntu)

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

The install script auto-detects your distro and adds the correct APT/YUM/DNF repository, then installs the tailscaled daemon.

sudo tailscale up prints a login URL — open it in any browser (doesn't need to be on the same machine) to authenticate the device.

Linux (Fedora/RHEL/CentOS)

sudo dnf install -y https://pkgs.tailscale.com/stable/fedora/tailscale.repo
sudo dnf install -y tailscale
sudo systemctl enable --now tailscaled
sudo tailscale up

Linux (Arch)

sudo pacman -S tailscale
sudo systemctl enable --now tailscaled
sudo tailscale up

iOS / iPadOS

  1. Install Tailscale from the App Store.
  2. Open the app → Log in → authenticate.
  3. iOS will prompt you to allow a VPN configuration — approve it (this is how iOS lets Tailscale route tailnet traffic; it doesn't mean all your traffic goes through Tailscale, only tailnet-destined traffic, unless you enable an exit node).

Android

  1. Install Tailscale from the Google Play Store (or F-Droid if you prefer an open-source-only source — search "Tailscale F-Droid").
  2. Open the app → Log in → authenticate.
  3. Approve the Android VPN permission prompt.

Synology NAS

  1. Open Package Center → search "Tailscale" → Install (available on DSM 7+ for many models).
  2. Open the Tailscale package, log in via the provided URL.

Docker

docker run -d --name=tailscale \
  -v /var/lib/tailscale:/var/lib/tailscale \
  --network=host \
  --cap-add=NET_ADMIN --cap-add=NET_RAW \
  -e TS_AUTHKEY=tskey-auth-xxxxxxx \
  tailscale/tailscale

Generate TS_AUTHKEY from the admin console (Settings → Keys → Generate auth key) so the container can authenticate non-interactively — useful for servers/CI where you can't click through a browser login.

Router-level (whole-network coverage)

Some routers (certain OPNsense, pfSense, GL.iNet, and select consumer routers) support running Tailscale directly on the router itself — every device on that LAN gets tailnet access without installing anything individually. Check tailscale.com/kb/install-x for your specific router's supported install method, since this varies significantly by hardware/firmware.

4. Verify Everything Is Connected

From any device's terminal (or Tailscale > Preferences on GUI apps):

tailscale status

This lists every device on your tailnet, its 100.x.x.x IP, and whether the connection to it is direct or going through a relay.

tailscale ping other-device-name

Confirms reachability and shows whether the path is direct or relayed.

Test MagicDNS name resolution:

ping laptop.your-tailnet-name.ts.net

5. Key Features Worth Setting Up

MagicDNS

Turn it on in the admin console (DNS → Enable MagicDNS) so every device can reach every other device by name instead of memorizing 100.x.x.x addresses.

Subnet Routers

Lets a single Tailscale node advertise an entire local subnet (e.g. your home LAN 192.168.1.0/24) to the rest of the tailnet, so other devices can reach things on that LAN — printers, NAS, IoT devices — without installing Tailscale on each of them individually.

sudo tailscale up --advertise-routes=192.168.1.0/24

Then approve the route in the admin console (Machines → this device → Edit route settings) — routes require manual approval by default for safety.

Exit Nodes

Route all of a device's internet traffic through another tailnet device — useful for routing phone traffic through a home connection while on untrusted public Wi-Fi.

# On the device that will BE the exit node:
sudo tailscale up --advertise-exit-node

# On the device that will USE it:
sudo tailscale up --exit-node=<exit-node-device-name>

Approve the exit node in the admin console the same way as subnet routes.

Tailscale SSH

Lets you SSH between tailnet devices using Tailscale's own identity/auth instead of managing separate SSH keys:

sudo tailscale up --ssh
ssh username@device-name

Access can be controlled precisely through ACLs (below) — e.g. "only my laptop can SSH into the home server."

ACLs (Access Control Lists)

Define fine-grained rules for which devices/users can reach which other devices, in the admin console under Access Controls, using a JSON/HuJSON policy file. Example — restrict a shared device so only your "admin" group can reach it over SSH:

{
  "acls": [
    {
      "action": "accept",
      "src":    ["group:admin"],
      "dst":    ["tag:server:22"]
    }
  ]
}

Tailscale Serve / Funnel

  • Serve exposes a local service to just your tailnet over HTTPS with a real certificate — no port forwarding.
  • Funnel goes further and exposes it to the public internet through Tailscale's infrastructure, useful for quick demos or webhooks.
tailscale serve https / http://localhost:3000
tailscale funnel 3000 on

6. Troubleshooting

Symptom Likely Cause Fix
Device shows "offline" to peers tailscaled service not running sudo systemctl status tailscaled (Linux); restart the app (Win/Mac)
High latency between two devices Connection is relayed, not direct tailscale ping <device> shows relay vs direct; usually caused by symmetric NAT on both ends — often unavoidable without router config changes
Can't reach devices on a subnet router's LAN Route not approved yet Admin console → Machines → approve the advertised route
MagicDNS names don't resolve MagicDNS disabled, or device's OS DNS override Enable MagicDNS in admin console; check the device isn't force-overriding DNS servers
Mobile device drains battery faster Always-on VPN + exit node routing all traffic Disable exit node use when not needed, or use it only on-demand
tailscale up fails with permission error Not run with sufficient privileges (Linux) Re-run with sudo

7. Security Best Practices

  • Enable device approval in the admin console (Settings → Device management) so new devices can't join your tailnet without explicit approval, even if someone has your login.
  • Set key expiry appropriately — long-lived servers can have expiry disabled per-device, but personal devices should keep default expiry/renewal so a lost/stolen device eventually loses access.
  • Use ACLs rather than leaving the default "everything can reach everything" policy once your tailnet grows beyond a couple of trusted personal devices.
  • Tag servers (e.g. tag:server, tag:prod) instead of relying on personal user identity for machine-to-machine policy — tags survive employee/user changes more cleanly than per-user ACL rules.
  • Review connected devices periodically in the admin console and remove anything you don't recognize or no longer use.
  • Use auth keys with expiry and tags for automated/non-interactive installs (servers, Docker, CI) rather than long-lived, untagged keys.

Quick Reference — Common Commands

tailscale up                          # connect this device to the tailnet
tailscale down                        # disconnect (but stay logged in)
tailscale status                      # list all devices and connection state
tailscale ping <device>               # test reachability + direct/relay status
tailscale ip -4                       # show this device's tailnet IPv4 address
tailscale netcheck                    # diagnose NAT type and connectivity
tailscale up --advertise-routes=CIDR  # advertise a subnet route
tailscale up --advertise-exit-node    # offer this device as an exit node
tailscale up --exit-node=<name>       # use another device as your exit node
tailscale up --ssh                    # enable Tailscale SSH on this device
tailscale serve ...                   # expose a local service to your tailnet
tailscale funnel ...                  # expose a local service to the internet

Yes, you can use Tailscale as a peer-to-peer (P2P) network regardless of physical distance. Distance itself does not prevent direct connections; Tailscale uses the WireGuard protocol to establish encrypted tunnels directly between devices anywhere in the world, provided the network infrastructure (NAT/Firewalls) allows it.

However, the concept of "replication factors" does not apply to Tailscale in the way it does for distributed databases (like Cassandra or Kubernetes). Tailscale is a mesh network, not a data replication system. Instead of "replicating" a server, you optimize reliability and speed by deploying Peer Relays or DERP servers.

Direct P2P vs. Relayed Connections

Tailscale always attempts a direct connection first, which offers the lowest latency regardless of distance.

Direct P2P: If both Linux systems can punch through their respective NATs/Firewalls, they connect directly. Distance adds only the speed-of-light latency (e.g., ~80ms between US and Europe).

The Problem (Hard NAT): If one or more of your systems are behind restrictive firewalls, Carrier-Grade NAT (CGNAT), or strict corporate networks, direct P2P may fail.

The Fallback: Without intervention, traffic falls back to Tailscale’s public DERP (Designated Encrypted Relay for Packets) servers, which might be geographically distant, increasing latency.

For remote linux interface, without a desktop browser, you will use an Auth Key or copy-paste a url.

sudo tailscale up

The terminal will output a URL (e.g., https://login.tailscale.com/a/8xK9...). Open this link in any browser, log in with your identity provider (Google, GitHub, Microsoft, etc.), and authorize the device.

on-Interactive Login (Auth Keys):

For headless automation, generate a one-time Auth Key from the Tailscale Admin Console (Settings > Keys). Then run on each server:

sudo tailscale up --auth-key=tskey-XXXXXXXXXXXXXXXX

Enable SSH Access

To easily SSH between these machines without managing SSH keys for IP changes, you can enable Tailscale SSH:

sudo tailscale up --ssh

You can then connect directly using the machine name: ssh user@server-2. Note that this requires configuring Access Control Lists (ACLs) in the admin console to allow SSH access between your devices

p2p:

you can use Tailscale as a peer-to-peer (P2P) network regardless of physical distance. Distance itself does not prevent direct connections; Tailscale uses the WireGuard protocol to establish encrypted tunnels directly between devices anywhere in the world, provided the network infrastructure (NAT/Firewalls) allows it.

Tailscale is a mesh network, not a data replication system. Instead of "replicating" a server, you optimize reliability and speed by deploying Peer Relays or DERP servers.

Direct P2P vs. Relayed Connections

Tailscale always attempts a direct connection first, which offers the lowest latency regardless of distance.

Direct P2P: If both Linux systems can punch through their respective NATs/Firewalls, they connect directly. Distance adds only the speed-of-light latency (e.g., ~80ms between US and Europe).

The Problem (Hard NAT): If one or more of your systems are behind restrictive firewalls, Carrier-Grade NAT (CGNAT), or strict corporate networks, direct P2P may fail.

The Fallback: Without intervention, traffic falls back to Tailscale’s public DERP (Designated Encrypted Relay for Packets) servers, which might be geographically distant, increasing latency.

The Solution: Self-Hosted "Relays" (Not Replication)

Instead of "increasing replication factors," you install Peer Relays or DERP servers on your high-performance Linux nodes to ensure low-latency connectivity when direct P2P fails.

What it is: You designate one of your existing Linux servers (preferably one with a public IP or open UDP ports) to act as a relay for the other two.

Benefit: It keeps traffic within your own infrastructure. If System A cannot connect directly to System B, it routes via your self-hosted Peer Relay, which is often faster and more private than using Tailscale’s public servers.

Setup: Enable the relay capability on a node and configure Access Control Lists (ACLs) to allow other nodes to use it.

Self-Hosted DERP Servers:

What it is: If you need a dedicated relay node that only relays traffic and doesn't act as a standard peer, you can run a DERP server (using the derper binary) on one of your Linux machines.

Use Case: Ideal if all three locations have strict firewalls that block direct P2P. You configure your tailnet to use your custom DERP server instead of Tailscale’s default fleet.

Performance: By placing a DERP server in a central location or on the node with the best connectivity, you ensure that relayed traffic doesn't have to travel to a distant public cloud region.

0 Likes
40 Views
0 Comments

Filters

No filters available for this view.

Reset All