Collegare le sedi: VPN, Tailscale, NetBird o Cloudflare Mesh?

Mi occupo molto del collegamento tra reti aziendali. Le domande ricorrenti sono sempre simili: qual è la soluzione migliore per collegare le nostre sedi? Servono indirizzi IP pubblici? Quanto è sicura? E andrà ancora bene aggiungendo una filiale, cambiando connessione Internet o assumendo altre persone?

La risposta dipende dalle esigenze concrete dell’azienda. Due sedi fisse con firewall già presenti hanno condizioni diverse da varie piccole filiali con connessioni variabili. Oltre al tunnel bisogna capire chi lo gestisce, dove vengono controllati gli accessi e quali dipendenze l’azienda accetta di mantenere.

Preferisco quindi comprendere l’architettura prima di scegliere un prodotto. Una VPN site-to-site classica può essere adatta. Tailscale o NetBird possono semplificare gestione e connessione. Cloudflare Mesh sposta il percorso dei dati nella rete del fornitore. Queste differenze determinano dove ciascun approccio abbia senso per me.

Qui parlo del collegamento di intere reti di sede. L’accesso dei singoli dipendenti da casa viene trattato separatamente come possibilità aggiuntiva di accesso remoto.

Il nostro esempio: Tre reti di sede collegate

La sede centrale usa 10.1.0.0/24, la filiale 10.2.0.0/24 e il laboratorio domestico 10.3.0.0/24. Ogni sede dispone di un gateway che rende raggiungibili le reti remote. Stampanti e NAS dietro di esso non necessitano di un client VPN. Tutti i modelli hanno lo stesso obiettivo: collegare in modo controllato queste tre reti.

Si ottiene una rete instradata di livello 3. Le sedi non condividono automaticamente il dominio broadcast e non tutti i protocolli di individuazione locale funzionano tra le sedi. Il DNS deve risolvere correttamente i nomi interni e i router locali devono conoscere le rotte verso le reti remote.

Prima voglio capire quali servizi servano a ciascuna rete. La filiale può richiedere il file server senza accedere all’amministrazione del laboratorio. Il server di backup deve raggiungere la destinazione, non tutti i dispositivi dell’altra sede. Queste decisioni restano necessarie con qualsiasi soluzione.

Site-to-site descrive il collegamento, non la topologia

Site-to-site significa rete a rete. Non impone di attraversare sempre un firewall centrale. La topologia hub-and-spoke attraverso la sede principale è comune; anche tunnel diretti tra coppie di sedi sono collegamenti site-to-site. I gateway di Tailscale, NetBird e Cloudflare Mesh possono svolgere la stessa funzione.

Tailscale e NetBird cercano percorsi dati diretti anche quando registrazione e coordinamento sono centralizzati. La rete Cloudflare è distribuita geograficamente, ma il traffico tra sedi continua ad attraversarla. Non si tratta di un collegamento peer-to-peer diretto. La rete del fornitore sostituisce il firewall centrale come punto di transito.

IP pubblici e requisiti che cambiano

La domanda sull’IP pubblico arriva presto. Distinguo la raggiungibilità dall’esterno dalla stabilità dell’indirizzo. Un IP pubblico fisso facilita la pianificazione di un endpoint VPN raggiungibile. Non serve però in ogni sede. Una filiale può aprire un tunnel in uscita verso un gateway centrale raggiungibile; secondo la configurazione, il DNS dinamico aiuta con gli indirizzi variabili.

Diventa più difficile se entrambi i lati sono dietro un carrier-grade NAT restrittivo senza endpoint direttamente raggiungibile. Soprattutto sulle connessioni mobili bisogna verificare indirizzi e connessioni in entrata realmente offerti dall’operatore. Tailscale e NetBird tentano collegamenti diretti attraverso il NAT e ricorrono ai relay se necessario. Cloudflare Mesh apre invece connessioni in uscita verso la rete del fornitore.

Voglio anche che il cambiamento successivo resti gestibile. Una sede aggiuntiva, un altro operatore o un collegamento senza raggiungibilità in entrata possono trasformare una piccola configurazione in un problema diverso. Non occorre sostituire preventivamente una soluzione funzionante, ma conviene considerare queste possibilità prima di fissare la topologia.

VPN site-to-site classica: Se ne occupano i gateway

Due firewall o router stabiliscono un tunnel cifrato, spesso con IPsec o WireGuard configurato manualmente. Il routing locale manda nel tunnel i pacchetti per la rete remota. L’altro gateway li decifra e li inoltra nella rete di destinazione.

Con tre sedi la centrale può essere l’hub. Filiale e laboratorio vi si collegano. La struttura si semplifica, ma i loro scambi passano dalla centrale. Un full mesh collega direttamente ogni coppia. Con n sedi servono n × (n − 1) / 2 collegamenti: tre con tre sedi, già 45 con dieci. Controller e meccanismi dinamici riducono il lavoro; le VPN tradizionali non sono limitate alle stelle configurate manualmente.

