WireGuard, IPsec e SD-WAN non si collocano sullo stesso piano. WireGuard e IPsec proteggono il traffico nei tunnel. SD-WAN descrive un servizio gestito di collegamento tra sedi su una o più connessioni sottostanti; la cifratura può basarsi su tecnologie diverse. Per più sedi aziendali la scelta parte quindi da applicazioni, linee, responsabilità e scenari di guasto, prima del nome di un prodotto.
Un’azienda fittizia ha una sede centrale e tre filiali. ERP e telefonia usano servizi centrali, Microsoft 365 accede a internet il più direttamente possibile e una ditta di manutenzione necessita solo di un accesso limitato. Il contributo DAXS sulla manutenzione di OPNsense tratta il processo di aggiornamento di un firewall; qui esaminiamo la topologia delle sedi e la scelta operativa. Una seconda connessione internet per ogni sede è un tema distinto, che il solo nome SD-WAN non risolve.
Quattro verifiche prima di scegliere un protocollo
Per ogni sede si rilevano prima applicazioni, reti di destinazione, picco di carico misurato, requisiti di latenza, raggiungibilità pubblica e guasti delle linee. Intervalli di indirizzi privati sovrapposti complicano routing e autorizzazioni indipendentemente dal protocollo di tunnel. Poi si stabilisce se le filiali comunicano solo con la centrale o anche direttamente tra loro; hub-and-spoke richiede meno relazioni di tunnel ma può trasformare la centrale in un collo di bottiglia. Infine si assegnano gestione, manutenzione delle chiavi, monitoraggio e una procedura di ripristino verificata.
| Approccio | Adatto quando … | Verifiche e limiti |
|---|---|---|
| WireGuard | Pochi peer e reti chiaramente definiti consentono una gestione sostenibile delle chiavi | Provare concretamente AllowedIPs, rotte, regole firewall, NAT e raggiungibilità per ogni peer; il protocollo non fornisce automaticamente una gestione centrale |
| IPsec con IKEv2 | I dispositivi o i peer esistenti richiedono tunnel IPsec standardizzati | Collaudare profili tra produttori, certificati, rekeying, NAT-T e failover sulla coppia concreta di dispositivi |
| Servizio SD-WAN | Più linee, numerose sedi o percorsi applicativi richiedono controllo e assistenza centralizzati | Verificare tecnicamente e contrattualmente underlay, dispositivi edge, policy, punti di misura, accesso gestionale, SLA e percorso in caso di guasto |
Una piccola rete può funzionare molto bene con WireGuard o IPsec se qualcuno è responsabile della configurazione e dei guasti. Un’offerta SD-WAN può riunire queste attività operative e gestire i percorsi, ma introduce propri costi di piattaforma, licenze, supporto e dipendenze. La maggiore disponibilità dipende da linee realmente indipendenti e da una commutazione collaudata.
WireGuard: peer chiari, reti chiare
WireGuard associa chiavi pubbliche a intervalli IP consentiti. In un collegamento tra sedi questi intervalli devono corrispondere alla tabella di routing e alle regole firewall; un handshake riuscito non prova ancora la raggiungibilità di ERP o telefonia. Dietro il NAT di un peer può essere necessario un keepalive. La documentazione OPNsense illustra controlli concreti di peer, rotte e firewall per due sedi, oltre a possibili problemi MTU/MSS. Con quattro sedi aumentano configurazione e gestione delle chiavi, soprattutto se servono percorsi diretti tra filiali. WireGuard da solo non aggiunge gestione automatica delle policy, monitoraggio del servizio o SLA.
IPsec/IKEv2: la standardizzazione richiede collaudo
IPsec protegge i pacchetti a livello di rete; IKEv2 negozia associazioni di sicurezza e chiavi. Può essere utile con firewall eterogenei o requisiti esistenti dei partner. La compatibilità richiede comunque verifica: suite crittografiche, certificati, selettori di rete, rekeying e NAT traversal devono corrispondere sui due lati. RFC 7296 descrive, per esempio, l’incapsulamento UDP per IPsec con NAT. Il pilota verifica quindi creazione del tunnel, funzionamento prolungato, cambio delle chiavi e ripristino dopo un’interruzione della linea. Anche qui un ping riuscito non equivale a un collaudo funzionale.
SD-WAN: distinguere overlay, underlay e contratto
MEF 70.2 definisce SD-WAN come servizio con attributi concordati e lo distingue espressamente dai servizi di connettività sottostanti. Nell’esempio, regole come «ERP sul percorso A, passando a B in caso di guasto misurato» o «telefonia solo con latenza adeguata» potrebbero essere requisiti; la loro concreta disponibilità dipende dal prodotto del fornitore, dalle misure e dalle prestazioni contrattuali. Se una filiale ha un solo accesso fisico a internet, il controllo centrale non può eliminarne il guasto tramite configurazione. Anche una seconda linea aiuta poco se entrambe condividono tracciato, alimentazione o dispositivo edge.
Nell’offerta si valutano quindi separatamente hardware edge, ubicazione della gestione, linee, policy centrale, confini di sicurezza, registrazione, manutenzione firmware, orari di assistenza, percorso dei dati e scenario di uscita. «Gestito» è un vantaggio solo se sono definiti escalation, dati di misura e responsabilità in caso di guasto.
Una prova di guasto dice più di una scheda tecnica
La centrale e una filiale provano insieme quattro casi: perdita del percorso principale, guasto dell’edge, chiave o certificato non validi e applicazione non funzionante nonostante il tunnel attivo. Si misurano rilevamento, commutazione, riconnessione, impatto applicativo e ripristino del percorso normale. ERP e telefonia possono ammettere interruzioni diverse. Il verbale indica i tempi effettivi anziché una promessa generica di alta disponibilità.
La scelta economica comprende dispositivi e ricambi, configurazione di tunnel e policy, prezzi delle linee, ulteriore ridondanza reale, licenze o canoni, monitoraggio e reperibilità interna. Un tunnel WireGuard proprio può non avere costi di licenza del protocollo, ma conserva costi operativi e di connettività. Un tunnel IPsec su apparati esistenti può sembrare economico se si includono manutenzione e approvazione del produttore. Un servizio SD-WAN può ridurre il lavoro su molte sedi, ma va confrontato a parità di prestazioni. Senza misure e preventivi una classifica in euro sarebbe inventata.
DAXS può tradurre insieme all’azienda le quattro sedi, applicazioni e casistiche di guasto in una topologia collaudabile e confrontare le varianti operative adatte. I punti di partenza per un colloquio con DAXS sono schema della rete tra sedi, contratti delle linee e storico dei guasti.
Fonti: WireGuard: Quick Start; OPNsense: WireGuard Site-to-Site; IETF RFC 7296: IKEv2; Mplify/MEF 70.2: SD-WAN Service Attributes.
