WireGuard Mesh Networking: costruire una rete Zero-Trust tra server e NAS con Tailscale e Netmaker

Guida pratica per creare una rete mesh Zero-Trust tra server remoti e un NAS usando WireGuard, con due percorsi concreti: Tailscale (SaaS) e Netmaker (self-hosted).

Nov 6, 2026 0 1

WireGuard Mesh Networking: costruire una rete Zero-Trust tra server e NAS con Tailscale e Netmaker

Finché si tratta di collegare due server, una VPN punto a punto basata su WireGuard si configura in pochi minuti. Il problema arriva quando i nodi da collegare diventano cinque, dieci, venti: server cloud sparsi su provider diversi, un NAS in sede, qualche Raspberry Pi e i laptop del team. Configurare a mano ogni singola coppia di peer diventa presto un incubo di chiavi pubbliche, indirizzi IP e file di configurazione da aggiornare manualmente a ogni modifica.

È qui che entra in gioco il concetto di mesh networking: una rete in cui ogni dispositivo può parlare direttamente con ogni altro dispositivo autorizzato, senza passare da un singolo punto centrale, e in cui l'accesso non dipende dal "trovarsi dentro il perimetro aziendale" ma da regole esplicite verificate per ogni connessione. Questo secondo principio ha un nome: Zero Trust. In questa guida vediamo come costruire concretamente una mesh Zero-Trust tra server remoti e un NAS, usando WireGuard come base crittografica e due strumenti che lo orchestrano in modo molto diverso tra loro: Tailscale (servizio SaaS) e Netmaker (self-hosted).

WireGuard in breve: perché è diventato lo standard

WireGuard è un protocollo VPN moderno, pensato per essere semplice da verificare (il suo codice sorgente è ordini di grandezza più piccolo di OpenVPN o IPsec) e veloce, perché gira direttamente nel kernel Linux dalla versione 5.6 in poi. Usa algoritmi di crittografia moderni come Curve25519 per lo scambio delle chiavi e ChaCha20 per la cifratura del traffico, e identifica ogni dispositivo tramite una coppia di chiavi pubblica/privata invece che con nomi utente e password.

Il limite di WireGuard "puro" non è la sicurezza, ma l'organizzazione: di default è pensato per collegamenti punto a punto. Per creare una mesh con molti nodi bisogna generare e distribuire manualmente le chiavi di ogni peer su tutti gli altri, aggiornare gli indirizzi AllowedIPs a ogni variazione e tenere traccia di tutto a mano. È un lavoro che si può automatizzare, e infatti è esattamente quello che fanno Tailscale e Netmaker: entrambi usano il protocollo WireGuard sotto il cofano, ma aggiungono un livello di orchestrazione automatica (distribuzione delle chiavi, scoperta dei peer, regole di accesso) che lo rende gestibile anche con decine di nodi.

Il principio Zero Trust applicato alla rete

Il modello di sicurezza di rete tradizionale si basa su un perimetro: se un dispositivo è "dentro" (in ufficio, sulla VPN aziendale), si fida di lui quasi completamente. Il problema è che un perimetro, una volta superato - una credenziale rubata, un laptop compromesso - lascia campo libero a un attaccante per muoversi lateralmente tra i sistemi.

Il principio Zero Trust rovescia l'approccio: nessun dispositivo o utente è considerato automaticamente affidabile, nemmeno quelli già "dentro" la rete. Ogni connessione viene autenticata e autorizzata singolarmente, con il principio del minimo privilegio: un server di backup deve poter raggiungere solo il NAS su cui scrive, non anche il database di produzione o la postazione dell'amministratore. Applicato a una mesh WireGuard, questo si traduce in pratica in due cose: identità forte per ogni nodo (la chiave pubblica WireGuard, univoca per dispositivo) e un sistema di regole (ACL, access control list) che decide esplicitamente chi può parlare con chi, invece di lasciare che "chiunque sia in rete" raggiunga tutto.

Tailscale e Netmaker: due filosofie diverse

