OpenVPN oder WireGuard? Entschieden wird über Identität und Transport

Der Vergleich dieser beiden Protokolle ist nur nützlich, wenn er das vergleicht, was Sie tatsächlich betreiben werden. WireGuard identifiziert Peers über einen öffentlichen Schlüssel und führt sein Protokoll über UDP, während OpenVPN einen breiteren Satz an Authentifizierungsverfahren bietet und über UDP oder TCP laufen kann, wenn der Server beides anbietet. Diese Unterschiede prägen Bereitstellung und Ausweichweg weit früher, als sie den Durchsatz prägen. Führen Sie die vier Prüfungen unten der Reihe nach aus; die ersten beiden entscheiden meist die Wahl, und die letzten beiden sagen, ob die Entscheidung richtig war.

Beginnen Sie mit der Identität, nicht mit der Cipher-Liste

Ein WireGuard-Peer speichert einen privaten Schlüssel und listet die öffentlichen Schlüssel auf, die er erreichen darf. Ein Anbieter kann darum ein Kundenportal legen, aber das Protokoll selbst kennt keinen Austausch von Benutzername und Passwort, also lebt der Kontolebenszyklus in dem, was die Schlüssel verteilt. OpenVPN kann Zertifikate, ein Plugin gegen ein bestehendes Verzeichnis oder ein Prüfskript verwenden, weshalb Organisationen mit einem Identitätssystem es oft vorziehen. Keines der beiden Designs beseitigt die Frage, wie ein verlorenes Gerät entfernt wird.

Eine kurze Konfiguration ist nicht dasselbe wie einfache Bereitstellung. Einen privaten Schlüssel an mehrere Personen auszugeben, macht die spätere Entfernung mehrdeutig, weil sein Widerruf alle auf einmal entfernt. Schreiben Sie die Zuordnung von Person zu Schlüssel oder Zertifikat vor der Wahl auf, und die Protokollentscheidung wird deutlich leichter.

Schauen Sie dann, was der Transport erlaubt

Das Protokoll von WireGuard nutzt UDP. OpenVPN-Dienste können sowohl UDP- als auch TCP-Profile anbieten, und in einem Netz, das UDP blockiert oder drosselt, ist die zweite Option ein praktischer Ausweichweg und kein theoretischer. Der Server muss das gewählte Profil unterstützen, und eine andere Portnummer macht den Tunnel nicht zu HTTPS und überzeugt keine Firewall, ihn durchzulassen.

TCP in TCP zu führen ändert auch das Verhalten bei Verlust, weil beide Schichten unabhängig wiederholen und umsortieren. Ein TCP-Profil, das in einem restriktiven Netz funktioniert, kann in einem verlustbehafteten trotzdem schlecht abschneiden, und das ist ein Grund, beide Profile verfügbar zu halten, statt eines für überlegen zu erklären.

Prüfen Sie dann Routing und Namensauflösung

AllowedIPs in WireGuard ordnet Adressbereiche Peers zu und wirkt als Routingentscheidung innerhalb des Protokolls, und die umgebenden Werkzeuge verwenden diese Bereiche, wenn sie Routen installieren. OpenVPN schiebt Routen und DNS-Optionen vom Server. In beiden Fällen kann der Client hochkommen, während die beabsichtigte Richtlinie nur halb angewendet ist.

ip route show
ip -6 route show
resolvectl status
wg show

Lesen Sie die Ausgabe, bevor Sie der Verbunden-Anzeige trauen. ip route show listet, was der Client für IPv4 installiert hat, und die IPv6-Variante erwischt einen Tunnel, der nur eine Familie führt. resolvectl status zeigt, welchen Resolver der Client tatsächlich fragt, und wg show druckt die AllowedIPs, die WireGuard für seine hält. Wenn der Resolver weiter auf das lokale Netz zeigt, während die Routen volle Abdeckung behaupten, verlässt DNS den Tunnel.

Messen Sie dann die Aufgabe, auf die es ankommt

Halten Sie Gerät, Netz und Ziel konstant und notieren Sie die verwendeten Clients und Endpunkte. Wenn die beiden Dienste in verschiedenen Städten austreten oder auf unterschiedlicher Hardware laufen, sagen Sie es, denn dann beschreibt das Ergebnis diese Dienste und nicht die Protokolle.

iperf3 -c 203.0.113.20 -t 30
mtr -rwzbc 50 203.0.113.20

Führen Sie beide Befehle zweimal aus, einmal pro Profilpaar, im selben Netz und auf demselben Gerät. iperf3 liefert eine Durchsatzzahl und mtr liefert den Pfad und wo Verlust auftritt, was eine einzelne Downloadzahl nicht zeigen kann. Eine Downloadzahl übersieht auch, was ein Gespräch bemerkt: zusätzliche Latenz, Jitter und wie lange eine Wiederverbindung dauert. Notieren Sie das getrennt, denn ein Protokoll, das beim Durchsatz gewinnt, kann bei der Aufgabe, die Sie tatsächlich ausführen, trotzdem verlieren.

Bei einer verwalteten Verbindung können Kompatibilität, Support und Erneuerungsaufwand einen kleinen Benchmarkunterschied aufwiegen. Bei einem persönlichen Ausgang zählen Protokollierung und Jurisdiktion des Betreibers mehr als das Protokolletikett. Beide Protokolle können eine gute Verbindung tragen; der Dienst und seine Konfiguration entscheiden, was Sie bekommen.

Schreiben Sie das Profilpaar vor dem Test auf

Wählen Sie vor dem Messen ein Profil pro Protokoll und schreiben Sie auf, was jedes leisten soll: nur private Subnetze oder der gesamte Verkehr über einen bestimmten Ausgang. Ein Test, der ein Split-Tunnel-Profil mit einem Full-Tunnel-Profil vergleicht, misst die Profile, nicht die Protokolle. Setzen Sie Clientname, Clientversion und Ausgangsstandort in dieselbe Notiz.

Führen Sie dann dieselbe Aufgabe auf beiden aus, im selben Netz, in derselben Sitzung. Wenn eines gar keine Verbindung aufbaut, ist dieses Scheitern das Ergebnis und gehört mit dem Grund in den Datensatz. Bewahren Sie den Datensatz bei der Dienstdokumentation auf, damit die nächste Person dasselbe Paar vergleicht, statt von vorn zu beginnen.