OpenVPN
Benchmark
Da wir über den Einsatz von OpenVPN nachdenken, haben wir zunächst Durchsatzmessungen vorgenommen. Uns interessierte dabei:
- Hardwarebeschleunigung durch die Padlock-Engine bei einigen Via-Cx-Prozessoren
- Verhalten unter OpenBSD und unter Debian-Linux als Server-OS
Testsetup
- Netzwerk: 11 Clients innerhalb von 192.168.0/24, OpenVPN Server auf 192.168.0.81, VPN-Bereich 10.0.0/24, FTP Server auf 10.0.0.20
- Clients / FTP Server: HP Desktop dc5700M, Intel Dualcore CPU 1,80 GHz, 2G RAM, GBit LAN, XUbuntu 7.04
- OpenVPN-Server:
- VIA C7 Mainboard CV700A, 1 GHz VIA C7 CPU, 1G RAM, 3 Intel GBit Ethernetinterfaces; Debian 4.0/i386 bzw. OpenBSD 4.2current.
Debian Etch OpenSSL unterstützt leider keine C7 Hardware-Beschleunigung, daher wurden die OpenSSL 9.8.g (Quellen von Debian unstable,
http://packages.debian.org/sid/openssl) mit den OpenSSL Padlock-Ergänzungen von Michal Ludvig http://www.logix.cz/michal/devel/padlock/ gepatcht und eigene openssl Debian-Pakete erstellt. - Dell Poweredge 2950, 2 Intel Xeon 5300 Dualcore CPUs 2.33GHz, 4G RAM, 2 Broadcom GBit Ethernetinterfaces; Debian 4.0/i386
- VIA C7 Mainboard CV700A, 1 GHz VIA C7 CPU, 1G RAM, 3 Intel GBit Ethernetinterfaces; Debian 4.0/i386 bzw. OpenBSD 4.2current.
OpenVPN wurde als Bridge ohne lzo Kompression konfiguriert. Auf dem FTP Server wurde vsftpd installiert und eine 100MB grosse Datei mittels /dev/urandom im tmpfs erstellt. Alle Clients wurden gleichzeitig angewiesen, die Datei von dem FTP Server herunterzuladen. Im Falle des Dell-Poweredge 2950 als OpenVPN-Server war die 100MB große Datei aufgrund des Durchsatzes keine ausreichende Datenmenge, sie wurde daher mehrmals hintereinander von allen Clients heruntergeladen.
Für die verschiedenen Verschlüsselungen und Servertypen sowie die Clients gab es verschiedene OpenVPN-Konfigurationen.
Gemessen wurde der Durchsatz auf dem Interface des FTP Servers mittels nload.
Die Messwerte beschreiben den maximalen Durchschnitt in einem subjektiven 3-5s Fenster einer Messung. Der Durchsatz des Dell Poweredge 2950 oszillierte erwähnenswert stark, er schwankte im Rahmen von +-3MBytes/s. Da OpenVPN ein einzelnen Prozess ist, benutzte es nur einen der vier Cores des Poweredge-Servers (man müsste also mehrere OpenVPN-Prozesse zur Auslastung des Servers starten und nutzen, was in OpenVPN vorgesehen ist).
Ergebnisse
| OpenBSD 4.2 Current / VIA C7 / OpenVPN 2.0.9 (ports) | ||
| cipher | auth | performance |
| none | none | 8.0 MByte/s |
| aes-128-cbc | none | 6.8 MByte/s |
| aes-128-cbc | SHA1 | 5.4 MByte/s |
| aes-256-cbc | SHA1 | 5.4 MByte/s |
| Debian 4.0 / VIA C7 / OpenVPN 2.0.9 (debian) | ||
| cipher | auth | performance |
| none | none | 21.2 MByte/s |
| aes-128-cbc | none | 18.6 MByte/s |
| aes-128-cbc | SHA1 | 14.5 MByte/s |
| aes-256-cbc | SHA1 | 14.3 MByte/s |
| Debian 4.0 / Dell 2950 / OpenVPN 2.0.9 (debian) | ||
| cipher | auth | performance |
| none | none | 91 MByte/s |
| aes-128-cbc | none | 50 MByte/s |
| aes-128-cbc | SHA1 | 37 MByte/s |
| aes-256-cbc | SHA1 | 30 MByte/s |
Bei den Messungen wurde nebenher zur Einschätzung der Ergebnisse auch eine Cisco ASA 5505 durchgemessen. Natürlich nicht mit OpenVPN sondern mit IPSec und vpnc als VPN-Client:
| Cisco ASA 5505 (clientside vpnc) | ||
| cipher | auth | performance |
| 3DES | SHA1 | 11.1 MByte/s |
| AES-128 | SHA1 | 11.1 MByte/s |
| AES-256 | SHA1 | 10.4 MByte/s |
Bei diesen ASA-Messungen waren nur 10 Clients verbunden, jedoch konnten nur 8 Clients Daten übertragen. Dieses Verhalten der ASA war reproduzierbar, so aber entgegen der Dokumentation.
Kein Support
Für diesen Tipp / die Software bzw. Skripte leistet das RRZN keinen Support.
Druckversion
Top