SSD Nodes Learn Hosting plans →
Guide Matt ConnorDi Matt Connor

NetBird o Tailscale: quale VPN mesh scegliere

Entrambi usano WireGuard, ma cambiano control plane, regole di accesso, relay e gestione. Confronta hosted, self-hosting NetBird e requisiti operativi.

NetBird rispetto a Tailscale: la risposta breve

Il confronto tra NetBird e Tailscale riguarda il control plane, perché entrambe le VPN mesh trasportano i pacchetti tramite WireGuard. Tailscale gestisce per te il proprio server di coordinamento, che è closed source. NetBird offre un servizio hosted dello stesso tipo. Pubblica inoltre il proprio management server con una licenza open, quindi puoi eseguire l’intero sistema su un singolo VPS. Scegli Tailscale se nessuno del tuo team deve gestire un server. Scegli NetBird se il control plane deve essere eseguito su hardware sotto il tuo controllo.

Se stai ancora confrontando più di due strumenti, inizia dall’elenco più ampio delle alternative a Tailscale. Le sezioni seguenti confrontano direttamente questi due strumenti sui quattro aspetti in cui differiscono realmente.

Cosa hanno in comune: WireGuard alla base

Una VPN mesh (rete privata virtuale) connette direttamente ogni dispositivo a tutti gli altri. Il traffico non passa attraverso un gateway centrale. Entrambi gli strumenti assegnano a ogni dispositivo una coppia di chiavi WireGuard. La chiave privata viene creata sul dispositivo e non lo lascia mai. Entrambi tentano quindi di creare un tunnel diretto tra due peer. Usano un relay solo quando il percorso diretto non è disponibile.

Questo significa che la cifratura sul collegamento usa lo stesso protocollo in entrambi i prodotti. In entrambi i sistemi, un relay inoltra pacchetti WireGuard che non può decrittografare, perché non possiede alcuna chiave privata. Per il confronto di base senza alcun control plane, leggi cosa aggiunge Tailscale rispetto a WireGuard puro.

Una differenza riguarda il data path. Tailscale esegue WireGuard in userspace tramite wireguard-go. Il README di NetBird indica WireGuard nel kernel su Linux. Non scegliere basandoti soltanto su questo aspetto. Esegui iperf3 attraverso il tunnel sul tuo VPS. Il limite dipende in genere prima dalla CPU, dal limite di banda o dal percorso di rete tra i peer.

Chi gestisce il control plane?

Il control plane è il server che conosce la chiave pubblica e l'indirizzo del tunnel di ogni dispositivo. Indica a ciascun dispositivo quali peer esistono e quali di essi può raggiungere. Non trasporta il traffico.

Tailscale. Il server di coordinamento è closed source. Viene eseguito esclusivamente come servizio ospitato da Tailscale. I client sono open source: il demone principale su ogni piattaforma, oltre ai client Linux e Android completi. Le applicazioni grafiche per Windows e macOS sono closed source. Il codice di DERP, il relay server di Tailscale, è open source. Se serve un control plane compatibile con Tailscale sul proprio server, l'opzione è Headscale. Tailscale lo descrive come un progetto indipendente gestito dalla community, sul quale non esercita alcuna direzione. La configurazione è descritta in eseguire Headscale come server di controllo Tailscale self-hosted.

NetBird. È disponibile un cloud ospitato all'indirizzo app.netbird.io e lo stesso codice è pubblicato su GitHub per l'esecuzione autonoma. A ottobre 2026 il README del repository indica chiaramente le licenze. Il client e la maggior parte del repository sono distribuiti con licenza BSD-3-Clause. Le directory management/, signal/ e relay/ sono distribuite con licenza AGPLv3 (GNU Affero General Public License, versione 3). La AGPL aggiunge una condizione. Se si modificano quei server e si consente ad altre persone di usarli tramite una rete, è necessario offrire loro il codice sorgente modificato.

Il lato server di NetBird è composto da tre parti. Il servizio management conserva lo stato della rete: chiavi dei peer, assegnazione degli indirizzi IP, controllo degli accessi e impostazioni DNS. Il servizio signal aiuta due peer a scambiarsi i candidati di connessione. Questi messaggi sono cifrati tra i peer, quindi signal non può leggerli. Il servizio relay trasporta il traffico quando non esiste un percorso diretto.

Come si scrivono le regole di accesso in ciascuno?

Entrambi i prodotti avviano una nuova rete con una regola che consente tutto il traffico. Ogni dispositivo può raggiungere tutti gli altri finché non si modifica questa regola. Sostituiscila prima di aggiungere un server che contiene dati importanti.

Tailscale: un unico file di policy