Sia Tailscale che Netmaker costruiscono una mesh WireGuard automatizzata, ma partono da presupposti opposti. Tailscale è un servizio SaaS: il piano di controllo (autenticazione, distribuzione delle chiavi, interfaccia di gestione) è gestito dai server di Tailscale, mentre il traffico tra i dispositivi viaggia direttamente peer-to-peer quando possibile. Netmaker invece è pensato per essere self-hosted: si installa il control plane (community edition, gratuita e open source) sul proprio server, e si resta proprietari dell'intera infrastruttura, dati compresi.

Questa differenza si riflette anche sui prezzi. Tailscale ha un piano "Personal" gratuito per uso non commerciale, fino a 6 utenti con dispositivi illimitati; i piani per team partono da 8 dollari per utente al mese (piano Standard), fino ai 18 dollari del piano Premium pensato per aziende più grandi. Netmaker offre invece una Community Edition gratuita e open source senza limiti dichiarati di dispositivi o reti, con piani a pagamento (Team e Business) calcolati sulle connessioni attive, a partire da circa 2 dollari per connessione al mese, pensati per chi vuole funzionalità aggiuntive come il failover automatico o la gestione utenti avanzata.

In termini pratici: se si vuole iniziare subito senza gestire un server aggiuntivo, e si è a proprio agio nell'affidare il piano di controllo a un fornitore esterno, Tailscale è la scelta più rapida. Se invece la priorità è tenere tutta l'infrastruttura (incluso il server che decide "chi parla con chi") sotto il proprio controllo, Netmaker è l'opzione da considerare, al costo di dover gestire un server in più.

Prima strada: una mesh Zero-Trust con Tailscale

Tailscale si installa su ogni dispositivo che deve far parte della rete (server, laptop, Raspberry Pi) con un client leggero. Una volta autenticati, i dispositivi ottengono un indirizzo IP virtuale stabile nell'intervallo privato 100.64.0.0/10 (lo stesso intervallo usato per il CGNAT) e possono raggiungersi tra loro.

Esporre un NAS senza installare nulla sul NAS

Molti NAS non supportano l'installazione diretta di un client Tailscale, o lo si preferisce evitare per non toccare il sistema del produttore. La soluzione è il pattern del subnet router: si installa Tailscale su un dispositivo sempre acceso sulla stessa rete locale del NAS (ad esempio un piccolo server Linux o un Raspberry Pi), e si fa da "ponte" per esporre l'intera sottorete alla mesh, senza che il NAS stesso debba sapere nulla di WireGuard o Tailscale.

Sul dispositivo-ponte, dopo aver abilitato l'IP forwarding a livello di sistema, si avvia il client con:

tailscale up --advertise-routes=192.168.1.0/24

dove 192.168.1.0/24 è la sottorete locale su cui si trova il NAS. Da sola, questa operazione non basta: la rotta annunciata deve essere approvata da un amministratore nella console web di gestione (sezione "Machines", dispositivo con il badge "Subnets"), a meno che non sia già coperta da una regola autoApprovers nel file di policy. Solo a quel punto gli altri nodi della mesh, se abilitati ad accettare le rotte con tailscale set --accept-routes (comportamento automatico su macOS, iOS, Android e Windows), possono raggiungere il NAS al suo indirizzo IP locale originale, come se fossero sulla stessa LAN.

Scrivere le regole di accesso (ACL/grants)

Di default, un nuovo "tailnet" (così si chiama la rete privata di Tailscale) permette a tutti i dispositivi di raggiungersi a vicenda: tutto tranne le regole esplicite è permesso. Per applicare davvero il principio Zero Trust occorre invertire questa logica, rimuovendo la regola permissiva di default e scrivendo solo i permessi necessari nel file di policy, in formato JSON. La sintassi moderna si chiama grants (preferita alla più vecchia acls, anche se possono coesistere) e ogni regola specifica sorgente, destinazione e porte consentite:

{
  "hosts": {
    "backup-server": "100.64.0.10",
    "nas": "100.64.0.20"
  },
  "grants": [
    {
      "src": ["backup-server"],
      "dst": ["nas"],
      "ip": ["tcp:445", "tcp:22"]
    }
  ]
}

