WireGuard ist kein vollständiger VPN-Dienst, sondern das Protokoll, mit dem ein Client und ein Server einen verschlüsselten Tunnel aufbauen. Der Entwurf verfolgt eine ungewöhnlich klare Idee: Ein öffentlicher Schlüssel wird fest mit den IP-Adressen verknüpft, die ein Teilnehmer innerhalb des Tunnels verwenden darf. Das Protokoll kümmert sich um Authentifizierung, Schlüsselaustausch und den sicheren Transport von IP-Paketen. Kontoerstellung, Serverauswahl, DNS, Kill-Switch und No-Logs-Richtlinie liegen außerhalb seines Umfangs und müssen vom VPN-Anbieter ergänzt werden.
Diese enge Aufgabe ist ein Grund für WireGuards Ruf. Das technische Whitepaper beschreibt eine Linux-Implementierung mit weniger als 4.000 Codezeilen. Die Zahl ist kein automatischer Sicherheitsbeweis, aber eine kleine, klar abgegrenzte Codebasis lässt sich leichter vollständig prüfen als ein System mit vielen optionalen Betriebsarten. Seit Linux 5.6 ist WireGuard direkt im Kernel enthalten. Für Windows, macOS, iOS, Android und weitere Systeme gibt es offizielle oder unterstützte Implementierungen.
Wie WireGuard funktioniert
WireGuard erscheint im Betriebssystem als virtuelle Netzwerkschnittstelle, zum Beispiel wg0. Der Administrator hinterlegt für jeden Peer einen öffentlichen Schlüssel, eine erreichbare Serveradresse und die erlaubten Tunnel-IP-Adressen. Die Routing-Tabelle schickt passende Pakete an diese Schnittstelle. WireGuard verschlüsselt und authentifiziert das vollständige innere IP-Paket und transportiert es als UDP-Paket zum anderen Peer.
Der erste Austausch stellt Sitzungsschlüssel her. Danach können Daten in beide Richtungen fließen. WireGuard erneuert die Schlüssel automatisch in kurzen Abständen und behandelt Paketverlust, Roaming sowie erneute Handshakes über eine eigene Zeitsteuerung. Wechselt ein Smartphone vom WLAN ins Mobilfunknetz, kann der Server den neuen authentifizierten Endpunkt übernehmen, ohne dass der Nutzer eine neue Sitzung einrichten muss.
Ein Peer akzeptiert ein entschlüsseltes Paket nur, wenn dessen innere Absenderadresse zu dem öffentlichen Schlüssel passt. WireGuard nennt dieses Prinzip Cryptokey Routing. Es verbindet Routing und Identität: Der Schlüssel beantwortet nicht nur die Frage „Wer hat dieses Paket gesendet?“, sondern auch „Welche Tunneladresse darf dieser Teilnehmer verwenden?“.
Welche Verschlüsselung verwendet WireGuard?
WireGuard bietet keine lange Auswahlliste alter und neuer Algorithmen. Die kryptografische Suite ist fest vorgegeben:
- ChaCha20 verschlüsselt den Datenstrom.
- Poly1305 erkennt Manipulationen an den verschlüsselten Daten.
- Curve25519 dient dem elliptischen Diffie-Hellman-Schlüsselaustausch.
- BLAKE2s wird als Hashfunktion eingesetzt.
- HKDF leitet getrennte Schlüssel für einzelne Zwecke ab.
ChaCha20 und Poly1305 bilden zusammen ein AEAD-Verfahren. AEAD bedeutet, dass Vertraulichkeit und Integrität gemeinsam geprüft werden. Ein Angreifer soll also weder den Inhalt lesen noch ein Paket unbemerkt verändern können. RFC 8439 dokumentiert ChaCha20-Poly1305 mit einem 256-Bit-Schlüssel. Die Sicherheit eines WireGuard-Tunnels beruht dennoch auf dem gesamten Handshake und seiner Implementierung, nicht allein auf dieser Zahl.
Die Schlüssel werden regelmäßig erneuert. Dadurch besitzt das Protokoll Forward Secrecy: Wird ein langfristiger privater Schlüssel später entwendet, lassen sich zuvor aufgezeichnete Sitzungen nicht allein damit nachträglich entschlüsseln. Die offizielle Protokolldokumentation und formale Analysen führen diese Eigenschaft ausdrücklich auf. Mehr zum Unterschied zwischen Datenverschlüsselung, Schlüsselaustausch und Forward Secrecy erklärt unser Artikel zu VPN-Verschlüsselung.
Warum WireGuard häufig schnell ist
WireGuard transportiert Daten ausschließlich über UDP und vermeidet eine große Zahl von Aushandlungsoptionen. Unter Linux arbeitet die Implementierung direkt im Kernel. Das spart Wechsel zwischen Nutzerbereich und Kernel, die bei älteren OpenVPN-Installationen zusätzlichen Aufwand verursachen können. ChaCha20 ist außerdem auf Geräten ohne spezielle AES-Beschleunigung effizient in Software ausführbar.
Das macht hohe Geschwindigkeiten möglich, garantiert sie aber nicht. Der tatsächliche Durchsatz hängt von Anschluss, CPU, Serverauslastung, Entfernung, Peering, Paketgröße und Konfiguration ab. Ein Anbieter kann WireGuard anbieten und trotzdem langsam sein. Umgekehrt kann ein gut angebundener OpenVPN-Server für einen bestimmten Weg schneller ausfallen.
Unser Messsystem behandelt Geschwindigkeit deshalb als fortlaufende Reihe. Es prüft die eingerichteten Anbieter mehrmals täglich und speichert Protokoll, Endpunkt, Zeitpunkt sowie den automatisch gewählten Speedtest-Server. Der sichtbare Wert eines Testberichts wird aus bis zu 20 aktuellen, technisch nachvollziehbaren Messungen über einen deutschen Endpunkt berechnet. Die aktuellen hide.me-Messwerte und ihr Verlauf ersetzen damit die Momentaufnahme eines einzelnen Inbetriebnahmelaufs.
WireGuard und OpenVPN im Vergleich
OpenVPN ist älter und wesentlich flexibler. Es kann UDP oder TCP verwenden, verschiedene Datenkanal-Chiffren aushandeln und lässt sich in vielen ungewöhnlichen Netzen betreiben. Der aktuelle OpenVPN-2.6-Client bevorzugt AEAD-Verfahren wie AES-256-GCM, AES-128-GCM und, falls verfügbar, ChaCha20-Poly1305. Die pauschale Gegenüberstellung „WireGuard modern, OpenVPN unsicher“ wäre daher falsch.
WireGuard setzt dagegen auf eine kleine, feste Protokolloberfläche. Verbindungen starten meist schneller, und mobile Netzwechsel funktionieren elegant. OpenVPN über TCP kann dort nützlich sein, wo UDP gesperrt wird. WireGuard selbst enthält keine Tarnung gegen Deep Packet Inspection und keinen TCP-Modus. In restriktiven Netzen braucht der Anbieter deshalb eine zusätzliche Verschleierungsschicht oder ein alternatives Protokoll.
Für die meisten Nutzer ist WireGuard die sinnvolle erste Einstellung, wenn der Anbieter es sauber integriert. OpenVPN bleibt eine brauchbare Ausweichmöglichkeit, wenn Kompatibilität oder Netzwerkfilter wichtiger sind als maximaler Durchsatz.
Die Datenschutzfrage bei kommerziellen VPNs
Eine einfache WireGuard-Konfiguration ordnet einem öffentlichen Schlüssel dauerhaft eine interne Tunnel-IP zu. Ein kommerzieller Dienst muss zusätzlich verhindern, dass daraus ein langfristig verknüpfbares Nutzerprotokoll entsteht. Dafür gibt es mehrere Architekturen: kurzlebige Schlüssel, getrennte Zuordnungsdienste, dynamische Adressen oder NAT-Schichten, die Konto und Ausgangsverkehr auseinanderhalten.
WireGuard schreibt keine dieser Lösungen vor. Deshalb sagt das Logo in einer App noch nichts darüber, wie lange Schlüssel, interne Adressen oder Zeitstempel gespeichert werden. Wir prüfen die technische Erklärung des Anbieters, den Umfang veröffentlichter Audits und die konkreten Aussagen in der Datenschutzrichtlinie. Ein Protokoll kann kryptografisch solide sein und trotzdem von einem Betreiber mit schlechter Datensparsamkeit eingesetzt werden.
Auch DNS gehört nicht automatisch zu WireGuard. Eine Konfigurationsdatei kann einen Resolver nennen, doch das Betriebssystem oder die App muss diese Einstellung korrekt anwenden und beim Tunnelabbruch absichern. Unser DNS-Leak-Test prüft das Ergebnis statt der Werbeaussage.
Wie wir WireGuard prüfen
Unser Messstand isoliert jeden Anbieter in einem eigenen Netzwerk-Namespace. Danach erfasst er Download, Upload und Latenz mit eindeutig bezeichnetem Protokoll und Endpunkt. Fehlgeschlagene Verbindungen werden als Fehler gespeichert, nicht aus der Reihe entfernt oder durch Ersatzwerte aufgefüllt.
Das automatische System kontrolliert die erreichbare Ausgangs-IP und zeichnet auf, ob IPv6 über die Verbindung erreichbar ist. Beides beweist für sich allein noch keinen vollständigen Leak-Schutz. Die Zuordnung von DNS-Resolvern sowie IPv6- und WebRTC-Lecks prüfen wir deshalb getrennt mit den Browserwerkzeugen. Ergebnisse aus dem Messsystem und aus dem praktischen App-Test bleiben als unterschiedliche Belege erkennbar.
Auf Geräten mit Anbieter-App testen wir zusätzlich Serverwechsel, Aufwachen aus dem Standby und den Wechsel zwischen WLAN und Mobilfunk. Ein schneller Handshake ist nur dann nützlich, wenn während des Übergangs kein Verkehr außerhalb des Tunnels fließt.
Worauf Sie achten sollten
- Wählen Sie in der App ausdrücklich WireGuard oder die klar benannte WireGuard-Variante des Anbieters.
- Prüfen Sie nach dem Verbinden IP, DNS und IPv6. Der Protokollname allein garantiert keine vollständige Route.
- Aktivieren Sie den Kill-Switch, besonders bei Dateiübertragungen oder häufigen Netzwechseln.
- Suchen Sie nach einer technischen Erklärung zur Schlüssel- und Adressverwaltung. Reines Marketing beantwortet die Datenschutzfrage nicht.
- Behalten Sie OpenVPN oder ein verschleiertes Protokoll als Alternative, wenn ein Netz UDP oder erkennbare WireGuard-Pakete blockiert.
Häufige Irrtümer und Grenzen
„WireGuard ist automatisch schneller als jedes andere Protokoll.“ Nein. Der Entwurf reduziert Aufwand, die reale Strecke und der Server bleiben aber entscheidend.
„Weniger Code bedeutet keine Sicherheitslücken.“ Nein. Kleine Software ist leichter zu prüfen, kann aber trotzdem Fehler enthalten. Relevant sind zusätzlich formale Analysen, Tests, Updates und die Integration durch den Anbieter.
„WireGuard speichert zwangsläufig Nutzerdaten.“ Das Protokoll hält notwendige Peer-Zustände im Arbeitsspeicher. Ob daraus dauerhafte, kontobezogene Protokolle werden, entscheidet die Architektur des Dienstes.
„WireGuard tarnt die VPN-Nutzung.“ Nicht von sich aus. Die offizielle Dokumentation nennt fehlende Verschleierung ausdrücklich als bekannte Grenze.
Quellen
- Jason A. Donenfeld: WireGuard, Next Generation Kernel Network Tunnel, technisches Whitepaper
- WireGuard: Protocol and Cryptography und Conceptual Overview
- WireGuard: Formal Verification und Known Limitations
- IETF: RFC 8439 zu ChaCha20-Poly1305
- OpenVPN: OpenVPN 2.6 Manual zum Protokollvergleich