Tailscale conserva tutte le regole di accesso nel file di policy della tailnet. Il formato è HuJSON (JSON leggibile), cioè JSON che consente anche commenti e virgole finali. Puoi modificarlo nella console di amministrazione oppure inviarlo tramite l'API. Le regole correnti sono scritte come grants. Questo file consente a un gruppo di raggiungere i server di produzione contrassegnati, limitando l'accesso a SSH e HTTPS. Include anche un test:

{
  "groups": {
    "group:engineering": ["alice@example.com", "bob@example.com"]
  },
  "tagOwners": {
    "tag:production": ["group:engineering"]
  },
  "grants": [
    {
      "src": ["group:engineering"],
      "dst": ["tag:production"],
      "ip": ["tcp:22", "tcp:443"]
    }
  ],
  "tests": [
    {
      "src": "alice@example.com",
      "accept": ["tag:production:22"]
    }
  ]
}

La sezione tests è importante. Le relative asserzioni vengono eseguite come controlli ogni volta che il file di policy cambia. In questo modo una modifica errata viene rilevata prima dell'applicazione. La policy predefinita di una nuova tailnet è costituita da una singola voce acls con "src": ["*"] e "dst": ["*:*"]. Anche omettere completamente il campo acls equivale a consentire tutto il traffico. Elimina questa voce dopo aver configurato le autorizzazioni necessarie. A ottobre 2026, il piano gratuito Personal offre 3 gruppi ACL.

NetBird: gruppi e policy nella dashboard

NetBird basa il controllo degli accessi su gruppi e policy. Un gruppo è un insieme di peer. Puoi aggiungere peer a un gruppo manualmente, tramite i gruppi associati a una setup key oppure dai gruppi utente del tuo identity provider. Una policy specifica un gruppo sorgente e un gruppo di destinazione. Può essere unidirezionale o bidirezionale. Può anche limitare il protocollo e le porte, con gli intervalli scritti come 8000-9000. Una policy può inoltre includere controlli di postura. Un controllo di postura è una condizione che un peer deve soddisfare prima che la connessione venga consentita.

Configuri tutti questi elementi nella dashboard. Un nuovo account include una policy denominata Default che consente a tutti i peer di comunicare tra loro. Aggiungi prima le tue policy, quindi disabilita Default. Se vuoi gestire le regole come testo, NetBird mette a disposizione una REST API pubblica. Offre anche un provider Terraform ufficiale (netbirdio/netbird), compatibile sia con NetBird Cloud sia con un management server self-hosted. La documentazione sul controllo degli accessi di NetBird non descrive asserzioni di test integrate come la sezione tests di Tailscale. Con Terraform, puoi invece esaminare l'output del piano.

Come viene inoltrato il traffico quando non esiste un percorso diretto?