Vantaggi: si integra con firewall esistenti e confini di sede chiari. Gli endpoint sono sotto il proprio controllo. Non c’è un ulteriore fornitore mesh nel percorso dati; regole, rotte e log possono rientrare nell’amministrazione esistente.

Svantaggi: routing, chiavi e gestione richiedono più lavoro al crescere delle sedi. NAT, indirizzi variabili e produttori diversi complicano la diagnosi. Gli utenti mobili richiedono spesso un accesso remoto separato.

L’IP pubblico fisso in ogni sede non è un requisito universale. Spesso bastano un hub raggiungibile e tunnel in uscita dalle filiali. DNS dinamico e attraversamento NAT possono aiutare. Con CGNAT restrittivo a entrambi i lati, però, un collegamento diretto è più difficile senza endpoint raggiungibile o intermediario.

Per due sedi stabili con firewall adatti resta una scelta ragionevole. Non sostituirei una VPN funzionante soltanto perché un altro prodotto mostra meno campi di configurazione.

Tailscale: Collegamenti diretti e coordinamento centrale

Tailscale aggiunge a WireGuard registrazione dei dispositivi, coordinamento e politiche di accesso. Il servizio di controllo aiuta i partecipanti a trovarsi. I dati passano direttamente tra peer quando possibile. Se NAT o firewall lo impediscono, un relay offre un’alternativa. Anche passando da DERP, i dati restano cifrati tra i peer Tailscale.

I subnet router collegano intere LAN al tailnet. Lo scenario site-to-site documentato da Tailscale usa Linux a entrambe le estremità. I dispositivi a valle non richiedono agenti ma necessitano di rotte corrette. Disabilitare il NAT sorgente per conservare gli indirizzi originali rende particolarmente importante pianificare il ritorno.

Vantaggi: i dispositivi LAN esistenti partecipano tramite subnet router. I collegamenti diretti evitano il passaggio obbligato dalla sede centrale. La stessa piattaforma permette di aggiungere singoli dispositivi utente.

Svantaggi: il percorso diretto non è garantito. Un relay può modificare latenza e velocità. Il coordinamento ospitato resta una dipendenza operativa; piano e funzioni devono adattarsi all’installazione.

La cifratura WireGuard termina sul peer. Se è un subnet router, il segmento LAN successivo è fuori dal tunnel. HTTPS e SSH restano quindi utili nella rete privata.

NetBird: Mesh simile, con possibilità di gestione propria

Anche NetBird usa WireGuard, cerca collegamenti diretti e ricorre ai relay quando necessario. I routing peer collegano reti i cui dispositivi non eseguono il client. La guida site-to-site attuale descrive Networks, Resources e relative politiche di accesso.

Vantaggi: il progetto open source offre un’alternativa autogestita al servizio cloud. Conta quando infrastruttura e amministrazione devono restare sotto la propria responsabilità. Gruppi e politiche permettono di restringere gli accessi.

Svantaggi: gestirlo significa curare aggiornamenti, backup, monitoraggio e disponibilità di coordinamento e relay. Un’installazione rapida non elimina questi compiti. La configurazione site-to-site documentata con Networks mantiene il masquerading attivo, quindi il destinatario non vede semplicemente l’indirizzo originale. Altre varianti di routing richiedono una pianificazione distinta.

Tailscale e NetBird sono parenti stretti, ma le configurazioni non sono intercambiabili. Li valuterei rispetto al routing e al modello d’identità necessari. Open source non significa neppure che tutte le funzioni siano utilizzabili senza limiti: vanno controllate licenze e funzioni richieste dal progetto.

Cloudflare Mesh: Il percorso passa nella rete del fornitore

I partecipanti aprono connessioni in uscita verso Cloudflare. Il traffico tra sedi attraversa la sua rete. Non occorre collegare direttamente ogni sede a tutte le altre né gestire un hub VPN proprio. Il confine di fiducia e il percorso restano diversi da un mesh WireGuard diretto.

Vantaggi: unisce connettività e politiche Gateway centrali. Può essere particolarmente adatto dove Cloudflare One è già presente. Sedi dietro NAT e client mobili si collegano tramite connessioni in uscita.

Svantaggi: funzionamento e percorso dipendono dal fornitore. Il trattamento dei dati deve soddisfare requisiti di fiducia e riservatezza. TLS e SSH restano utili per l’applicazione. Per capire se il percorso avvantaggia una specifica applicazione occorre misurare; un backbone globale non garantisce migliori prestazioni ovunque.

Per una nuova installazione seguirei il client attualmente documentato. Cloudflare indica Mesh come beta e richiede MASQUE nel profilo dei nodi. Con WireGuard documenta limitazioni per alta disponibilità e rotte IPv6 e per hostname. Il supporto WireGuard di un router non basta quindi a considerarlo un nodo Mesh equivalente.

Mesh va distinto anche da un tunnel cloudflared per singole applicazioni. Qui si tratta di connettività IP privata bidirezionale tra partecipanti e reti instradate.

Le differenze a colpo d’occhio