In questo esempio solo il server di backup può raggiungere il NAS, e solo sulle porte SMB (445) e SSH (22): nessun altro dispositivo della mesh, nemmeno chi ha accesso completo ad altri sistemi, può toccarlo. Per organizzare i permessi su più dispositivi si possono usare i tag, assegnati nella sezione tagOwners della policy: un tag sposta la "proprietà" del dispositivo da un singolo account umano al tag stesso, così l'accesso non dipende da chi ha fatto originariamente il login su quella macchina. Da notare un dettaglio pratico non banale: rimuovere un tag da un dispositivo non è semplice, spesso richiede di rimuoverlo dalla rete e registrarlo di nuovo da zero, quindi vale la pena pianificare lo schema dei tag con attenzione prima di metterlo in produzione.

Accesso SSH senza chiavi da gestire

Un vantaggio pratico di appoggiarsi all'identità Tailscale per l'intera rete è poter abilitare l'accesso SSH "keyless": attivandolo su un server con tailscale set --ssh, l'autenticazione SSH si basa sull'identità del tailnet invece che su chiavi da generare, distribuire e revocare manualmente. Le regole su chi può accedere via SSH, e con quale utente di sistema, si definiscono in un blocco separato della policy:

{
  "ssh": [
    {
      "action": "check",
      "src": ["group:sysadmin"],
      "dst": ["tag:server"],
      "users": ["deploy"]
    }
  ]
}

Con "action": "check" l'accesso richiede una riautenticazione periodica (l'intervallo si imposta con checkPeriod), utile sui server più sensibili; con "action": "accept" l'accesso è immediato una volta verificata l'identità. In entrambi i casi, resta comunque necessario che la configurazione SSH del sistema operativo autorizzi quell'utente specifico.

Due avvertenze pratiche prima di andare in produzione: le chiavi dei nodi scadono per default dopo 180 giorni, il che può disconnettere silenziosamente un subnet router o un exit node se non si disabilita la scadenza sui dispositivi che fanno da infrastruttura permanente; e le modifiche alla policy sono effettive immediatamente al salvataggio, quindi una regola troppo restrittiva può interrompere la sessione SSH con cui si sta lavorando - conviene sempre rivedere il diff delle modifiche prima di confermarle.

Seconda strada: una mesh self-hosted con Netmaker

Se la priorità è mantenere il controllo completo dell'infrastruttura, Netmaker Community Edition permette di installare il proprio piano di controllo su un server, senza dipendere da un fornitore esterno per decidere chi può accedere a cosa.

Requisiti e installazione

Per la Community Edition, Netmaker richiede un server Ubuntu 24.04 (può essere una VM, un bare metal o anche la stessa macchina su cui girano gli altri servizi), con un minimo di 1 GB di RAM, 1 CPU e 2 GB di storage per i test, ma almeno 2 GB di RAM e 2 CPU per un uso in produzione. Sono necessari un indirizzo IP pubblico statico e, idealmente, un nome di dominio con accesso alla gestione DNS, perché il pannello, l'API, il broker MQTT e gli strumenti di monitoraggio (Prometheus, Grafana) hanno ciascuno bisogno di un proprio sottodominio pubblico (o di un wildcard come *.netmaker.esempio.it). Vanno aperte le porte 80/TCP e 443/TCP per i certificati e l'interfaccia web, e la porta 51821/UDP per il traffico WireGuard dell'agente.

L'installazione guidata della Community Edition si riduce a scaricare ed eseguire lo script ufficiale dal repository GitHub di Netmaker:

curl -sfL https://raw.githubusercontent.com/gravitl/netmaker/master/scripts/nm-quick.sh -o /root/nm-quick.sh
chmod +x /root/nm-quick.sh
sudo /root/nm-quick.sh