Entrambi gli strumenti tentano prima una connessione diretta. Usano STUN (utilità per l'attraversamento delle sessioni NAT) per conoscere l'indirizzo pubblico di ogni peer. Poi tentano di aprire un percorso attraverso il NAT (network address translation) su entrambi i lati. I firewall restrittivi e alcune reti mobili bloccano questa operazione, quindi entrambi gli strumenti richiedono un fallback.

Tailscale utilizza come fallback i server DERP (designated encrypted relay for packets). Tailscale li gestisce in molte regioni e trasporta il traffico tramite HTTPS. Non comportano costi aggiuntivi. Tailscale supporta anche i peer relay. Un peer relay è uno dei propri dispositivi che funge da relay; Tailscale lo prova prima di ricorrere a DERP. La documentazione di Tailscale presenta i peer relay come l'opzione da usare quando servono latenza inferiore e throughput superiore a quelli offerti da DERP. I peer relay sono disponibili in generale dal 18 February 2026, su tutti i piani, incluso quello gratuito. Per abilitarne uno, è sufficiente scegliere una porta UDP e autorizzarlo con una grant nel file delle policy:

sudo tailscale set --relay-server-port=40000

Per verificare quale percorso usa una connessione, eseguire tailscale ping verso un peer. Una risposta con via DERP(fra) indica che il traffico passa attraverso un relay. Una risposta che indica un indirizzo IP e una porta indica una connessione diretta. Se una connessione continua a usare un relay, perché un collegamento Tailscale inoltrato è lento e come ottenerne uno diretto analizza le possibili cause.

NetBird inoltrava il traffico tramite il server TURN coturn nelle release precedenti. La versione 0.29.0 ha introdotto NetBird Relay, che da allora ha sostituito coturn per le connessioni inoltrate. Il relay accetta connessioni WebSocket sul percorso /relay oppure connessioni QUIC sulla porta UDP 33080. Le indicazioni attuali spostano inoltre STUN nel servizio relay. Su NetBird Cloud, NetBird gestisce i relay. Su un server self-hosted, il relay viene gestito da te. Ogni byte inoltrato viene conteggiato nella larghezza di banda del VPS e ogni percorso inoltrato passa dalla posizione del VPS. Verificare il percorso per ogni peer con:

netbird status -d

Per ogni peer viene mostrato un tipo di connessione: P2P (diretta) oppure Relayed.

Che cosa comporta il self-hosting di NetBird su un unico VPS?

La quickstart ufficiale configura l'intero lato server con un unico script. A ottobre 2026 richiede una macchina Linux con almeno 1 CPU e 2 GB di memoria. Servono anche un nome di dominio pubblico che risolva verso il VPS e Docker con il compose plugin, jq e curl. Apri TCP 80, TCP 443 e UDP 3478 nel firewall del VPS. Aprili anche nel firewall di rete del provider, che nella maggior parte dei pannelli è un controllo separato.

export NETBIRD_DOMAIN=netbird.example.com; curl -fsSL https://github.com/netbirdio/netbird/releases/latest/download/getting-started.sh | bash

Lo script esegue il deployment di quattro tipi di servizio:

  • Traefik come reverse proxy, con certificati TLS (transport layer security) di Let's Encrypt.
  • Un server Dex integrato come identity provider, così puoi creare utenti nella dashboard senza un sistema di autenticazione esterno.
  • I servizi management, signal e relay descritti sopra.
  • Extra opzionali: il servizio NetBird Proxy e il filtro della reputazione IP di CrowdSec.

Da questo momento devi gestire direttamente ogni componente. L'identity provider determina chi può accedere e aggiungere dispositivi. Dex è sufficiente per un team di piccole dimensioni. In seguito puoi collegare un provider single sign-on esterno, ad esempio un server SSO Authentik self-hosted. TLS dipende dall'ordine delle operazioni. Let's Encrypt convalida il dominio connettendosi a questo VPS, quindi crea il record DNS e apri le porte prima di eseguire lo script. Se il dominio non risolve ancora verso il VPS, la convalida fallisce e il certificato non viene emesso. Anche backup e upgrade sono di tua responsabilità. La procedura completa di installazione, con un controllo dopo ogni passaggio, è disponibile nella guida al self-hosting di un server VPN NetBird.

Registrare un server Linux in ciascuna soluzione

Per entrare in una mesh è necessario poter accedere alla rete in uscita verso il control plane, quindi esegui questi comandi sul tuo computer. Un server non dispone di un browser, perciò entrambi gli strumenti usano una chiave creata in anticipo invece di un accesso interattivo.

Tailscale, con una auth key generata nella console di amministrazione:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --auth-key=YOUR_AUTH_KEY
tailscale status

tailscale status dovrebbe elencare questo computer con un indirizzo 100.x.y.z e gli altri dispositivi della tua tailnet. Una auth key senza scadenza impostata scade dopo 90 days, che è il limite massimo. Un server già registrato resta registrato. Uno script che registra nuovi server richiede una chiave nuova.

NetBird, con una setup key generata nella dashboard:

curl -fsSL https://pkgs.netbird.io/install.sh | sh
netbird up --setup-key YOUR_SETUP_KEY
netbird status

Su un server self-hosted, aggiungi --management-url https://netbird.example.com alla riga netbird up. In sua assenza, il client contatta NetBird Cloud, che non conosce una setup key creata sul tuo server. netbird status dovrebbe indicare i servizi di management e signal come connessi.

Piani gratuiti e prezzi a ottobre 2026

Questi dati provengono dalle due pagine dei prezzi consultate il 2 ottobre 2026. I prezzi possono cambiare, quindi verificateli nuovamente prima di prendere una decisione.

Tailscale Personal è gratuito per un massimo di 6 utenti, con un numero illimitato di dispositivi per utente. Include 50 risorse con tag, cioè server associati a un tag anziché a una persona, e 3 gruppi ACL. I piani a pagamento sono Standard, a $8 per utente al mese, e Premium, a $18. Il prezzo di Enterprise è disponibile su richiesta. Il dettaglio di quanto paga effettivamente una famiglia o un piccolo team per Tailscale analizza i casi particolari.

NetBird Cloud è gratuito per un massimo di 5 utenti e 100 macchine. Il piano Team costa €6 per utente al mese, mentre il piano Business costa €12. Il prezzo di Enterprise è disponibile su richiesta. I piani a pagamento includono 100 macchine più 10 macchine per utente; ogni macchina aggiuntiva costa €0.50 al mese. Self-hosted NetBird non prevede costi di licenza. È necessario pagare il VPS e il tempo richiesto per gestirlo.

Scegli Tailscale se...

  • Nessuno del team vuole gestire, aggiornare o sottoporre a backup un server di controllo.
  • Vuoi definire le regole di accesso in un unico file di testo, con test che rilevino le modifiche errate prima dell'applicazione.
  • Gli utenti viaggiano e si connettono da reti alberghiere o mobili. In questi casi, i server DERP di Tailscale distribuiti in molte regioni forniscono un fallback vicino senza configurazione.
  • Il gruppo rientra nel piano gratuito per 6 utenti oppure il prezzo per utente è accettabile.

Scegli NetBird se...

  • Il control plane deve essere eseguito su un'infrastruttura di tua proprietà, usando il progetto ufficiale invece di una reimplementazione separata.
  • Ti servono più di 6 utenti su una rete self-hosted senza costi per utente.
  • Il tuo team preferisce gestire gruppi e policy tramite una dashboard oppure usa già Terraform per tutto il resto.
  • Vuoi iniziare con NetBird Cloud e mantenere la possibilità di trasferire l'installazione su un tuo server, usando lo stesso client.

Cosa manca a ciascuna soluzione

Ogni elemento riportato qui proviene dalla documentazione ufficiale o dalla pagina dei prezzi del fornitore, verificate il 2 ottobre 2026.

A Tailscale manca:

  • Un server di controllo ufficiale self-hosted. Il server di coordinamento è closed source e Headscale è un progetto della community separato.
  • Client grafici open source per Windows e macOS. Il demone sottostante è open source, ma le applicazioni non lo sono.

A NetBird manca:

  • Un sistema integrato di asserzioni per testare le policy di accesso. La documentazione sul controllo degli accessi non ne descrive alcuno, quindi la revisione delle policy dipende da te o dai piani Terraform.
  • Relay gestiti da terzi quando esegui il self-hosting. Il relay viene eseguito sul tuo VPS. Un peer lontano da quel VPS utilizza un percorso inoltrato più lungo e la relativa larghezza di banda è a tuo carico.

Entrambe le soluzioni iniziano con una policy che consente tutto, quindi una nuova rete è completamente aperta finché non scrivi le regole. Per il threat model completo del lato hosted, consulta cosa può e non può vedere un control plane hosted.

FAQ

NetBird è completamente open source?

Sì, ma con due licenze. A ottobre 2026 il README di NetBird indica che il client e la maggior parte del repository sono distribuiti con licenza BSD-3-Clause. Le directory management/, signal/ e relay/ sono soggette alla licenza AGPLv3. Se modifichi questi componenti server e permetti ad altre persone di utilizzarli tramite una rete, la licenza AGPL ti obbliga a offrire loro il codice sorgente modificato.

Posso eseguire in self-hosting il server di controllo di Tailscale come quello di NetBird?

No. Il server di coordinamento di Tailscale è closed source e viene eseguito soltanto come servizio hosted. La sostituzione self-hosted normalmente utilizzata è Headscale, un server di coordinamento open source indipendente che funziona con i client Tailscale ufficiali. Tailscale impiega il principale responsabile della manutenzione di Headscale, ma dichiara di non dirigere il progetto.

Il relay può leggere il mio traffico in NetBird o Tailscale?

No. In entrambi i prodotti, la chiave privata WireGuard viene generata sul dispositivo e non lo lascia mai. Un server Tailscale DERP, un relay peer Tailscale e un relay NetBird inoltrano soltanto pacchetti WireGuard crittografati. Il relay può comunque vedere a quali peer si connette e quanti dati transitano tra loro.

Di quale VPS ho bisogno per eseguire NetBird in self-hosting?

A ottobre 2026, la quickstart ufficiale richiede almeno 1 CPU e 2 GB di memoria. Servono inoltre un dominio pubblico che risolva verso il VPS, Docker con il compose plugin e le porte aperte TCP 80, TCP 443 e UDP 3478. Prevedi anche la larghezza di banda necessaria per il traffico inoltrato. Su un server self-hosted, ogni connessione inoltrata passa attraverso il tuo VPS.

Quale dei due ha il piano gratuito più completo?

A ottobre 2026, Tailscale Personal consente fino a 6 utenti con un numero illimitato di dispositivi per utente. Il piano gratuito NetBird Cloud consente fino a 5 utenti e 100 macchine. Un server NetBird self-hosted non impone limiti al numero di utenti e non richiede un canone di licenza, ma devi pagare il VPS e gestire direttamente il server.