Oltre cinquanta sedi collegate in BGP: la rete di un gruppo cresciuto per acquisizioni
Una rete multi-sede costruita per acquisizioni successive non è una rete grande: è un numero grande di reti piccole che si toccano. Questo è il caso in cui il conteggio ha smesso di contare — oltre cinquanta sedi su un solo impianto di routing dinamico, dove collegare la prossima costa quanto è costata l'ultima.
Il nome del cliente non compare. Sulle nostre pagine il nome e il dettaglio architetturale non stanno mai insieme: uno dei due si sceglie, e qui abbiamo scelto il dettaglio.
La situazione
Un gruppo industriale italiano cresciuto in pochi anni per acquisizioni successive, fino a superare le cinquanta sedi fra stabilimenti, uffici e magazzini.
Ogni azienda entrata si è portata dietro la propria rete: un piano di indirizzamento deciso da qualcun altro, un firewall di marca diversa, una connettività scelta con criteri locali, regole scritte negli anni da persone che nel frattempo non ci sono più. Il risultato non era una rete: erano cinquanta reti che si toccavano.
Il problema
Il problema non era collegare le sedi — quello lo fa chiunque con una VPN site-to-site. Era che ogni nuova acquisizione ripartiva da zero: sovrapposizioni di indirizzamento da risolvere a mano, policy da riscrivere caso per caso, tempi di integrazione misurati in settimane.
In un gruppo che continua a comprare, il tempo di integrazione di una sede non è un dettaglio operativo: è un costo che si moltiplica per ogni operazione futura.
Routing dinamico su loopback, non VPN statiche
Le sedi si annunciano fra loro in BGP. Le sessioni BGP sono stabilite fra interfacce di loopback e trasportate dentro i tunnel IPsec: il peering non è legato al singolo tunnel, quindi sopravvive alla sua rinegoziazione e regge più percorsi verso la stessa sede.
Una sede nuova annuncia le proprie reti e riceve quelle del gruppo. Nessuno apre la configurazione degli altri apparati, quindi non esiste la classe di errore in cui una rotta finisce su quarantanove firewall su cinquanta e nessuno se ne accorge fino al giorno in cui serve.
È la differenza fra una WAN progettata e una somma di tunnel. Il criterio con cui scegliamo fra le due — quando bastano i tunnel e quando serve il routing dinamico — è sulla pagina firewall aziendali FortiGate.
SD-WAN sulla qualità del percorso, non sulla presenza del link
Dove la sede ha più connettività, FortiGate misura la qualità dei percorsi — non solo se la linea è elettricamente su — e sposta il traffico secondo policy per categoria. Il traffico verso i servizi cloud del gruppo e quello verso il datacenter seguono regole diverse, perché hanno tolleranze diverse.
Identità federata sull'accesso remoto
Le VPN utente si appoggiano all'identity provider del gruppo via SAML. Chi entra ha accesso il primo giorno; chi esce lo perde nel momento in cui viene disattivato centralmente, senza che nessuno debba ricordarsi di toccare cinquanta firewall.
Su un perimetro che cambia di continuo per acquisizioni e riorganizzazioni, l'account che sopravvive alla persona è il rischio numero uno — e l'unico modo di chiuderlo è non gestire le identità sul firewall.
Un modello, non cinquanta configurazioni
Stesse zone, stesse categorie di policy, stessa struttura di naming. Le differenze fra una sede e l'altra esistono, sono volute, sono poche e sono documentate.
Una configurazione che si legge in cinque minuti è una configurazione che si può correggere sotto pressione. È il motivo per cui la progettazione e la gestione della rete pesano più dell'apparato scelto.
Il risultato
L'integrazione di una sede nuova è diventata una procedura, non un progetto. Il gruppo può valutare un'acquisizione senza chiedersi ogni volta quanto costerà collegarla.
Il valore: non abbiamo collegato cinquanta sedi. Abbiamo fatto in modo che la cinquantunesima costi come la cinquantesima.
Rispondiamo entro un giorno lavorativo. Nessun impegno.