tiermutter
Well-known member
[PROLOG]
Wireguard... Wireguard?! Als würde sich die Welt plötzlich um diesen "Drahtschutz" drehen. Tja, scheint wohl so...
Wireguard ist schon länger ein heiß diskutiertes Thema, das immer heißer wird. Dieses VPN Protokoll gibt es seit 2016, als stabil kann es erst seit 2020 betrachtet werden, nachdem das Protokoll im Linux und FreeBSD Kernel Einzug fand und begann auch andere Betriebssysteme wie Windows oder Android zu erobern. Ein sehr junges Protokoll also, aber wieso der Hype um das Protokoll? Weil es neu ist und neu geil ist? Eher nicht, nein.
Ich möchte im Folgenden meine Eindrücke von dem neuen Protokoll teilen und es dem OpenVPN Protokoll gegenüberstellen, was ich bislang verwendet habe.
Als Experte für Kryptographie und VPN Techniken kann ich... Ok, das ist dezent übertrieben, ich bin auch nur ein einfacher Anwender, aber ich kann meine Beobachtungen mit euch teilen und ein oder zwei Wörter darüber hinaus verlieren
[THEORIE]
Anwendung
Während OpenVPN insbesondere für Roadwarrior, also die Verbindung einzelner PCs mit dem VPN, Anwendung findet, ist Wireguard auch bestens dafür geeignet ein Side to Side VPN aufzubauen, also eine Verbindung von zwei Standortnetzwerken. Letzteres habe und hatte ich aber nie imEinsatz, sodass ich mich auf die Roadwarrior beschränke, die für die meisten sicherlich auch interessanter sind.
Verschlüsselung
In OpenVPN kann man zwischen etlichen Verschlüsselungsalgorithmen (Ciphern) sowohl für den Verbindungsaufbau, als auch für die Verschlüsselung des Tunnels in unterschiedlichen Stärken wählen. Bewährt hat sich hier SHA1 - SHA256 für den Verbindungsaufbau und AES-GCM mit 128-256 bit für den Tunnel selbst. Die richtige Auswahl ist hier entscheidend, da andere Cipher, wie z.B. das ebenfalls häufig verwendete AES-CBC anfällig für bestimmte Angriffe sind. Je nachdem was verwendet wird, benötigt man auf Server- und Clientseite entsprechend starke Prozessoren, die unbedingt AES-NI beherrschen sollten, damit die Performance nicht leidet.
Wireguard hingegen bietet keine Möglichkeit andere Cipher zu verwenden und setzt hier fest auf Curve25519 für den Verbindungsaufbau und ChaCha20 (basierend auf Salsa20) für die Verschlüsselung des Tunnels. Curve25519 zeichnet sich dadurch aus, dass der Schlüsselaustausch sehr rasant erfolgt, eine Verbindung also sehr schnell aufgebaut werden kann. ChaCha20 ist ein Algorithmus der ebenso sicher ist wie z.B. AES-GCM, dafür aber auch deutlich performanter ist, insbesondere auch auf Geräten die kein AES-NI unterstützen (z.B. ARM Geräte und Smartphones). Wireguard genießt hier also zumindest in der Theorie einen Geschwindigkeitsvorteil auf entsprechenden Geräten, außerdem besteht nicht die Gefahr, dass das VPN durch Fehlkonfiguration der Verschlüsselung unsicher gemacht wird.
Verbindungsaufbau
Beide Protokolle haben gemeinsam, dass beim Verbindungsaufbau Zertifikate und/oder Schlüssel ausgetauscht werden, damit sich ein Client beim Server legitimieren kann. Bei OpenVPN kann optional zusätzlich Benutzername und Passwort verwendet werden, oder nur Benutzername und Passwort (unsicher!). Wireguard hingegen bietet keine weitere Möglichkeit das VPN abzusichern. Ein extremer Nachteil, denn jeder der Zugriff auf das Clientgerät (oder die dort hinterlegten Schlüssel) hat kann sich ohne weitere Legitimerung mit dem VPN verbinden, weshalb ich Wireguard aktuell nicht im geschäftlichen Umfeld sehe und die Verwendung nur dann empfehlen kann, wenn unlegitimierte Zugriffe bestmöglich ausgeschlossen werden können. Die Möglichkeit die Client App mit einem Passwort zu schützen gibt es zumindest bei Android und Windows derzeit nicht, das wäre schonmal ein Anfang. Als zusätzliche Sicherheitsebene ist es möglich einen Pre Shared Key (PSK) in Wireguard zu verwenden. Da ich hier keinen wirklichen Zugewinn an Sicherheit sehe verwende ich diesen nicht, Auswirkungen auf die Performance hätte dies aber nicht und würde den Verbindungsaufbau allenfalls marginal verzögern.
Allgemeines
Der Code von Wireguard wurde sehr schlank gehalten, was zum Einen für gute Performance und zum Anderen für hohe Sicherheit/ wenig Sicherheitslücken spricht, außerdem ist er im Gegensatz zu OpenVPN fest im Linux Kernel (ab v5.6) und FreeBSD (u.a.) integriert, sodass man auf darauf basierenden Geräten erneut einen Performanceschub erwarten kann. Die feste Integration in weiteren Betriebssystemen scheint in Arbeit zu sein, OpenVPN hingegen ist auch nach vielen Jahren in noch keinem Betriebssystem fest integriert. Außerdem wird dem Wireguard Protokoll weniger Overhead, also Zusatzinformationen die zusätzlich zu den eigentlichen Daten übertragen werden müssen, zugesprochen als OpenVPN, was ebenfalls für eine höhere Geschwindigkeit spricht.
[PRAXIS]
Einrichtung/ Konfig
Als eingesessener OpenVPN User fiel mir die Einrichtung von Wireguard gar nicht so leicht, natürlich spielt da viel Gewohnheit mit rein, aber allein die Tatsache, dass im Wireguard Protokoll mehrfach von "allowed Adresses" gesprochen wird, hat mir sehr zu schaffen gemacht, denn je nachdem an welcher Stelle davon gesprochen wird, hat es eine völlig andere Bedeutung: Mal wird hier die IP angegeben, die einem Client zugewiesen wird, und mal wird angegeben, welche Adressen oder Subnetze durch den Tunnel geroutet werden sollen. Somit hatte ich auch meine Schwierigkeiten, den Tunnel so zu konfigurieren, dass der gesamte Traffic darüber geroutet wird. Während man in OpenVPN lediglich einen Haken setzen oder den Befehl "redirect-gateway" in die Konfiguration einsetzten muss, scheint es in Wireguard partout keine Möglichkeit zu geben dies auf ähnlich einfache Weise zu gestalten, stattdessen muss die default Route durch entsprechende Einstellung unter "allowed Adresses" manuell übergangen werden. Ebensowenig finde ich weitere Informationen für erweiterte Konfigurationen, die aber allenfalls unter bestimmten Bedingungen benötigt werden. Ich habe hier keine weiteren Anforderungen, sodass ich bisher auch gut mit den Standardmöglichkeiten zurechtkomme.
Ich bin mir sicher, dass Wireguard nach etwas Eingewöhnung ebenfalls sehr einfach einzurichten ist, in OpenVPN muss man sich ja schließlich auch erstmal reinfuchsen und die Konfiguration gestaltet sich ob der vielen Optionen doch deutlich komplexer.
Geschwindigkeit
In einem VPN zählen vor allem zwei Dinge: Sicherheit und Geschwindigkeit.
Da ich der Sicherheit mangels Wissen nicht näher auf den Grund gehen kann, muss ich mich auf den Test der Geschwindigkeit beschränken.
Die Testsituation stellt sich wie folgt dar...
Server (OVPN und WG): Intel Atom E3845 (mit AES-NI), 4GB RAM, Bandbreite Internet 300/150Mbit/s
Client A1: Samsung Galaxy S20+, WLAN
Um etwaige Empfangsprobleme/ niedrige Bandbreiten im Mobilfunknetz ausschließen zu können, habe ich zunächst getestet, wie sich die Geschwindigkeit im WLAN darstellt, getestet wurde mit iperf3 in beide Richtungen (Download/ Upload).
(Bild 1: WLAN iperf3 Download)
(Bild 2: WLAN iperf3 Upload) 
Ohne VPN betrug der Download 418Mbit/s und der Upload 430Mbit/s,
bei OpenVPN 55/70 Mbit/s und
bei Wireguard 121/151 Mbit/s
Unter diesen Testbedingungen (kein Internet dazwischen) erzielt Wireguard also mehr als die doppelte Bandbreite, respekt!
Client A2: Samsung Galaxy S20+, 5G Mobilfunk
Der 5G Empfang war hier grenzwertig zu LTE+, die Geschwindigkeit des Netzes (ohne VPN) habe ich mittels Speedtest von Ookla gemessen, die VPN Geschwindigkeiten zusätzlich nochmal mit iperf3.
Bei den Bildern nicht wundern, die Messung ohne VPN weist eine LTE Verbindung aus, die beim Start der Messung nur kurz bestand, aber sofort auf 5G wechselte, diese Messung ist ohnehin eher informativ. Insgesamt ist das Mobilfunknetz an dem Standort und zu der Uhrzeit nicht sonderlich stabil (Dorfkind an der Autobahn 7 ), daher erzielt WG auch bessere Ergebnisse als das Netz vermeintlich hergibt. Die Messung sollte aber aussagekräftig genug sein.
(Bild 3: 5G Mobilfunk, Ookla)
(Bild 4: 5G Mobilfunk, iperf3) 
Ohne VPN betrug der Download 89Mbit/s und der Upload 36Mbit/s,
bei OpenVPN 24/11 Mbit/s (Ookla) und
bei Wireguard 45/39 Mbit/s (Ookla)
sowie
bei OpenVPN 11/19 Mbit/s (iperf3) und
bei Wireguard 20/28 Mbit/s (iperf3)
Auch hier erzielt Wireguard stets fast die doppelte Geschwindigkeit von OpenVPN. Auffällig ist hier der erhöhte Jitter (schwankende Latenz) sowie der damit zusammenhängende Paketverlust bei Wireguard, ich konnte dies aber nicht nochmal nachstellen und kann das Problem daher nicht auf das Wireguard Protokoll schieben, sondern vermute das Mobilfunknetz selbst als Verursacher.
Alles in allem kann man bereits jetzt sagen, dass das Wireguard Protokoll einen sehr deutlichen Geschwindigkeitsvorteil gegenüber OpenVPN hat. Etwaige Messtoleranzen, etc. dürften daran nichts mehr rütteln. Dennoch sind diese "praktischen" Messungen eher theoretischer Natur, da beide Messverfahren nicht die üblicherweise eingesetzten Dateiübertragungsprotokolle wie z.B. SMB oder FTP berücksichtigen, die ebenfalls durch den Tunnel laufen müssen. Dies werde ich (zumindest für SMB) zu einem anderen Zeitpunkt in einem anderen Erfahrungsbericht testen und euch daran teilhaben lassen. Auch ein Test mit einem potenteren PC (Stichwort AES-NI) über kabelgebundenes Internet steht noch aus.
Wireguard... Wireguard?! Als würde sich die Welt plötzlich um diesen "Drahtschutz" drehen. Tja, scheint wohl so...
Wireguard ist schon länger ein heiß diskutiertes Thema, das immer heißer wird. Dieses VPN Protokoll gibt es seit 2016, als stabil kann es erst seit 2020 betrachtet werden, nachdem das Protokoll im Linux und FreeBSD Kernel Einzug fand und begann auch andere Betriebssysteme wie Windows oder Android zu erobern. Ein sehr junges Protokoll also, aber wieso der Hype um das Protokoll? Weil es neu ist und neu geil ist? Eher nicht, nein.
Ich möchte im Folgenden meine Eindrücke von dem neuen Protokoll teilen und es dem OpenVPN Protokoll gegenüberstellen, was ich bislang verwendet habe.
Als Experte für Kryptographie und VPN Techniken kann ich... Ok, das ist dezent übertrieben, ich bin auch nur ein einfacher Anwender, aber ich kann meine Beobachtungen mit euch teilen und ein oder zwei Wörter darüber hinaus verlieren
[THEORIE]
Anwendung
Während OpenVPN insbesondere für Roadwarrior, also die Verbindung einzelner PCs mit dem VPN, Anwendung findet, ist Wireguard auch bestens dafür geeignet ein Side to Side VPN aufzubauen, also eine Verbindung von zwei Standortnetzwerken. Letzteres habe und hatte ich aber nie imEinsatz, sodass ich mich auf die Roadwarrior beschränke, die für die meisten sicherlich auch interessanter sind.
Verschlüsselung
In OpenVPN kann man zwischen etlichen Verschlüsselungsalgorithmen (Ciphern) sowohl für den Verbindungsaufbau, als auch für die Verschlüsselung des Tunnels in unterschiedlichen Stärken wählen. Bewährt hat sich hier SHA1 - SHA256 für den Verbindungsaufbau und AES-GCM mit 128-256 bit für den Tunnel selbst. Die richtige Auswahl ist hier entscheidend, da andere Cipher, wie z.B. das ebenfalls häufig verwendete AES-CBC anfällig für bestimmte Angriffe sind. Je nachdem was verwendet wird, benötigt man auf Server- und Clientseite entsprechend starke Prozessoren, die unbedingt AES-NI beherrschen sollten, damit die Performance nicht leidet.
Wireguard hingegen bietet keine Möglichkeit andere Cipher zu verwenden und setzt hier fest auf Curve25519 für den Verbindungsaufbau und ChaCha20 (basierend auf Salsa20) für die Verschlüsselung des Tunnels. Curve25519 zeichnet sich dadurch aus, dass der Schlüsselaustausch sehr rasant erfolgt, eine Verbindung also sehr schnell aufgebaut werden kann. ChaCha20 ist ein Algorithmus der ebenso sicher ist wie z.B. AES-GCM, dafür aber auch deutlich performanter ist, insbesondere auch auf Geräten die kein AES-NI unterstützen (z.B. ARM Geräte und Smartphones). Wireguard genießt hier also zumindest in der Theorie einen Geschwindigkeitsvorteil auf entsprechenden Geräten, außerdem besteht nicht die Gefahr, dass das VPN durch Fehlkonfiguration der Verschlüsselung unsicher gemacht wird.
Verbindungsaufbau
Beide Protokolle haben gemeinsam, dass beim Verbindungsaufbau Zertifikate und/oder Schlüssel ausgetauscht werden, damit sich ein Client beim Server legitimieren kann. Bei OpenVPN kann optional zusätzlich Benutzername und Passwort verwendet werden, oder nur Benutzername und Passwort (unsicher!). Wireguard hingegen bietet keine weitere Möglichkeit das VPN abzusichern. Ein extremer Nachteil, denn jeder der Zugriff auf das Clientgerät (oder die dort hinterlegten Schlüssel) hat kann sich ohne weitere Legitimerung mit dem VPN verbinden, weshalb ich Wireguard aktuell nicht im geschäftlichen Umfeld sehe und die Verwendung nur dann empfehlen kann, wenn unlegitimierte Zugriffe bestmöglich ausgeschlossen werden können. Die Möglichkeit die Client App mit einem Passwort zu schützen gibt es zumindest bei Android und Windows derzeit nicht, das wäre schonmal ein Anfang. Als zusätzliche Sicherheitsebene ist es möglich einen Pre Shared Key (PSK) in Wireguard zu verwenden. Da ich hier keinen wirklichen Zugewinn an Sicherheit sehe verwende ich diesen nicht, Auswirkungen auf die Performance hätte dies aber nicht und würde den Verbindungsaufbau allenfalls marginal verzögern.
Allgemeines
Der Code von Wireguard wurde sehr schlank gehalten, was zum Einen für gute Performance und zum Anderen für hohe Sicherheit/ wenig Sicherheitslücken spricht, außerdem ist er im Gegensatz zu OpenVPN fest im Linux Kernel (ab v5.6) und FreeBSD (u.a.) integriert, sodass man auf darauf basierenden Geräten erneut einen Performanceschub erwarten kann. Die feste Integration in weiteren Betriebssystemen scheint in Arbeit zu sein, OpenVPN hingegen ist auch nach vielen Jahren in noch keinem Betriebssystem fest integriert. Außerdem wird dem Wireguard Protokoll weniger Overhead, also Zusatzinformationen die zusätzlich zu den eigentlichen Daten übertragen werden müssen, zugesprochen als OpenVPN, was ebenfalls für eine höhere Geschwindigkeit spricht.
[PRAXIS]
Einrichtung/ Konfig
Als eingesessener OpenVPN User fiel mir die Einrichtung von Wireguard gar nicht so leicht, natürlich spielt da viel Gewohnheit mit rein, aber allein die Tatsache, dass im Wireguard Protokoll mehrfach von "allowed Adresses" gesprochen wird, hat mir sehr zu schaffen gemacht, denn je nachdem an welcher Stelle davon gesprochen wird, hat es eine völlig andere Bedeutung: Mal wird hier die IP angegeben, die einem Client zugewiesen wird, und mal wird angegeben, welche Adressen oder Subnetze durch den Tunnel geroutet werden sollen. Somit hatte ich auch meine Schwierigkeiten, den Tunnel so zu konfigurieren, dass der gesamte Traffic darüber geroutet wird. Während man in OpenVPN lediglich einen Haken setzen oder den Befehl "redirect-gateway" in die Konfiguration einsetzten muss, scheint es in Wireguard partout keine Möglichkeit zu geben dies auf ähnlich einfache Weise zu gestalten, stattdessen muss die default Route durch entsprechende Einstellung unter "allowed Adresses" manuell übergangen werden. Ebensowenig finde ich weitere Informationen für erweiterte Konfigurationen, die aber allenfalls unter bestimmten Bedingungen benötigt werden. Ich habe hier keine weiteren Anforderungen, sodass ich bisher auch gut mit den Standardmöglichkeiten zurechtkomme.
Ich bin mir sicher, dass Wireguard nach etwas Eingewöhnung ebenfalls sehr einfach einzurichten ist, in OpenVPN muss man sich ja schließlich auch erstmal reinfuchsen und die Konfiguration gestaltet sich ob der vielen Optionen doch deutlich komplexer.
Geschwindigkeit
In einem VPN zählen vor allem zwei Dinge: Sicherheit und Geschwindigkeit.
Da ich der Sicherheit mangels Wissen nicht näher auf den Grund gehen kann, muss ich mich auf den Test der Geschwindigkeit beschränken.
Die Testsituation stellt sich wie folgt dar...
Server (OVPN und WG): Intel Atom E3845 (mit AES-NI), 4GB RAM, Bandbreite Internet 300/150Mbit/s
Client A1: Samsung Galaxy S20+, WLAN
Um etwaige Empfangsprobleme/ niedrige Bandbreiten im Mobilfunknetz ausschließen zu können, habe ich zunächst getestet, wie sich die Geschwindigkeit im WLAN darstellt, getestet wurde mit iperf3 in beide Richtungen (Download/ Upload).
(Bild 1: WLAN iperf3 Download)
(Bild 2: WLAN iperf3 Upload) Ohne VPN betrug der Download 418Mbit/s und der Upload 430Mbit/s,
bei OpenVPN 55/70 Mbit/s und
bei Wireguard 121/151 Mbit/s
Unter diesen Testbedingungen (kein Internet dazwischen) erzielt Wireguard also mehr als die doppelte Bandbreite, respekt!
Client A2: Samsung Galaxy S20+, 5G Mobilfunk
Der 5G Empfang war hier grenzwertig zu LTE+, die Geschwindigkeit des Netzes (ohne VPN) habe ich mittels Speedtest von Ookla gemessen, die VPN Geschwindigkeiten zusätzlich nochmal mit iperf3.
Bei den Bildern nicht wundern, die Messung ohne VPN weist eine LTE Verbindung aus, die beim Start der Messung nur kurz bestand, aber sofort auf 5G wechselte, diese Messung ist ohnehin eher informativ. Insgesamt ist das Mobilfunknetz an dem Standort und zu der Uhrzeit nicht sonderlich stabil (Dorfkind an der Autobahn 7
), daher erzielt WG auch bessere Ergebnisse als das Netz vermeintlich hergibt. Die Messung sollte aber aussagekräftig genug sein.(Bild 3: 5G Mobilfunk, Ookla)
(Bild 4: 5G Mobilfunk, iperf3) Ohne VPN betrug der Download 89Mbit/s und der Upload 36Mbit/s,
bei OpenVPN 24/11 Mbit/s (Ookla) und
bei Wireguard 45/39 Mbit/s (Ookla)
sowie
bei OpenVPN 11/19 Mbit/s (iperf3) und
bei Wireguard 20/28 Mbit/s (iperf3)
Auch hier erzielt Wireguard stets fast die doppelte Geschwindigkeit von OpenVPN. Auffällig ist hier der erhöhte Jitter (schwankende Latenz) sowie der damit zusammenhängende Paketverlust bei Wireguard, ich konnte dies aber nicht nochmal nachstellen und kann das Problem daher nicht auf das Wireguard Protokoll schieben, sondern vermute das Mobilfunknetz selbst als Verursacher.
Alles in allem kann man bereits jetzt sagen, dass das Wireguard Protokoll einen sehr deutlichen Geschwindigkeitsvorteil gegenüber OpenVPN hat. Etwaige Messtoleranzen, etc. dürften daran nichts mehr rütteln. Dennoch sind diese "praktischen" Messungen eher theoretischer Natur, da beide Messverfahren nicht die üblicherweise eingesetzten Dateiübertragungsprotokolle wie z.B. SMB oder FTP berücksichtigen, die ebenfalls durch den Tunnel laufen müssen. Dies werde ich (zumindest für SMB) zu einem anderen Zeitpunkt in einem anderen Erfahrungsbericht testen und euch daran teilhaben lassen. Auch ein Test mit einem potenteren PC (Stichwort AES-NI) über kabelgebundenes Internet steht noch aus.
Zuletzt bearbeitet:
