Hub e spoke o mesh completo: quale topologia VPN si adatta alle vostre sedi

Due filiali parlano tra loro tutto il giorno, e il tunnel che le collega devia attraverso un data center in un'altra regione. Ogni richiesta paga quel giro due volte, e nessuno se ne accorge finché la sincronizzazione dei file non inizia a sembrare sbagliata. È qui che la domanda sulla topologia inizia davvero: non con quale schema sembri più resiliente, ma con quale modello di traffico state pagando. Entrambi i progetti funzionano, e falliscono in modi diversi con costi diversi.

Contate prima di tutto le relazioni tra pari

Con N sedi, una mesh completa richiede N per N meno uno, diviso due, tunnel; un hub ne richiede N. Con cinque sedi sono dieci contro cinque, cosa che sembra ancora gestibile. Con quindici sono 105 contro quindici, e la differenza non è più aritmetica ma di personale.

Ognuna di queste relazioni porta uno stato che dovete possedere. In IPsec significa un'associazione di sicurezza, un'identità, una chiave o un certificato, il rilevamento del peer morto e almeno una rotta per ogni prefisso remoto. In WireGuard significa una chiave pubblica e un AllowedIPs blocco per peer, che costa meno per peer ma arriva senza alcuna scoperta: una nuova sede è comunque un cambio di configurazione su ogni sede esistente.

Lasciate decidere la composizione del traffico, non il disegno

Se il traffico delle filiali è soprattutto richieste a un ERP centrale o a un cluster di file, un hub non è un compromesso, è la forma corretta: il traffico voleva già andare lì, e un solo punto di politica è più facile da verificare di una mesh di regole a coppie. Una mesh merita la sua complessità quando le filiali si scambiano dati tra loro — replica tra due uffici, voce tra sedi, una condivisione CAD che una dozzina di ingegneri aprono tutto il giorno.

I casi scomodi stanno nel mezzo, e sono la maggioranza. Misurate prima di discutere invece di indovinare da un organigramma.

Leggete la tabella come uno spareggio, non come una regola. Tre righe su quattro nella stessa direzione di solito chiudono il progetto; una divisione significa ibrido, che è ciò a cui approdano comunque la maggior parte delle reti mature.

All'hub va detto di inoltrare

Due tunnel spoke-hub funzionanti non creano accesso spoke-spoke. L'hub ha bisogno dell'inoltro IP abilitato, di una rotta verso ogni rete spoke, di una regola del firewall che consenta il transito e del percorso di ritorno calcolato; ogni spoke ha bisogno di una rotta per i prefissi dell'altra sede. Su un hub Linux è net.ipv4.ip_forward=1 più FORWARD una catena che non scarta la coppia in silenzio, e in IPsec basato su politiche sono selettori di traffico che elencano la sottorete spoke remota su entrambi i lati. In strongSwan, le note sull'inoltro coprono il lato kernel e firewall quando è quello lo strato che vi manca. Un test poco costoso è inviare traffico da uno spoke a un servizio sull'altro osservando i contatori dell'hub; una regola che non incrementa mai significa che l'ordine è sbagliato, non la rotta.

La politica centrale è anche la parte utile. Si può consentire alle filiali di raggiungere servizi condivisi senza raggiungersi a vicenda, e quella matrice di accesso vale la pena di scriverla esplicitamente. Le rotte mancanti sono un cattivo sostituto di una regola che qualcuno può leggere.

Attenzione alla versione a metà: lo spoke A instrada verso lo spoke B attraverso l'hub, l'hub instrada in entrambe le direzioni, e il firewall dell'hub consente nuove connessioni da A ma non da B. La prima direzione si prova bene e la seconda si blocca, il che sembra un guasto di instradamento e non lo è.

Progettate prima il guasto, poi il percorso normale

Un hub unico è una dipendenza condivisa e un collo di bottiglia del transito, e la ridondanza è dove i progetti con hub di solito sbagliano. Due hub significano che ogni spoke tiene due tunnel, e il percorso di ritorno deve concordare con quello di andata; quando non lo fa, un firewall stateful scarta le risposte e il sintomo è una connessione che si apre e poi muore. Le installazioni più grandi risolvono con un protocollo di instradamento sui tunnel invece che con prefissi statici, che è più macchinario ma elimina le congetture. Qualunque cosa scegliate, scrivete il percorso di ritorno accanto a quello di andata, perché è la metà di ritorno che nessuno prova.

Una mesh distribuisce quel rischio: la caduta del collegamento di una sede non isola le altre. Moltiplica anche i punti in cui la selezione del percorso può sorprendervi, e le sessioni applicative continuano a non sopravvivere a un cambio di percorso senza aiuto.

Nessuno dei due progetti mantiene da solo viva una sessione TCP attraverso un failover. Se l'applicazione non riesce a riconnettersi, la topologia non è il vostro problema.

Scegliete in base al costo del cambiamento, poi verificate le rotte

Cominciate dall'hub, perché è la cosa meno costosa su cui sbagliarsi, e aggiungete tunnel diretti per le coppie il cui traffico lo giustifica. Quell'ibrido non è una rinuncia a decidere; è il progetto su cui la maggior parte delle organizzazioni converge entro un anno. L'importante è che ogni collegamento diretto abbia una ragione dichiarata e un responsabile.

Poi verificate due disegni invece di uno. Per il percorso normale, traceroute da ogni sede a ogni prefisso di servizio e confermate che i salti corrispondano al diagramma. Per il percorso di guasto, spegnete un tunnel e ripetete, perché una rotta che funziona solo finché tutto è in piedi non è progettata, è solo configurata.

Conservate entrambi i disegni con la matrice di accesso, e rivedeteli quando si aggiunge una sede; il costo che gestite è quello del prossimo cambiamento, non l'eleganza dell'immagine attuale.