Meshed VPN mit hohem Durchsatz zur Verbindung von Rechenzentrums-Hosts

Wir vermieten eine Reihe von Hosts in einem öffentlichen Rechenzentrum. Das Rechenzentrum bietet keine privaten VLANs an. Alle Hosts erhalten eine (oder mehrere) öffentliche IPv4 / IPv6-Adressen. Die Hosts kommen mit sehr modernen CPUs (Haswell Quad-Core, 3,4 GHz) und haben Gbit-Uplinks. Die verschiedenen Bereiche (Räume, Stockwerke, Gebäude) des Rechenzentrums sind miteinander verbunden - soweit ich das beurteilen kann - mit Gbit- oder 500-Mbit-Links. Unsere Gastgeber führen debian wheezy aus. Gegenwärtig haben wir knapp über 10 Hosts, mit der Erwartung eines Wachstums in naher Zukunft.

Ich suche nach einer Möglichkeit, alle Hosts dazu zu bringen, sicher und vertraulich miteinander zu kommunizieren. Schicht 3 ist in Ordnung, Schicht 2 in Ordnung (aber nicht notwendig). Da ich keinen Zugriff auf VLANs habe, muss es sich um ein VPN handeln.

Was ist mir wichtig:

Hoher Durchsatz, idealerweise nahe an der Drahtgeschwindigkeit
dezentrale, vermaschte Architektur - um sicherzustellen, dass der Durchsatz nicht durch ein zentrales Element (z. B. VPN-Konzentrator) verlangsamt wird
CPU-Auslastung ist nicht übermäßig (angesichts der AESNI- und GCM-Verschlüsselungssuiten hoffe ich, dass dies keine lächerliche Anforderung ist)
Bedienungskomfort; nicht zu kompliziert einzurichten; Das Netzwerk kann wachsen, ohne dass bestehende Verbindungen verloren gehen

Wir verwenden derzeit Tinc . Es tickt [2] und [4], aber ich erreiche nur ungefähr 600 Mbit / s (Simplex) einer Wirespeed von 960 Mbit / s, und ich verliere einen Kern vollständig. Außerdem ist Tinc 1.1, das sich derzeit in der Entwicklung befindet, noch nicht multithreading-fähig, sodass ich bei der Singlecore-Leistung nicht weiterkomme.

Herkömmliches IPSec kommt nicht in Frage, da es ein zentrales Element oder eine Unmenge von Tunneln erfordert, die konfiguriert werden müssen (um [2] zu erreichen). IPsec mit opportunistischer Verschlüsselung wäre eine Lösung, aber ich bin mir nicht sicher, ob es jemals zu einem stabilen Produktionscode gekommen ist.

Ich bin heute über tcpcrypt gestolpert . Abgesehen von der fehlenden Authentifizierung sieht es so aus, wie ich es will. Die Implementierung des Userspace ist langsam, aber auch alle anderen VPNs. Und sie sprechen von einer Kernel-Implementierung. Ich habe es noch nicht ausprobiert und bin gespannt, wie es sich zu [1] und [3] verhält.

Welche anderen Möglichkeiten gibt es? Was machen Leute, die nicht bei AWS sind?

Zusätzliche Information

Ich interessiere mich für GCM und hoffe, dass es den CPU-Fußabdruck verringert. Siehe Intels Artikel zum Thema . Im Gespräch mit einem der tinc-Entwickler erklärte er, dass der HMAC (z. B. SHA-1) auch bei Verwendung von AESNI für die Verschlüsselung mit Gbit-Geschwindigkeit noch sehr teuer ist.

Endgültiges Update

IPsec im Transportmodus funktioniert einwandfrei und macht genau das, was ich will. Nach langem Ausprobieren habe ich mich für Openswan gegenüber ipsec-tools entschieden, einfach weil es AES-GCM unterstützt. Auf den Haswell-CPUs messe ich einen Simplex-Durchsatz von ca. 910-920 Mbit / s bei einer CPU-Auslastung von ca. 8-9% kworkerd.

— Strang
quelle

SO, Low-End-Ausrüstung? Welche Leistung erwarten Sie nach der Verschlüsselung auf Gigabit-Ebene? Auf keinen Fall - ich schlage vor, Sie suchen einen professionelleren Host oder töten den Verschlüsselungsteil.

— TomTom

