Il proprio server di controllo.
La mappa è la cosa che vale la pena possedere.

Ci sono tre risposte oneste a "voglio che le mie macchine si raggiungano privatamente", e solo una di esse è questa guida. WireGuard puro è la più piccola: un modulo del kernel, un file di configurazione per peer, nessun daemon oltre all'interfaccia, nulla da tenere aggiornato tranne il sistema operativo. Se i suoi dispositivi sono server con indirizzi fissi e può contarli su una mano, si fermi qui e legga invece la guida a WireGuard. Finirà con meno software e un elenco più corto di cose che possono rompersi.

Tailscale è la più grande delle tre: sotto il cofano lo stesso WireGuard, più un servizio di coordinamento, un NAT traversal che funziona da dietro quasi qualunque rete, una flotta di relay su più continenti, una console web, il single sign-on e un contratto di supporto. È software genuinamente eccellente e il piano gratuito copre comodamente una famiglia. Il prezzo non è in denaro: è che la mappa di ogni dispositivo che possiede, e il registro di dove ciascuno si collega, vivono nel database di un'azienda.

Headscale è la terza risposta, ed è più circoscritta di entrambe: una reimplementazione open source del server di coordinamento, gestita da lei, con cui dialoga lo stesso client ufficiale. Mantiene l'automazione e il NAT traversal; si assume un piccolo servizio da gestire, un set di funzionalità parziale e aggiornamenti che vanno letti con attenzione. Nessuno dovrebbe far finta che questo sia gratis. Compra esattamente una cosa, ed è quella a cui questo sito tiene davvero: nessun altro possiede la mappa.

Un'altra cosa da decidere ora piuttosto che dopo, perché cambia cosa installa: se questa rete è solo per lei, o se altre persone vi si uniranno. Un tailnet per una sola persona può restare completamente aperto all'interno senza che accada nulla di male. Un tailnet con un collega, un collaboratore esterno o un familiare ha bisogno di regole di accesso scritte fin dalla prima settimana — passo 05 — e ha bisogno che gli utenti siano separati invece che tutti condividano lo stesso login. Deciderlo in anticipo costa un paragrafo; adattarlo in seguito costa un pomeriggio.

Headscale e Caddy, e nient'altro. Headscale ascolta in HTTP semplice all'interno della rete Docker; Caddy termina il TLS, ottiene il certificato al primo avvio e lo rinnova senza che gli venga chiesto. Il listener delle metriche resta su localhost, perché è una superficie di debug interna e non pubblica.

Una regola prima del file: blocchi l'immagine su una versione esatta. Headscale è software pre-1.0 che ha rinominato chiavi di configurazione e sottocomandi della CLI tra release minori più di una volta. Un tag mobile trasforma un normale riavvio del container in un'interruzione di un servizio il cui compito è farle raggiungere tutto il resto.

/srv/headscale/docker-compose.yml

services:
  headscale:
    image: docker.io/headscale/headscale:0.26            # pin it; never :latest
    container_name: headscale
    command: serve
    volumes:
      - ./config:/etc/headscale
      - ./data:/var/lib/headscale
    ports:
      - "3478:3478/udp"                                  # STUN, for your own DERP
    restart: unless-stopped

  caddy:
    image: caddy:2-alpine
    container_name: caddy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
    restart: unless-stopped

volumes:
  caddy_data:

/srv/headscale/Caddyfile

vpn.example.com {
    reverse_proxy headscale:8080
}

Questa è l'intera configurazione del proxy. Caddy parla HTTP/2 e fa l'upgrade delle connessioni di lunga durata senza che glielo si chieda, il che qui conta perché ogni client ne mantiene una aperta per ricevere gli aggiornamenti della mappa. Prenda il file di configurazione di esempio incluso nella versione che ha bloccato e lo modifichi invece di scriverne uno da zero — il file è lungo, la maggior parte sono valori predefiniti sensati, e le chiavi che contano sono queste:

/srv/headscale/config/config.yaml — the lines that matter

server_url: https://vpn.example.com          # exactly what clients will dial
listen_addr: 0.0.0.0:8080                    # inside the Docker network only
metrics_listen_addr: 127.0.0.1:9090          # debug surface, keep it local

prefixes:
  v4: 100.64.0.0/10
  v6: fd7a:115c:a1e0::/48

noise:
  private_key_path: /var/lib/headscale/noise_private.key

database:
  type: sqlite                               # postgres for a large fleet
  sqlite:
    path: /var/lib/headscale/db.sqlite