Sono queste le differenze che valuto prima. Abbonamento e percorso effettivo vanno verificati nell’ambiente concreto.

Cosa mi aspetto da un collegamento sicuro

Quando mi chiedono quale soluzione sia più sicura, guardo prima connessioni consentite e gestione degli accessi. Un tunnel cifrato può autorizzare troppo. Voglio definire quali reti raggiungano quali servizi, come proteggere gli amministratori e come revocare gli accessi. MFA per amministrazione e utenti registrati personalmente, permessi limitati e gateway mantenuti fanno parte della valutazione.

Cambiano anche i confini della cifratura. La VPN classica termina ai gateway; Tailscale e NetBird cifrano tra peer, che possono essere subnet router. La LAN successiva non è automaticamente cifrata. Con Cloudflare anche il trattamento nella rete del fornitore deve rispettare i requisiti aziendali. HTTPS o SSH restano utili per l’applicazione.

Una connessione in uscita può semplificare l’installazione ed evitare un servizio VPN esposto nella filiale. Non sostituisce una politica di accesso. Un IP pubblico, d’altra parte, non rende automaticamente insicuro un firewall. Contano i servizi esposti, la protezione e la gestione quotidiana. Non ricavo una graduatoria di sicurezza dal nome del prodotto.

Cosa voglio verificare prima dell’accettazione

Devono funzionare andata e ritorno. La rotta verso 10.2.0.0/24 va sul router o client responsabile. Se il destinatario risponde attraverso un altro gateway predefinito, serve una rotta di ritorno adatta. SNAT semplifica le risposte ma cambia l’indirizzo visibile, influenzando log e regole. Dev’essere una scelta consapevole.

Due nodi overlay non bastano per l’alta disponibilità. Dopo un guasto, i dispositivi LAN devono ancora raggiungere il gateway successivo. Keepalived e VRRP possono fornire un indirizzo virtuale. Anche le rotte remote devono selezionare un nodo sano. Voglio quindi vedere cosa succede alle sessioni TCP nuove ed esistenti quando cade un gateway o il tunnel. Un processo attivo e un ping riuscito rispondono solo in parte.

I controlli funzionali devono includere connessioni bloccate intenzionalmente. Se SSH deve passare e un’altra applicazione no, va verificato proprio questo. ICMP non dimostra che una regola TCP funzioni. Registrazione, politiche e firewall di destinazione devono concordare.

Restano i dettagli meno visibili che determinano l’uso quotidiano: prefissi distinti, nomi interni e MTU corretta. Né 192.168.x.x né 10.x.x.x garantisce assenza di conflitti. Se i ping piccoli funzionano e i trasferimenti grandi si bloccano, non considero finita la connessione.

Una valutazione delle prestazioni richiede lo stesso trasferimento e la stessa applicazione interattiva sui collegamenti reali. Vanno registrati percorso diretto o relay, carico CPU e comportamento al cambio di connessione. La mia valutazione riguarda architettura e gestione; non fornisce una classifica di velocità misurate.

Accesso remoto: Aggiungere singoli dispositivi

Quando un dipendente collega da casa il proprio portatile alla rete aziendale, si tratta di accesso remoto o client-to-site. Il client gira sul portatile e non collega automaticamente tutta la rete domestica alla sede. Si può usare il servizio del firewall centrale o i client delle piattaforme confrontate. La registrazione personale permette anche permessi associati a utenti e gruppi.

Un ufficio domestico può invece essere una sede site-to-site: un gateway collega una rete autorizzata o VLAN alla centrale. La distinzione riguarda dispositivo o rete collegata, non il luogo di lavoro. Per singoli dispositivi l’accesso remoto è spesso più appropriato. Non c’è ragione di rendere raggiungibile tutta la rete privata involontariamente.

Dove ciascun approccio ha senso per me

Per poche sedi fisse con firewall esistenti partirei dalla VPN classica, scegliendo fra hub-and-spoke e tunnel diretti. Per sedi dietro NAT, amministrazione centrale e percorsi diretti quando possibile, confronterei Tailscale e NetBird. Se gestire personalmente il coordinamento è un requisito, valuterei presto NetBird. Dove esistono già politiche Cloudflare One esaminerei Mesh, lo stato beta e il trattamento nella rete del fornitore. L’accesso remoto aggiuntivo è un criterio separato.

Un’altra opzione è Headscale, implementazione autogestita del server di coordinamento Tailscale. È un progetto distinto con proprie funzioni, non sostituisce ogni capacità del servizio ospitato. WireGuard gestito manualmente appartiene già al modello classico e ha senso se bastano pochi tunnel senza altra gestione.

Quando mi chiedono la soluzione migliore, voglio raccomandare quella adatta all’azienda e ai cambiamenti futuri. In una piccola installazione con firewall esistenti può essere ancora una VPN classica. Altre condizioni di connessione o esigenze gestionali rendono interessanti i mesh. Sceglierei in base alla possibilità di gestire in sicurezza, comprendere e ripristinare dopo un guasto le connessioni richieste.

Alla prossima,
Joe