@tomtom Laut dem Cryptoperformance-Paper von Intel liegt die Verschlüsselungsleistung für AES-128-CBC bei 4,52 Zyklen pro Byte, was bedeutet, dass 100 MB / s ~ 450 MHz eines einzelnen Kerns verschlingen würden. Die Entschlüsselung ist erheblich kostengünstiger. Also , wenn die Umsetzung spezifische Themen Leistung nach unten schleppen, sollte es für Lasten auszuarbeiten, die braucht keine maximale CPU - Leistung und maximale Netzwerkleistung bei gleichzeitig .

— The-Wabbit

warum willst du GCM? IPSEC ist nicht anfällig für TLS-Angriffe. Daher ist die Verwendung von GCM zur Umgehung von TLS-Schwachstellen im CBC-Modus umstritten.

— The-Wabbit

Was Sie nicht wollen, ist ein VPN. Was Sie tun wollen , ist in der Tat IPsec, aber nicht im Tunnelmodus. Sie möchten vielmehr IPsec im Transportmodus .

In dieser Konfiguration kommuniziert jeder Host direkt mit seinem Peer, und nur die Paketnutzdaten werden verschlüsselt, sodass die IP-Header an Ort und Stelle bleiben. Auf diese Weise müssen Sie keine Routing-Gymnastik machen, damit die Dinge funktionieren.

Ja, Sie benötigen für jeden Host eine IPSec-Verbindungszeilengruppe (es sei denn, Ihre Hosts sind in einem Subnetz zusammengefasst. In diesem Fall können Sie dies über einen CIDR-Block tun). Diese Zeilen können jedoch problemlos programmgesteuert von Ihrem Konfigurationsverwaltungssystem generiert werden.

Sie haben nicht nach Konfigurationsdetails gefragt, aber wenn Sie einige Hinweise benötigen (es gibt nicht allzu viele solide Informationen zum Transportmodus), können Sie auf diesen Blog-Beitrag verweisen, den ich kürzlich geschrieben habe.

— EEAA
quelle

Ich befürworte die Idee, dafür den IPSEC-Transportmodus zu verwenden. Die Verwendung von PSK mit OpenSWAN ist jedoch möglicherweise nicht das beste Setup. Linux wird bereits mit einer nativen IPSEC-Implementierung und einem Keying-Daemon (Racoon) geliefert. Ich würde mich daran halten, es sei denn, es gibt eine spezielle Anforderung, die von KAME / Racoon nicht abgedeckt wird.

— The-Wabbit

Vielen Dank! In Kombination mit Ihrem Rat habe ich die native IPSec-Implementierung mit Racoon verwendet. Ich habe zuerst auf kleinen Single-Core-Maschinen getestet und bereits den Durchsatz um 50% erhöht und die Latenz auf etwa 60% gesenkt. Ich werde es nächste Woche auf den Haswell-Knoten bestätigen und die Antwort dann akzeptieren. Ich muss allerdings herausfinden, ob AES-GCM im Kernel unterstützt wird und wie ich es IPsec signalisieren kann.

— Hank

@ syneticon-dj - einfach nur neugierig ... warum nicht openswan? Es verwendet immer noch die IP-xfrm-Bits des Kernels für IPSec, verwendet jedoch Pluto als IKE-Daemon für den Benutzerbereich anstelle von Racoon. Ich befürworte nicht, dass openswan das Beste ist - es ist einfach alles, was ich verwendet habe, und wenn es bessere Optionen gibt, möchte ich diese Richtung einschlagen.

— EEAA

Es läuft wahrscheinlich auf persönliche Vorlieben hinaus, aber ich hatte immer Probleme mit der Unachtsamkeit der Free- / OpenSWAN-Konfigurationsdateien und der äußerst hässlichen Routing-Implementierung. Ich mag den dynamischen Teil racoonctlsehr, der dem sehr ähnelt, was kommerzielle Router in ihren IPSEC-Steuerungen berücksichtigen. KAME fühlt sich gründlicher entwickelt, während OpenSWAN sich eher zusammengeflickt fühlt.

— The-Wabbit

@ syneticon-dj, möchten Sie dies näher erläutern? Meinen Sie damit, dass Sie mehrere Netzwerke über eine IPSec-Verbindung routen können, ohne dass mehrere SA-Konfigurationen erforderlich sind, wie dies jetzt bei Openswan der Fall ist?

— Rsuarez