VPN mesh ad alto rendimento per la connessione di host di datacenter

Noleggiamo un numero di host in un datacenter pubblico. Il datacenter non offre VLAN private; tutti gli host ricevono uno (o più) indirizzi IPv4 / IPv6 pubblici. Gli host sono dotati di CPU molto moderne (Haswell quad-core, 3,4 GHz) e hanno uplink Gbit. Le diverse aree (stanze? Piani? Edifici?) Del data center sono interconnesse con - da quello che posso dire - collegamenti Gbit o 500Mbit. I nostri host eseguono debian wheezy. Attualmente siamo in esecuzione appena sopra i 10 host, con l'aspettativa di crescita nel prossimo futuro.

Sto cercando un modo per far comunicare tutti gli host in modo sicuro e confidenziale. Il livello 3 va bene, il livello 2 è ok (ma non necessario). Dal momento che non ho accesso alle VLAN, dovrà essere una VPN di qualche tipo.

Ciò che è importante per me:

1. elevata produttività, idealmente vicino alla velocità del filo
2. architettura decentralizzata, mesh: questo per garantire che il throughput non venga rallentato da un elemento centrale (ad es. concentratore VPN)
3. L'impronta della CPU non è eccessiva (date le suite di crittografia AESNI e GCM, spero che questo non sia un requisito ridicolo)
4. facilità d'uso operativa; non troppo complicato da configurare; la rete può crescere senza perdere le connessioni stabilite

Attualmente stiamo usando la tinta . Spunta [2] e [4], ma raggiungo solo circa 600 Mbit / s (simplex) di una velocità di filo 960 Mbit / s e perdo completamente un core. Inoltre, Tinc 1.1 - attualmente in fase di sviluppo - non è ancora multithread, quindi sono bloccato con le prestazioni singlecore.

IPSec tradizionale è fuori discussione, poiché richiede la configurazione di un elemento centrale o di un carico di tunnel (per ottenere [2]). IPsec con crittografia opportunistica sarebbe una soluzione, ma non sono sicuro che sia mai diventato un codice di produzione stabile.

Mi sono imbattuto in tcpcrypt oggi. Fatta eccezione per l'autenticazione mancante, sembra quello che voglio. L'implementazione dello spazio utente puzza lentamente, ma lo sono anche tutte le altre VPN. E parlano di un'implementazione del kernel. Non l'ho ancora provato e sono interessato a come si comporta in [1] e [3].

Quali altre opzioni ci sono? Cosa stanno facendo le persone che non fanno parte di AWS?

Informazioni addizionali

Sono interessato a GCM, sperando che riduca il footprint della CPU. Vedi l'articolo di Intel sull'argomento . Parlando con uno degli sviluppatori di tinc, ha spiegato che anche usando AESNI per la crittografia, l'HMAC (ad esempio SHA-1) è ancora molto costoso alla velocità Gbit.

Aggiornamento finale

IPsec in modalità trasporto funziona perfettamente e fa esattamente quello che voglio. Dopo molte valutazioni ho scelto Openswan piuttosto che ipsec-tools, semplicemente perché supporta AES-GCM. Sulle CPU Haswell misuro circa 910-920Mbit / sec di throughput simplex con circa l'8-9% di carico CPU di uno kworkerd.

Quello che non vuoi è una VPN. Quello che fai mancanza è davvero IPsec, ma non in modalità tunnel. Piuttosto, vuoi IPsec in modalità di trasporto .

In questa configurazione, ogni host comunica direttamente con il proprio peer e solo i payload dei pacchetti sono crittografati, lasciando in posizione le intestazioni IP. In questo modo, non è necessario eseguire alcuna ginnastica di routing per far funzionare le cose.

Sì, avrai bisogno di una stanza di connessione IPsec per ciascun host (a meno che i tuoi host non siano raggruppati in una sottorete, nel qual caso puoi farlo tramite un blocco CIDR), ma questi possono essere facilmente generati a livello di programmazione dal tuo sistema di gestione della configurazione.

Non hai chiesto informazioni sulla configurazione, ma se hai bisogno di alcuni suggerimenti (non ci sono così tante informazioni solide là fuori sulla modalità di trasporto), puoi fare riferimento a questo post sul blog che ho scritto di recente.