Fino a pochi anni fa, pubblicare un servizio ospitato in una rete aziendale o domestica richiedeva una discreta quantità di lavoro infrastrutturale. Era necessario disporre di un indirizzo IP pubblico (spesso a pagamento), oppure aggirare il problema degli indirizzi dinamici con un servizio DynDNS; configurare il port forwarding sul router; definire regole di NAT e firewall; gestire certificati, autenticazione e aggiornamenti; infine verificare che l’operatore non applicasse NAT a monte, come nel caso del CGNAT. Per l’accesso a più sistemi o a intere sottoreti, la soluzione tipica era una VPN tradizionale, point-to-site o site-to-site, spesso concentrata su un gateway centrale. Un modello efficace, ma non sempre semplice da progettare, mantenere e rendere realmente sicuro.
Negli ultimi anni le mesh VPN hanno cambiato radicalmente questo scenario. Soluzioni come Tailscale e NetBird, insieme a progetti open source come Pangolin e Headscale, automatizzano gran parte delle attività che prima richiedevano competenze specifiche di networking. L’obiettivo non è soltanto “creare una VPN”, ma costruire una rete privata sovrapposta a Internet, cifrata, gestita per identità e capace di collegare dispositivi, server, cloud e reti locali anche quando si trovano dietro NAT o firewall differenti.
In pratica, queste soluzioni superano anche il limite tipico delle connessioni domestiche, come il CGNAT applicato dagli operatori su fibra e 5G, senza dover richiedere, configurare o pagare un indirizzo IP pubblico dedicato.
Il modello tradizionale: funziona, ma richiede molte responsabilità
Aprire una porta sul router è apparentemente semplice, ma trasferisce su chi amministra la rete una serie di responsabilità. Il servizio esposto deve essere aggiornato, correttamente autenticato e monitorato; la superficie di attacco diventa visibile da Internet; eventuali errori di configurazione possono esporre non solo l’applicazione, ma anche altri sistemi raggiungibili dalla stessa rete. A questo si aggiungono problemi pratici: indirizzi IP che cambiano, doppio NAT, connettività mobile, reti alberghiere o aziendali restrittive e impossibilità di intervenire sul router dell’operatore.
Le VPN classiche riducono l’esposizione diretta, ma introducono un punto centrale attraverso cui transitano autenticazione e traffico. Questo gateway deve essere dimensionato, aggiornato, reso disponibile e protetto. In una configurazione hub-and-spoke, inoltre, due dispositivi geograficamente vicini possono comunicare passando da un concentratore lontano, con un impatto su latenza e banda. Anche la gestione delle autorizzazioni tende a essere legata alle sottoreti: una volta entrato nella VPN, l’utente può spesso raggiungere più risorse di quelle strettamente necessarie, salvo aggiungere regole firewall dettagliate.
Che cos’è una mesh VPN
Una mesh VPN crea una rete overlay: ogni dispositivo riceve un indirizzo virtuale stabile e vede gli altri nodi autorizzati come se fossero collegati alla stessa rete privata, indipendentemente dalla loro posizione reale. Un control plane gestisce identità, registrazione dei dispositivi, distribuzione delle chiavi e policy; il traffico applicativo, quando possibile, viaggia invece direttamente tra i peer attraverso tunnel cifrati. Questa separazione tra controllo e dati è uno degli elementi più importanti del modello.
Il collegamento diretto viene ottenuto tramite tecniche di NAT traversal e hole punching. Se i dispositivi non riescono a stabilire una sessione peer-to-peer, la piattaforma può utilizzare un relay. Il relay permette alla comunicazione di avvenire anche in reti molto restrittive, pur introducendo in genere maggiore latenza e minore throughput rispetto a un percorso diretto. Dal punto di vista dell’utente, questa complessità resta quasi sempre nascosta: non occorre conoscere l’IP pubblico del peer, aprire porte in ingresso o riconfigurare la connessione quando il dispositivo passa dal Wi-Fi alla rete mobile.
WireGuard: la base tecnica del cambiamento
Alla base di molte mesh VPN moderne c’è WireGuard, protocollo e software open source progettato per essere semplice, veloce e multipiattaforma. WireGuard utilizza un insieme ristretto di primitive crittografiche moderne. La configurazione fondamentale è basata su coppie di chiavi pubbliche e private: ogni peer conosce la chiave pubblica degli interlocutori autorizzati e associa a ciascuno gli indirizzi che può raggiungere attraverso il tunnel.
WireGuard risolve molto bene il problema del tunnel cifrato, ma volutamente non si occupa di tutto il resto. Non fornisce da solo un catalogo centralizzato dei peer, un sistema di identità, la rotazione automatica delle autorizzazioni, un’interfaccia amministrativa o policy espresse per utenti e gruppi. Le piattaforme mesh costruiscono proprio questo livello sopra WireGuard: trasformano una raccolta di tunnel configurati manualmente in un servizio di connettività amministrabile.
Tailscale: semplicità e integrazione con l’identità
Tailscale è probabilmente l’esempio più noto di mesh VPN basata su WireGuard. Dopo l’installazione del client e l’autenticazione, il dispositivo entra in una rete privata chiamata tailnet. Il control plane raggiungibile dall’interfaccia amministrativa coordina chiavi, indirizzi, individuazione dei peer e policy; il traffico dati prova a seguire un percorso diretto e utilizza relay solo quando necessario. Questa impostazione riduce drasticamente il tempo richiesto per collegare workstation, server, macchine virtuali e dispositivi mobili.
Tra le funzioni più utili ci sono MagicDNS, che consente di raggiungere i nodi per nome; le policy di accesso basate su utenti, gruppi e tag; Tailscale SSH; la condivisione controllata dei dispositivi; e i subnet router, che estendono la tailnet a reti o apparati sui quali non è possibile installare il client. La modalità di default è “split tunneling” ma, se necessario, un nodo può anche funzionare da exit node e instradare verso Internet tutto il traffico di uno o più dispositivi, riproducendo il comportamento di una VPN tradizionale, per esempio su una rete Wi-Fi non fidata. Tailscale Serve e Funnel permettono inoltre di pubblicare servizi rispettivamente all’interno della tailnet o, con le opportune cautele, verso Internet.
NetBird: approccio Zero Trust e possibilità di self-hosting
NetBird propone un modello simile, anch’esso basato su collegamenti WireGuard peer-to-peer, ma pone molta enfasi sul networking Zero Trust e sulla disponibilità di un’implementazione open source self-hosted. La piattaforma integra gestione centralizzata dei peer, SSO e MFA, gruppi, policy granulari, controllo della postura dei dispositivi, route verso reti private, DNS e registrazione delle attività. È disponibile sia come servizio cloud gestito sia come installazione nella propria infrastruttura.
La differenza rispetto a una VPN basata esclusivamente su regole IP è concettuale: l’accesso può essere concesso a una persona o a un gruppo verso una specifica risorsa, subordinandolo anche a requisiti come autenticazione forte o stato del dispositivo (esempio tipico: l’antivirus deve essere aggiornato e il firewall locale abilitato). Questo limita il movimento laterale e rende più leggibile il modello autorizzativo. Il self-hosting offre controllo su piano di gestione e dati operativi, ma richiede capacità di gestione, aggiornamento, backup, monitoraggio e disponibilità del servizio: non è quindi automaticamente più semplice o più sicuro del cloud.
Pangolin: tra VPN e reverse proxy
Pangolin, un ottimo progetto open source, affronta il problema da una prospettiva leggermente diversa, combinando le funzioni di una VPN con quelle di un reverse proxy identity-aware. È una piattaforma basata su WireGuard, Traefik e Gerbil che collega reti remote mediante connettori leggeri e tunnel in uscita: le risorse interne possono quindi restare dietro firewall e NAT senza richiedere porte aperte in ingresso. L’amministratore pubblica risorse specifiche, anziché concedere automaticamente visibilità di un’intera rete. Anche in questo caso, come per Tailscale e NetBird, WireGuard resta il motore dei tunnel cifrati sotto il cofano, mentre la piattaforma costruisce sopra di esso orchestrazione, identità e controllo degli accessi.
Le applicazioni web possono essere raggiunte dal browser e protette tramite autenticazione, SSO, MFA e regole per identità o ruolo. Per risorse private come database, host SSH o intere reti è invece possibile utilizzare un client. Pangolin è interessante quando l’esigenza principale è esporre in modo controllato singole applicazioni, pannelli amministrativi o servizi tecnici, mantenendo un unico livello di gestione degli accessi. È però importante distinguere tra accesso privato e pubblicazione su Internet: anche se protetto da un proxy con autenticazione, un servizio pubblico continua ad avere una superficie esposta e va aggiornato e monitorato.
Headscale: un control plane di Tailscale self-hosted
Qualora non si voglia o non si possa, per policy, appoggiarsi a un provider cloud per l’implementazione di una mesh VPN, ci si può appoggiare a Headscale: un’implementazione open source e self-hosted del control server compatibile con i client Tailscale. Consente di gestire in proprio registrazione dei nodi, assegnazione degli indirizzi, MagicDNS, route, subnet router, exit node, ACL, autenticazione OIDC e relay. Il progetto dichiara però un perimetro più ristretto, orientato soprattutto a una singola tailnet, al self-hosting, ai laboratori e alle piccole organizzazioni.
Headscale è quindi adatto a chi apprezza l’esperienza dei client Tailscale ma vuole mantenere il control plane nella propria infrastruttura. In cambio dell’autonomia, occorre accettare l’onere operativo e una possibile differenza di copertura rispetto al servizio commerciale: prima di adottarlo è opportuno verificare la compatibilità delle funzioni indispensabili, il processo di aggiornamento e la gestione dei relay.
Cloudflare Zero Trust e Tunnel: pubblicare applicazioni senza esporre l’origine
Cloudflare Zero Trust affronta la pubblicazione delle applicazioni con un modello diverso da quello di una mesh VPN peer-to-peer. Installando il demone leggero cloudflared su un server, una macchina virtuale o un container della rete interna, si crea un Cloudflare Tunnel persistente verso la rete globale di Cloudflare. La connessione viene iniziata esclusivamente dall’interno verso l’esterno: non serve un indirizzo IP pubblico, non occorre aprire porte in ingresso e l’indirizzo dell’origine può rimanere nascosto. Il tunnel collega quindi un hostname pubblico, per esempio app.example.com, a un servizio interno come http://nas.lan:8080 o a un altro indirizzo della LAN; Cloudflare gestisce poi il certificato TLS sul proprio edge, rendendo l’applicazione raggiungibile in HTTPS senza esporre direttamente il server di origine.
L’integrazione con il DNS di Cloudflare rende la configurazione particolarmente lineare: aggiungendo una route per un’applicazione, la piattaforma può creare automaticamente il record DNS che punta al tunnel. Le richieste raggiungono prima la rete Cloudflare e vengono poi inoltrate all’origine attraverso la connessione cifrata. Per le applicazioni web si possono così utilizzare anche i servizi applicativi della piattaforma, compresi caching CDN, protezione DDoS e, secondo il piano e la configurazione adottati, WAF e ulteriori controlli di sicurezza. Il caching è particolarmente utile per contenuti statici, immagini e file distribuibili dalla CDN; per pannelli dinamici, API o applicazioni autenticate deve invece essere configurato con attenzione, escludendo dal caching dati personali e risposte specifiche della sessione.
Cloudflare Access permette inoltre di anteporre all’applicazione un livello di autenticazione Zero Trust basato sull’identità, con policy che possono limitare l’accesso a determinati utenti, gruppi, domini e condizioni. Questo rende il modello adatto sia alla pubblicazione di un sito destinato a Internet sia alla protezione di dashboard, strumenti amministrativi e applicazioni private raggiungibili dal browser. Non è però una mesh VPN nel senso stretto del termine: il traffico passa attraverso l’infrastruttura Cloudflare e il valore principale risiede nella combinazione tra connettività dell’origine, DNS, reverse proxy, sicurezza applicativa e distribuzione CDN.
Un ulteriore punto di forza è il piano gratuito di Cloudflare Zero Trust, disponibile senza scadenza e pensato per team fino a 50 utenti. Cloudflare Tunnel è disponibile senza costi anche per la pubblicazione delle applicazioni; le postazioni conteggiate diventano rilevanti quando si applicano policy di Access che richiedono l’autenticazione degli utenti. Per dimensioni, funzioni incluse e assenza di una spesa iniziale, il piano gratuito consente di valutare concretamente la tecnologia ed è sufficiente per quasi tutti gli homelab. Restano comunque da verificare i limiti correnti, la retention dei log, il supporto e le funzioni riservate ai piani a pagamento prima di estendere l’uso a servizi aziendali o critici.
Sicurezza: meno esposizione non significa assenza di rischio
Il vantaggio immediato di queste soluzioni è la possibilità di evitare porte aperte in ingresso e ridurre l’esposizione di servizi amministrativi, NAS, hypervisor, telecamere, ambienti di sviluppo o applicazioni interne. La cifratura è però solo una parte del problema. La sicurezza dipende anche dall’identità utilizzata per accedere, dalla protezione dell’account, dalla revoca tempestiva dei dispositivi, dalla qualità delle policy e dall’aggiornamento degli endpoint. Una mesh configurata con una policy “tutti verso tutto” può risultare comoda, ma riproduce una rete piatta e facilita il movimento laterale in caso di compromissione.
La buona pratica è applicare il principio del minimo privilegio: separare utenti, amministratori, server e dispositivi personali; usare gruppi e tag con criteri chiari; abilitare MFA; preferire chiavi o registrazioni a durata limitata per l’automazione; controllare i log; rimuovere i nodi non più usati; e distinguere le risorse che devono essere raggiungibili solo dalla rete privata da quelle realmente destinate al pubblico. In un contesto aziendale vanno considerati anche disponibilità del control plane, residenza dei dati, integrazione con l’identity provider, gestione degli incidenti e procedure di emergenza.
Come scegliere tra le diverse soluzioni
- Tailscale è adatto quando la priorità è iniziare rapidamente, con client maturi, gestione semplificata, buone integrazioni con l’identità e numerose funzioni già pronte.
- NetBird è interessante per chi cerca una piattaforma Zero Trust open source, disponibile sia gestita sia self-hosted, con policy granulari e un’impostazione adatta anche a team e infrastrutture distribuite.
- Pangolin è particolarmente indicato quando occorre combinare accesso privato e pubblicazione controllata di specifiche applicazioni, anche via browser, senza esporre direttamente la rete di origine.
- Headscale è una scelta sensata per laboratori, homelab e organizzazioni contenute che vogliono utilizzare i client Tailscale mantenendo in proprio il piano di controllo.
- Cloudflare Zero Trust e Tunnel sono indicati quando la priorità è pubblicare applicazioni web attraverso hostname gestiti nel DNS Cloudflare, nascondere l’origine e sfruttare reverse proxy, autenticazione Zero Trust, protezioni applicative e caching CDN. Il piano gratuito li rende particolarmente interessanti per homelab e valutazioni senza investimento iniziale.
- WireGuard puro resta valido quando la topologia è piccola e stabile, i peer sono pochi e si desidera il massimo controllo senza introdurre un ulteriore livello di gestione.
La scelta non dovrebbe basarsi soltanto sul fatto che il prodotto sia gratuito o open source. Bisogna valutare numero e tipo di utenti, sistemi operativi supportati, necessità di accesso da browser, integrazione con SSO e MFA, granularità delle policy, audit, prestazioni attraverso relay, esigenza di collegare intere sottoreti e capacità interna di gestire un’installazione self-hosted. Occorre inoltre verificare licenze, limiti dei piani e disponibilità delle singole funzioni nella versione effettivamente adottata, perché possono cambiare nel tempo.
La mia esperienza
Nel mio homelab questo modello non è rimasto teorico. Su quattro nodi Proxmox ospito circa quaranta container LXC e pubblico decine di applicazioni: alcune tramite Cloudflare Tunnel, quando devono essere accessibili anche dall’esterno via browser; altre tramite Pangolin, quando voglio mantenere un accesso più selettivo. Tailscale è diventato invece lo strumento quotidiano per entrare nella mia rete da fuori senza doverci pensare. Pur avendo un indirizzo IP pubblico statico (grazie Fastweb), ho smesso di esporre servizi tramite port forwarding sul router. NetBird, Headscale e le altre soluzioni sono comunque interessanti, ma per il mio homelab domestico, anche se articolato, le ritengo sovradimensionate rispetto al problema da risolvere.
Confronto sintetico
| Soluzione | Tipo / architettura | Gestione | Target / caso d’uso principale |
| Tailscale | Mesh VPN basata su WireGuard | Control plane SaaS | Attivazione immediata, minima configurazione e reti personali o aziendali distribuite. |
| NetBird | Mesh VPN Zero Trust basata su WireGuard | Cloud gestito o self-hosted | Policy granulari, posture check e alternativa open source con controllo dell’infrastruttura. |
| Headscale | Control plane self-hosted per la mesh Tailscale | Self-hosted; client Tailscale | Homelab e piccole organizzazioni che apprezzano i client Tailscale ma vogliono gestire direttamente piano di controllo e metadati. |
| Pangolin | Reverse proxy identity-aware + VPN basata su WireGuard | Cloud o self-hosted | Esposizione controllata di applicazioni web, pannelli interni e risorse private senza porte aperte sulla rete di origine. |
| Cloudflare Zero Trust | Edge tunnel e identity-aware proxy | Servizio cloud con connettore locale | Pubblicazione di servizi web tramite browser, con origine nascosta e integrazione con CDN, protezione DDoS e WAF. |
| WireGuard puro | Tunnel peer-to-peer o hub-and-spoke | Interamente self-managed | Topologie semplici e stabili nelle quali si vuole controllo totale senza un livello aggiuntivo di orchestrazione. |
Conclusioni
Le mesh VPN non eliminano il networking: ne automatizzano le parti più ripetitive e spostano l’attenzione dagli indirizzi IP alle identità e alle risorse. Per un homelab possono significare raggiungere NAS e server senza aprire porte; per un’azienda, collegare utenti, sedi e workload cloud con policy uniformi e minore dipendenza da concentratori centrali. Il risultato è una connettività più semplice da distribuire e, se amministrata correttamente, più coerente con i principi Zero Trust.
La vera rivoluzione non è quindi una singola tecnologia, ma il cambio di modello: invece di pubblicare una rete e difenderne il perimetro, si autorizzano connessioni precise tra identità, dispositivi e servizi. WireGuard fornisce il tunnel peer-to-peer; Tailscale, NetBird, Pangolin e Headscale aggiungono livelli diversi di orchestrazione, controllo e usabilità; Cloudflare Zero Trust associa invece tunnel in uscita, identità, DNS, reverse proxy e CDN per pubblicare applicazioni mantenendo nascosta l’origine. Scegliere bene significa partire dal caso d’uso, definire il perimetro di accesso e adottare la soluzione che riduce la complessità senza trasferirla semplicemente altrove.
Questo post non è sponsorizzato: ho provato personalmente tutti i prodotti citati e le opinioni sono le mie.