dns:
  magic_dns: true
  base_domain: ts.example.com                # NOT a parent or child of server_url
  nameservers:
    global:
      - 1.1.1.1                              # replaced by your own in step 05

Lo avvii, poi legga il log invece di dare per scontato. Un primo avvio che non riesce a ottenere un certificato, o che rifiuta il suffisso DNS perché si sovrappone all'hostname del server, lo dice chiaramente e poi si ferma.

docker compose up -d
docker compose logs -f headscale

# From your laptop — a control server that is up answers this:
curl -s https://vpn.example.com/health

Il primo avvio genera il materiale della chiave privata in /srv/headscale/data. Lo copi da qualche parte al sicuro subito, prima che si registri anche un solo dispositivo, e di nuovo dopo la prima registrazione: perdere quella chiave significa che ogni dispositivo rifiuta il server di cui si fidava, e l'unica riparazione è reiscriverli tutti a mano. Il passo 06 trasforma quella copia in un backup vero e proprio.

Un tailnet in cui ogni dispositivo raggiunge ogni altro dispositivo è già utile di per sé. Tre aggiunte lo trasformano in una rete vera e propria anziché in un insieme di tunnel, e tutte e tre condividono una caratteristica che trae in inganno molti: il client annuncia una capacità, e il server deve approvarla. Una rotta annunciata ma non approvata semplicemente non esiste, in silenzio, e il sintomo è che si riesce a fare il ping del router ma nulla dietro di esso risponde.

Un router di sottorete — porti un'intera LAN sul tailnet. Una macchina su una rete domestica o d'ufficio annuncia l'intervallo della rete; ogni altro dispositivo raggiunge quindi le stampanti, il NAS e le interfacce di gestione dietro di essa senza dover installare nient'altro lì. Attivi prima l'inoltro nel kernel, altrimenti i pacchetti si fermano al router senza alcun messaggio di errore.

# On the machine that sits inside the LAN:
echo 'net.ipv4.ip_forward = 1'          | sudo tee /etc/sysctl.d/99-ts.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-ts.conf
sudo sysctl -p /etc/sysctl.d/99-ts.conf

sudo tailscale up --login-server https://vpn.example.com \
  --advertise-routes=192.168.1.0/24 --accept-routes

# On the control server — approve it, or it does not exist.
# The subcommand moved between releases; check `hs nodes --help` first.
hs nodes list
hs nodes approve-routes --identifier 3 --routes 192.168.1.0/24

Un nodo di uscita — faccia uscire tutto attraverso il VPS. Lo stesso meccanismo con una rotta più ampia: un dispositivo che si annuncia come nodo di uscita offre di trasportare l'intera connessione internet di un altro dispositivo. Su una rete non fidata di un bar o di un hotel è esattamente ciò che serve, ed è la cosa più vicina a una VPN personale che questa guida offra.

# On the VPS that will do the exiting (forwarding must be on, as above):
sudo tailscale up --login-server https://vpn.example.com --advertise-exit-node

# Approve it on the control server, then on the laptop:
tailscale set --exit-node=100.64.0.1 --exit-node-allow-lan-access
tailscale set --exit-node=                    # turn it off again

Un nodo di uscita non è una VPN commerciale e non va venduto a se stessi come tale. Il suo indirizzo è solo suo ed è stabile, il che è eccellente contro il Wi-Fi del bar e inutile contro la correlazione a lungo termine tra siti diversi — il compromesso è spiegato nella guida pilastro. Noti anche che può far girare il nodo di uscita su un secondo VPS più economico e tenere il server di controllo completamente libero da traffico inoltrato.

Regole di accesso — le scriva prima che si unisca una seconda persona. La policy predefinita è consenti-tutto, il che è corretto per un tailnet di una sola persona e sbagliato nel momento in cui qualcun altro vi entra. La policy è un piccolo documento HuJSON: gruppi di utenti, tag per le macchine, e un elenco di regole che stabiliscono quali sorgenti possono raggiungere quali destinazioni su quali porte. Punti la configurazione al file, tenga il file sotto controllo di versione, e ricarichi dopo ogni modifica.

{
  "groups": {
    "group:admin":     ["alice"],
    "group:contractor":["bob"]
  },
  "tagOwners": {
    "tag:server": ["group:admin"],
    "tag:exit":   ["group:admin"]
  },
  "acls": [
    // Admins reach everything.
    { "action": "accept", "src": ["group:admin"], "dst": ["*:*"] },

    // The contractor reaches one machine, on two ports, and nothing else.
    { "action": "accept", "src": ["group:contractor"],
      "dst": ["tag:server:22,443"] }
  ],
  "autoApprovers": {
    "routes":   { "192.168.1.0/24": ["tag:server"] },
    "exitNode": ["tag:exit"]
  }
}

