Tailscale è uno di quegli strumenti che ti fanno cambiare modo di pensare alla rete. Da quando l’ho introdotto nel mio homelab, ho smesso di configurare port forwarding sul router, certificati Wireguard a mano, regole NAT e DDNS. è diventato il tessuto connettivo invisibile fra tutti i miei device, dal portatile in casa fino a un piccolo server ARM su un tier gratuito di un provider cloud.

Cos’è davvero

Tailscale è una VPN mesh costruita sopra Wireguard. La parte interessante: il traffico non passa per un server centrale (il control plane fa solo coordinamento, distribuendo chiavi e aiutando il NAT traversal). I device si parlano peer-to-peer, cifrati, anche quando sono dietro NAT che normalmente sarebbero impenetrabili.

Ogni device riceve un IP nel range CGNAT 100.64.0.0/10, persistente, raggiungibile da ogni altro device della tua tailnet. Niente DNS dinamico, niente “qual era l’IP pubblico oggi?”. Negli esempi userò indirizzi generici tipo 100.64.1.10 e 100.64.1.20, non quelli della mia tailnet.

Installare

Su Linux Debian/Ubuntu/Raspberry Pi OS:


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

Su macOS via brew o dall’App Store:


brew install --cask tailscale

Su Mac la app gira come menu bar item e si autentica con SSO al primo lancio.

Su server headless preferisco il flag --ssh, così posso usare l’auth Tailscale invece di gestire chiavi SSH separate:


sudo tailscale up --ssh --advertise-tags=tag:server

Al primo up, apre un URL nel browser che porta alla pagina di Tailscale per autenticarsi (Google, Microsoft, GitHub o passkey). Da quel momento il device è nella tailnet.

ACL e tag

Tutti i device nella stessa tailnet di default possono parlarsi tutti con tutti. Per un homelab serio non basta, e l’ACL via tag è la prima cosa che configuro. Esempio di policy nella console web:


{
  "tagOwners": {
    "tag:server":   ["autogroup:admin"],
    "tag:laptop":   ["autogroup:admin"],
    "tag:iot":      ["autogroup:admin"]
  },
  "acls": [
    { "action": "accept", "src": ["tag:laptop"], "dst": ["tag:server:22,80,443,8086"] },
    { "action": "accept", "src": ["tag:server"], "dst": ["tag:server:*"] }
  ]
}

I device taggati tag:iot non possono parlare con i server, ma solo con il gateway IoT dedicato. Il portatile arriva ai server solo su SSH, HTTP, HTTPS e InfluxDB. I server si parlano fra loro liberamente. Una compromissione su un device IoT è contenuta entro il suo segmento logico.

Subnet router e exit node

Quando ho un dispositivo che non posso o non voglio mettere in tailnet (vecchio NAS, stampante, switch), faccio annunciare la sua subnet a un Pi che è in tailnet:


sudo tailscale up --advertise-routes=198.51.100.0/24 --advertise-tags=tag:server

Dalla console web approvo la route. Da quel momento ogni device in tailnet può raggiungere quelle macchine direttamente per IP, senza che abbiano installato Tailscale loro stessi. Stesso meccanismo per l’exit node: un nodo in cloud annunciato come exit, e il portatile in viaggio ci dirige tutto il traffico per uscire da IP fissi.

Un caso reale

Una sera tardi, intorno alle 22:00, un familiare a 800 km mi ha chiesto aiuto con il suo piccolo homelab: un Raspberry Pi che faceva da Home Assistant non rispondeva più dall’esterno. Per anni avevamo gestito quel collegamento con port forwarding e DDNS, e ovviamente qualcosa nel router gli era cambiato dopo un update firmware. Invece di guidarlo passo passo in chiamata, gli ho installato Tailscale dal terminale con un curl ... | sh e un tailscale up. In tre minuti il suo Pi era nella tailnet, ho potuto fare SSH come se fosse nella mia stessa LAN, e ho fixato la sua configurazione in altri cinque. Da quel giorno il port forwarding sul suo router è disattivato e tutte le interazioni passano per la tailnet, cifrate e segmentate dalle ACL.

Cosa funziona bene

Tailscale taglia gli ostacoli di rete in modo sorprendente: NAT, CGNAT del provider, IPv6 incompatibile fra peer, non sono più problemi. MagicDNS dà nomi friendly ai device. Il free plan personale ha limiti più che generosi per un homelab (100 device, ACL illimitate). L’integrazione con SSO permette di legare l’identità a Google/Microsoft, e si revoca un device con un click se finisce per terra in tram.

Limiti

è un servizio proprietario centralizzato per il control plane: se Tailscale Inc. va offline, le nuove connessioni non partono (quelle stabilite continuano per un po’). Per chi vuole sovranità totale c’è Headscale, un control plane open source compatibile, che valuto periodicamente. Le ACL sono potenti ma vanno scritte con cura, perché un errore può aprire flussi non voluti fra tag.

In pratica

Tailscale è il sistema nervoso del mio homelab distribuito. Senza di lui dovrei gestire VPN site-to-site, certificati Wireguard, regole iptables a mano e DDNS. Con lui, la rete è semplicemente “tutto vede tutto secondo ACL”, e posso concentrarmi sul resto. è uno dei pochi servizi che, se sparisse domani, mi creerebbe più problemi che la perdita di un server fisico.

Immagine generata con ComfyUI Mac M1 / RealVisXL V5 Lightning.

Articolo originale su rpi.temporiti.net