Lo script configura automaticamente i certificati TLS (tramite Caddy), il broker MQTT usato per la comunicazione con i client e il pannello di amministrazione. Un avvertimento utile per chi usa Cloudflare come proxy DNS: va disabilitato il proxying ("nuvoletta grigia" invece che arancione) sui record usati da Netmaker, perché altrimenti il traffico MQTT viene bloccato in un modo che Netmaker stesso non è in grado di diagnosticare.

Creare la rete e aggiungere i nodi

Al primo accesso al pannello si crea un account amministratore, poi si crea una nuova rete scegliendo un intervallo di indirizzi privati non sovrapposto ad altre reti già in uso (per reti sotto le 254 macchine, un blocco come 10.11.12.0/24 è più che sufficiente). Il server Netmaker si aggiunge automaticamente alla rete come primo nodo.

Per aggiungere un server remoto o il dispositivo-ponte verso il NAS, si genera dal pannello una enrollment key (sezione "Keys"), impostando quante volte può essere usata e su quali reti dà accesso. Sul nuovo host, dopo aver verificato che WireGuard e systemd siano installati, si installa il netclient per il proprio sistema operativo e si registra il nodo con:

netclient register -k  -s grpc.miodominio.it -p 50051

Qualche istante dopo il nodo compare nel pannello di amministrazione, e si può verificarne la connettività facendo un semplice ping al suo indirizzo privato dalla rete mesh da un altro nodo già collegato. Per i nodi aggiunti successivamente alla stessa rete già esistente, si può usare in alternativa un registration token dedicato invece dell'enrollment key, pensato apposta per quel caso.

Netmaker gestisce la sicurezza della mesh tramite ACL a livello di rete (quali nodi possono parlare tra loro all'interno della stessa rete virtuale) e tag assegnabili alle chiavi di enrollment, un meccanismo diverso ma concettualmente affine alle grants di Tailscale: anche qui, l'obiettivo è evitare che "fare parte della mesh" equivalga automaticamente ad "avere accesso a tutto".

Buone pratiche di sicurezza, qualunque strumento si scelga

Indipendentemente dalla strada scelta, alcune accortezze valgono per entrambe. Primo: disabilitare la scadenza automatica delle chiavi sui dispositivi che svolgono un ruolo infrastrutturale permanente, come il subnet router che espone il NAS o il server Netmaker stesso - una chiave scaduta senza preavviso su un nodo critico significa un'interruzione di servizio silenziosa. Secondo: applicare sempre il principio del minimo privilegio quando si scrivono le regole di accesso, concedendo a ogni nodo solo le porte e i peer di cui ha effettivamente bisogno, e non "tutto quello che serve più qualcosa in più per sicurezza" - è esattamente l'opposto dello spirito Zero Trust. Terzo: tenere aggiornati sia il client WireGuard sottostante sia il software di orchestrazione (Tailscale o il netclient di Netmaker), perché entrambi ricevono periodicamente correzioni di sicurezza. Quarto, e spesso sottovalutato: testare le regole di accesso prima di affidarvisi in produzione, verificando non solo che le connessioni autorizzate funzionino, ma anche che quelle non autorizzate siano effettivamente bloccate.

Quale scegliere?

Non esiste una risposta universale, ma qualche indicazione pratica. Per un homelab, un piccolo team o chi vuole iniziare subito senza amministrare un server aggiuntivo, Tailscale offre il percorso più rapido, un piano gratuito generoso per uso personale e una gestione delle policy comunque abbastanza granulare da implementare un vero modello Zero Trust. Per chi gestisce già un'infrastruttura server propria, ha requisiti di compliance che richiedono di mantenere i dati e il piano di controllo in sede, o preferisce non dipendere da un fornitore SaaS esterno per una componente critica come l'accesso alla rete, Netmaker Community Edition offre le stesse garanzie di sicurezza basate su WireGuard, al prezzo di un server in più da amministrare e aggiornare. In entrambi i casi, il risultato finale è lo stesso: una mesh cifrata, performante perché basata su WireGuard, e progettata secondo il principio per cui nessuna connessione viene concessa per default, ma solo perché esplicitamente autorizzata.