Due note su quel file. Il linguaggio della policy è quello di Tailscale, e Headscale ne implementa un sottoinsieme ampio e in crescita, non tutto — controlli la documentazione della sua versione prima di affidarsi a una regola esotica. E il punto in cui la policy risiede si è spostato: le release più vecchie indicavano un percorso nella configurazione di primo livello, quelle più nuove la raggruppano sotto una sezione policy con una modalità che può anche tenere le regole nel database. Entrambe sono documentate; quella che conta è quella che spedisce la sua versione bloccata.

MagicDNS — nomi brevi, e il proprio resolver ovunque. Con MagicDNS attivo, ogni dispositivo risponde a un nome breve all'interno del suffisso scelto al passo 02, quindi ssh nas funziona da qualunque luogo senza un file hosts. La seconda metà è quella interessante: il server di controllo invia anche un elenco di nameserver a ogni client, il che significa che il resolver costruito nella guida al resolver DNS privato può servire il suo telefono sui dati mobili — filtrando, mettendo in cache e senza registrare nulla — pur restando in ascolto su un indirizzo del tailnet che non è raggiungibile da internet in alcun modo.

dns:
  magic_dns: true
  base_domain: ts.example.com
  override_local_dns: true          # beat whatever DHCP handed the device
  nameservers:
    global:
      - 100.64.0.5                  # your resolver, on the tailnet

Il self-hosting del piano di controllo è un miglioramento reale e specifico, e non è un gioco di prestigio. Cinque cose restano vere anche dopo aver fatto tutto quanto sopra, e conoscerle è la differenza tra una difesa vera e propria e una storia consolatoria.

Il server di controllo è un endpoint pubblico e nominato. Ogni dispositivo lo contatta, quindi ha un hostname, e quell'hostname viene pubblicato nei log di certificate transparency nel momento stesso in cui il certificato viene emesso. È individuabile anche se non ci si collega mai a esso, e il suo indirizzo è l'unica costante che tutti i suoi dispositivi hanno in comune. Usi un sottodominio di un nome che già pubblica, invece di uno che descrive cosa esso sia.

Headscale è una reimplementazione, e lo dichiara apertamente. Non è realizzato né supportato da Tailscale, la parità di funzionalità è parziale per costruzione, e parte di ciò che il prodotto ospitato vende — la console web, la flotta di relay pubblica, i percorsi di single sign-on rifiniti — o non esiste qui oppure è un progetto di terze parti che nessuno ha verificato. Legga la documentazione del progetto per sapere se una funzionalità esiste prima di costruirci un piano attorno, e tratti gli aggiornamenti come un compito, non come un processo in background.

I relay predefiniti restano comunque di qualcun altro. Finché non attiva il server DERP integrato, una connessione che non riesce ad andare direct ripiega sulla flotta di relay pubblica. Il payload resta comunque cifrato end-to-end e nessuno può leggerlo — ma il fatto che due dei suoi dispositivi stiano parlando, e quanto, transita su un'infrastruttura che non possiede. Questa è la parte della catena di fiducia che quasi tutti si perdono il primo pomeriggio.

Un nodo di uscita è un indirizzo stabile, non una folla. Instradare il suo traffico attraverso il proprio VPS sconfigge la rete del bar e il profilo dell'ISP. Non sconfigge la correlazione, perché quell'indirizzo appartiene solo a lei e non cambia. L'indirizzo condiviso di una VPN commerciale è peggiore sotto ogni aspetto tranne quello che conta per quella particolare minaccia.

La macchina è pur sempre dentro un edificio. Un server affittato gira su hardware in un data center con porte e personale. Ciò che cambia è che non esiste un indice a livello di prodotto dei suoi dispositivi, nessun database aziendale che registra da dove si collega ciascuno di essi, e nessuna informativa sulla privacy che possa essere modificata il prossimo trimestre. Ciò che non cambia è che il disco è fisico e non è a casa sua.

Ciò che ha effettivamente comprato, con precisione: l'elenco di ogni macchina che possiede, il registro di dove ciascuna si collega, e l'autorità di aggiungerne una nuova, sono tutti custoditi su un server che affitta senza un nome particolare. È un'affermazione circoscritta ed è reale. Vale ciò che costa solo se il passo 06 è stato completato — un piano di controllo self-hosted senza un ripristino testato non è un miglioramento della privacy, è un singolo punto di guasto con un branding migliore.