«Come accedo ai sistemi aziendali da fuori?» ha avuto per vent’anni una sola risposta: la VPN. Oggi la risposta migliore, per molte aziende, è un’altra: una rete overlay — una rete cifrata che vive sopra Internet e collega utenti, server, sedi e apparati con tunnel diretti, senza esporre nulla. La tecnologia di base si chiama WireGuard, è open source e sta nel kernel Linux dal 2020. Vediamo come funziona, cosa cambia rispetto alla VPN e qual è la domanda — quasi sempre saltata — da fare prima di scegliere un servizio di questo tipo.
La VPN dà accesso alla rete. Ed è questo il problema
La VPN tradizionale fa esattamente ciò che promette: mette il dispositivo remoto dentro la rete aziendale. Il problema è che lo fa davvero. Una credenziale rubata o un notebook compromesso non aprono una porta: aprono il palazzo — con la possibilità di muoversi lateralmente verso file server, gestionali, backup. Non a caso il ransomware in azienda entra spesso proprio da un accesso remoto legittimo.
C’è poi un secondo problema, più silenzioso: il concentratore VPN è un servizio esposto su Internet. Va patchato con disciplina, e le vulnerabilità critiche sui gateway VPN e sulle appliance di accesso remoto sono ormai una presenza fissa nei bollettini delle agenzie di sicurezza — chi tiene un firewall con la VPN pubblicata sa quanto spesso arriva l’avviso «aggiornare subito». Ogni porta in ascolto su Internet è superficie d’attacco che qualcuno, prima o poi, proverà.
Come funziona una rete overlay
Una rete overlay ribalta il modello. Su ogni dispositivo — notebook, server, macchina virtuale, apparato — gira un agent leggero che stabilisce tunnel WireGuard cifrati punto-a-punto con gli altri dispositivi autorizzati. Le connessioni sono in uscita: niente porte aperte, niente port forwarding, e i tunnel attraversano i NAT da soli; solo quando il collegamento diretto è impossibile il traffico passa da un relay, che vede esclusivamente pacchetti cifrati. WireGuard è il motivo per cui tutto questo è affidabile: circa 4.000 righe di codice contro le centinaia di migliaia degli stack VPN tradizionali, crittografia moderna, ed è parte del kernel Linux dal rilascio 5.6 del 2020.
Sopra i tunnel c’è il pezzo che decide tutto: il control plane. È il cervello della rete: autentica i dispositivi (tipicamente con SSO sull’identità aziendale), distribuisce le chiavi e applica le policy di accesso — chi può parlare con chi, su quali porte. Vale la pena essere precisi su cosa vede e cosa no:
| Il control plane | Dettaglio |
|---|---|
| Non vede | Il contenuto del traffico: viaggia cifrato end-to-end direttamente tra i dispositivi, anche quando transita da un relay. |
| Vede — e governa | L’inventario dei dispositivi e la loro identità, le chiavi pubbliche, le policy di accesso (chi può raggiungere cosa), la topologia della rete, gli eventi di connessione. |
In altre parole: il control plane non legge i vostri file, ma conosce la mappa completa di come la vostra azienda è collegata — e ha il potere di cambiarla. È un asset critico nello stesso senso in cui lo è il controller di rete: la domanda giusta non è solo «che funzionalità ha», ma «dove sta e chi ne risponde».
La domanda che quasi nessuno fa: dove sta il control plane
I servizi overlay più noti sono SaaS di fornitori statunitensi: si attivano in dieci minuti e funzionano bene, ma il control plane — la mappa e le chiavi della vostra rete — vive presso un provider soggetto alla giurisdizione USA. Vale il discorso già fatto per il controller UniFi: il CLOUD Act, la legge federale del 2018, consente alle autorità americane di ordinare a un provider sotto la loro giurisdizione la consegna dei dati che detiene, ovunque siano fisicamente i server. Le alternative esistono, ed è qui che la natura open source della tecnologia diventa un fatto pratico e non ideologico: il control plane si può far girare altrove.
| Opzione | Chi gestisce il control plane | Giurisdizione | Adatta a |
|---|---|---|---|
| SaaS del vendor | Il vendor | Tipicamente USA (CLOUD Act) | Chi privilegia la rapidità e non ha vincoli di giurisdizione |
| Self-hosted (open source) | Voi | La vostra | Team IT strutturati, pronti a gestirlo come produzione |
| Gestita da un fornitore IT europeo | Il fornitore, su cloud EU | EU | Chi vuole il modello Zero Trust senza gestirne l’infrastruttura |
Detto senza tifoserie, come sempre: per molte aziende la giurisdizione del provider è indifferente, ed è una scelta legittima. Ma se l’azienda ha vincoli — due diligence di clienti enterprise, pubblica amministrazione, dati regolamentati — la giurisdizione del control plane va decisa prima, non scoperta dopo. E il self-hosting è realistico solo se qualcuno, con nome e cognome, si prende la responsabilità di aggiornarlo, salvarlo e monitorarlo.
E Microsoft Entra Private Access?
Domanda legittima, perché Microsoft ha la sua risposta ZTNA: Entra Private Access (parte di Global Secure Access) pubblica le applicazioni interne agli utenti autenticati con Entra ID, con Conditional Access a ogni richiesta. Richiede Entra ID P1 o P2 come prerequisito, più una licenza dedicata o la Microsoft Entra Suite. Per l’accesso degli utenti alle applicazioni in un ambiente Microsoft è spesso la strada più naturale — ne abbiamo scritto in ZTNA: come sostituire la VPN aziendale.
La rete overlay copre ciò che un ZTNA applicativo non copre: i collegamenti site-to-site tra sedi, i server che parlano con server, gli apparati di gestione e le risorse self-hosted, gli ambienti misti dove non tutto vive nell’ecosistema Microsoft. Non sono concorrenti: sono due strumenti, e in parecchie aziende convivono — Entra Private Access per le persone, la rete overlay per l’infrastruttura. La scelta dipende da struttura, licenze e budget: è un progetto di rete, non un acquisto a catalogo.
Dall’esperienza sul campo
Quattro cose che si imparano mettendo in produzione reti overlay, non leggendo le brochure.
- Se il control plane è giù, la rete regge — ma si congela. I tunnel attivi continuano a funzionare con le chiavi già distribuite; a fermarsi sono le novità: nuovi dispositivi, modifiche alle policy, rotazioni. È il motivo per cui il control plane va monitorato come un sistema di produzione, non come un tool di comodo.
- Si parte dai subnet router, non dagli agent ovunque. Il rollout pratico comincia con un nodo che pubblica una subnet esistente (la sede, la server farm) e gli agent solo sui dispositivi remoti: si migra a pezzi, senza big bang. Gli agent sui singoli server arrivano dopo, dove servono policy granulari.
- Le policy di default-deny vanno provate su un gruppo pilota. Il potere di dire «solo chi è autorizzato raggiunge questa risorsa» è anche il potere di tagliare fuori il gestionale alle 9 del lunedì. Prima il gruppo pilota, poi il resto dell’azienda — con le policy versionate e documentate.
- L’aggancio all’identità è il vero moltiplicatore. Con il SSO su Entra ID, l’offboarding di un collaboratore revoca anche l’accesso alla rete — subito, non alla prossima ricognizione delle utenze VPN. E il DNS interno va pianificato: i nomi con cui le risorse si raggiungono attraverso l’overlay devono essere gli stessi ovunque, o il telefono squilla.
Il nostro modello
Per completezza: eroghiamo una rete overlay Zero Trust gestita basata su WireGuard e tecnologia open source, con il control plane sulla nostra infrastruttura cloud europea — sotto giurisdizione EU, gestita secondo ISO/IEC 27001, 27017, 27018 e ISO 9001 — accesso legato all’identità con SSO su Microsoft Entra ID e policy per gruppi. Si integra con la gestione della rete e dell’hardware: per chi vuole il modello, senza doverne diventare il manutentore.
Fonti
- Jason A. Donenfeld — «WireGuard: Next Generation Kernel Network Tunnel» (whitepaper, NDSS 2017)
- Kernel Linux — release 5.6, marzo 2020 (integrazione di WireGuard)
- CLOUD Act — Clarifying Lawful Overseas Use of Data Act, H.R. 4943, Stati Uniti, 2018
- Microsoft Learn — «What is Global Secure Access?» e «Microsoft Entra licensing»
Approfondisci
Domande frequenti
Le risposte alle domande più comuni sulle reti overlay e la sostituzione della VPN.
Tecnicamente usa la stessa famiglia di strumenti — tunnel cifrati, nel nostro caso WireGuard — ma il modello di accesso è l’opposto. La VPN classica collega il dispositivo alla rete: una volta dentro, si raggiunge tutto ciò che la rete non vieta. La rete overlay collega il dispositivo alle singole risorse autorizzate: ogni collegamento è esplicito, legato all’identità, e tutto il resto semplicemente non esiste. È la differenza tra dare le chiavi del palazzo e aprire una porta alla volta.
No: il traffico viaggia cifrato end-to-end direttamente tra i dispositivi, e anche quando serve un relay il contenuto resta cifrato. Ma il control plane sa molto della rete: quali dispositivi esistono, chi può parlare con chi, la topologia, gli eventi di connessione. È il motivo per cui la domanda «chi gestisce il control plane, e sotto quale giurisdizione» va fatta prima di scegliere il servizio, non dopo.
I tunnel già stabiliti continuano a funzionare: le chiavi sono già distribuite e il traffico passa direttamente tra i dispositivi. Quello che si ferma è il piano di gestione: niente nuovi dispositivi, niente rotazione delle chiavi, niente modifiche alle policy finché non torna raggiungibile. È un guasto degradato, non un blackout — ma è anche il motivo per cui il control plane va gestito e monitorato come un sistema di produzione.
Dipende da cosa dovete collegare. Entra Private Access è la risposta naturale per l’accesso degli utenti alle applicazioni interne in un ambiente Microsoft: richiede Entra ID P1 o P2 più una licenza dedicata o la Microsoft Entra Suite, e si integra con Conditional Access. La rete overlay copre ciò che un ZTNA applicativo non copre: collegamenti site-to-site tra sedi, server che parlano con server, apparati di gestione, ambienti misti. In molte aziende convivono: scegliamo in base a struttura, licenze e budget.
No, ed è uno dei vantaggi principali: ogni dispositivo stabilisce connessioni in uscita, e i tunnel si formano con tecniche di NAT traversal. Niente port forwarding, niente concentratore VPN pubblico da patchare, niente RDP o VNC esposti su Internet. Un attaccante che scansiona i vostri IP pubblici non trova nulla in ascolto.