Kategorien-Archiv Blog

openvpn cipher performance benchmark vergleich geschwindigkeit

Möchte man z.B. wie wir, über einen WPA2 WLAN-Link, eine doppelte Sicherheit und deshalb noch ein VPN spannen, nimmt man hierzu gerne OpenVPN. Geht es um größere Bandbreiten (> 100Mbit) des Links, kann man schnell an Grenzen stoßen. Der machbare Durchsatz hängt von mehreren Faktoren ab:

• Gewählte Cipher
• Verfügbare CPU-Leistung für Verschlüsselung
• Genutztes Protokoll
• Genutzte Art der Verschlüsselung (TLS / PSK)

Ziehen wir das Pferd von hinten auf. Je nach genutzter Verschlüsselung, bieten sich unterschiedliche Ciphers an. Dies zeigt auf einem OpenVPN-Knoten:

`openvpn –show-ciphers`

Bei unserer Verbindung kommt ein statischer Schlüssel zum Einsatz (secret….) wodurch alle TLS-Ciphers in der Übersicht ausscheiden. Den besten Durchsatz haben wir erreicht mit aes-256-cbc.

Da UDP verbindungslos ist, ist UDP hier dem TCP-Protokoll vorzuziehen.

Bei allen unseren Tests wurde klar, dass Verschlüsselung ganz gravierend auf die CPU schlägt und OpenVPN bis heute im Jahr 2018 pro Verbindung jeweils nur einen CPU-Kern nutzt.  Aus diesem Grund bremst fast immer die CPU (100% Last) die Übertragung.

Hier noch ein paar Performancewerte (Angabe jeweils in Mbits-Durchsatz – gemessen mit iperf im client/server Mode mit TCP – 40 Sekunden Test)

OpenVPN als virtuelle KVM-Maschine auf mobilem Intel i5 Laptop:

BF-CBC -> 213 Mbits

AES-128-CBC -> 227 Mbits

CAMELLIA-128-CBC -> 206 MBit

Man sieht immer schön mit ‚top‘ dass die CPU bei 100% hängt – technisch deutlich mehr möglich wäre also, wenn die Rechenleistung verfügbar ist.

Ein Blick in Proxmox/KVM zeigt, dass hier nicht alle CPU-Flags (vgl. cat /proc/cpuinfo) an die VM durchgereicht werden. Wählt man in der Virtualisierungslösung bei CPU-Typ ‚host‘ bzw. einen aktuellen CPU, sehen die Werte nach einem Neustart der VM gleich anders aus:

AES-128-CBC -> 313 Mbit

AES-256-CBC -> 309 Mbit

Es bleibt jedoch die CPU der Flaschenhals. Im Vergleich dümpelte ein Xeon E3 Prozessor auf dem Ziel-OpenVPN-System bei ~ 45 % Auslastung herum. Hier wäre noch Luft nach oben. Dennoch bleibt Verschlüsselung eine nicht zu unterschätzende Anforderung an die CPU.

Postfix – Absender darf nur spezielle Domains adressieren

Ausgangslage:

Mehrere Systeme im Haus, relayen über den zentralen Postfix-Mailserver

Anforderung:

Ein bestimmter Absender (benachrichtigung@cubewerk.de) darf nur 3 bestimmte Zieldomains (microsoft.com, aol.com, yahoo.com) anschreiben.

Für alle anderen Domains, soll dieser eine Absender ein reject erhalten.

main.cf erweitern um:

smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/benachrichtigung
smtpd_restriction_classes = benachrichtigung
benachrichtigung = check_recipient_access hash:/etc/postfix/erlaubt, reject

/etc/postfix/benachrichtigung erstellen mit
benachrichtigung@cubewerk.de benachrichtigung

postmap /etc/postfix/benachrichtigung

/etc/postfix/erlaubt erstellen mit
microsoft.com OK
aol.com OK
yahoo.com OK

postmap /etc/posfix/erlaubt

Abschließend ein /etc/init.d/posfix restart

Jetzt der Praxistest:

bauer@mail05:~$ telnet localhost 25
Trying ::1…
Connected to localhost.
Escape character is ‚^]‘.
220 mail05.int ESMTP Postfix (Ubuntu)
mail from: benachrichtigung@cubewerk.de
250 2.1.0 Ok
rcpt to: test@microsoft.com
250 2.1.5 Ok
rcpt to: test@yahaoo.com
250 2.1.5 Ok
rcpt to: anderer-empfaenger@t-online.de
554 5.7.1 <benachrichtigung@cubewerk.de>: Sender address rejected: Access denied

Restliche Absender davon nicht berührt:

bauer@mail05:~$ telnet localhost 25
Trying ::1…
Connected to localhost.
Escape character is ‚^]‘.
220 mail05.int ESMTP Postfix (Ubuntu)
mail from: interner-absender@cubewerk.de
250 2.1.0 Ok
rcpt to: anderer-empfaenger@t-online.de
250 2.1.5 Ok

kopano K-1216 – security update – duration np-defrag

Aufgrund CVE-2018-8950 und CVE-2018-8951 sollte aktuell jeder Kopano-Server aktualisiert werden.

Details hierzu hier:

Kopano Groupware Core 8.5.8: Vulnerability fixes and more (updated)

Bei unserem Server mit ~ 120 Benutzern und Corosync/Pacemaker-Cluster und ~ 200GB Mysql-Datenbank dauerte der anschließende Aufruf von opano-dbadm k-1216 ~ 5 1/2 Stunden.

Trotz 32 CPU-Kernen schnappt sich MySQL immer nur einen Kern wie es scheint.

Auszug des Laufs:

up: merging #3946 into #1375 in „lob“…
dbadm: executing action „np-defrag“
defrag: 2960 IDs
defrag: moving 2 -> 1 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 4 -> 2 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 6 -> 3 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 8 -> 4 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 10 -> 5 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 12 -> 6 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 14 -> 7 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 16 -> 8 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 18 -> 9 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 19 -> 10 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 21 -> 11 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 23 -> 12 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 25 -> 13 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 27 -> 14 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 29 -> 15 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 31 -> 16 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 33 -> 17 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 35 -> 18 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 37 -> 19 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 39 -> 20 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 41 -> 21 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 43 -> 22 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 45 -> 23 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 47 -> 24 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 49 -> 25 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 51 -> 26 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 53 -> 27 (names) (properties)