WireGuard verstehen: Funktionsweise und Entwicklung

Vor WireGuard hieß die übliche Wahl IPsec oder OpenVPN. IPsec ist eine große Familie von Standards mit unzähligen Einstellungen, und die Zusammenarbeit zwischen verschiedenen Herstellern ist berüchtigt mühsam. OpenVPN läuft im Benutzerbereich und hängt an einer umfangreichen TLS-Bibliothek – flexibel, aber langsam. Bei beiden ist der Code so umfangreich, dass ihn kaum jemand vollständig prüfen kann.

WireGuard dreht das um: nur eine Sache machen, und die richtig. Im System erscheint es als virtuelle Netzwerkkarte (etwa wg0). Sie geben dieser Karte Ihren privaten Schlüssel und die öffentlichen Schlüssel einiger Gegenstellen; Pakete, die Sie an sie schicken, werden verschlüsselt versendet, empfangene Pakete kommen entschlüsselt aus ihr heraus. Alles Übrige – Routing, Firewall, Adressvergabe – überlässt es den Werkzeugen, die das System ohnehin hat.

Was es bewusst nicht tut, ist ebenso klar: keine Aushandlung von Algorithmen, keine Verwaltung von Benutzernamen und Passwörtern, keine Adressvergabe, keine Tarnung des Verkehrs. Diese Dinge gelten entweder als Quelle von Sicherheitslücken oder werden Werkzeugen auf einer höheren Ebene überlassen.

In WireGuard hat jedes Gerät ein Schlüsselpaar, und der öffentliche Schlüssel ist seine Identität – ähnlich wie bei SSH: Tragen beide Seiten den öffentlichen Schlüssel der jeweils anderen in ihre Konfiguration ein, besteht Vertrauen. Keine Zertifikate, keine Benutzernamen und Passwörter.

In der Konfiguration erhält jede Gegenstelle einen Eintrag „erlaubte Adressen“ (AllowedIPs). Er gilt in beide Richtungen: Beim Senden wird das Paket mit dem öffentlichen Schlüssel der Gegenstelle verschlüsselt, in deren erlaubten Bereich die Zieladresse fällt, und an sie geschickt. Beim Empfangen wird nach dem Entschlüsseln geprüft, ob die Absenderadresse im erlaubten Bereich dieser Gegenstelle liegt – wenn nicht, wird das Paket verworfen. Dieses Verfahren heißt Cryptokey-Routing: Routingtabelle und Zugriffskontrolle werden zu einer einzigen Tabelle.

Tragen Sie für eine Gegenstelle also 0.0.0.0/0 als erlaubte Adressen ein, heißt das „aller Verkehr geht an sie“ – das, was man gemeinhin ein globales VPN nennt. Tragen Sie nur ein internes Netzsegment ein, läuft nur der Zugriff auf dieses Segment durch den Tunnel.

Bevor zwei Geräte zum ersten Mal kommunizieren, findet ein Handshake statt: Der Initiator schickt ein Paket, der Empfänger antwortet mit einem Paket – nach einem Hin und Her ist alles erledigt, und beide Seiten haben einen Satz Sitzungsschlüssel, der nur für diesen Zeitraum gilt. Der Handshake beruht auf dem Noise-Protokoll-Framework: Die langfristigen Schlüssel beider Seiten authentifizieren sich gegenseitig, temporäre Schlüssel sorgen für Forward Secrecy – selbst wenn der langfristige private Schlüssel später bekannt wird, lässt sich früher mitgeschnittener Verkehr nicht entschlüsseln.

Die Sitzungsschlüssel werden alle paar Minuten automatisch gewechselt; davon merkt der Nutzer nichts, und ein „Neuverbinden“ gibt es nicht.

Die Algorithmen sind fest: Curve25519 für den Schlüsselaustausch, ChaCha20-Poly1305 für die Datenverschlüsselung, BLAKE2s als Hashfunktion. Es wird nichts ausgehandelt, und damit gibt es auch keine Downgrade-Angriffe – ein Angreifer kann die beiden Seiten nicht dazu bringen, auf schwächere Algorithmen auszuweichen. Sollte einer dieser Algorithmen eines Tages gebrochen werden, kommt eine neue Protokollversion, die das Ganze ersetzt, statt einer zusätzlichen Option.

Zusätzlich lässt sich ein vorab geteilter Schlüssel (Pre-Shared Key) hinzufügen, der mit dem Verfahren der öffentlichen Schlüssel kombiniert wird – als Vorsorge gegen eine künftige Bedrohung der Public-Key-Verfahren durch Quantencomputer.

• Nur UDP: WireGuard verschlüsselt jedes Datenpaket einzeln und verschickt es in einem UDP-Paket. Auf TCP wird bewusst verzichtet – läuft TCP in TCP, wiederholen beide Ebenen Übertragungen, und bei Paketverlust bremsen sie sich gegenseitig aus.
• Keine Antwort an Fremde: Auf Pakete, die die Authentifizierung nicht bestehen, antwortet es grundsätzlich nicht. Für jemanden, der Ports scannt, wirkt der Port geschlossen; dass dort WireGuard läuft, ist nicht zu erkennen.
• Roaming: WireGuard kennt keine „Verbindung“, nur öffentliche Schlüssel. Wechselt die Gegenstelle ihre Adresse – das Handy geht vom WLAN ins Mobilfunknetz –, genügt es, dass ihr nächstes Paket die Authentifizierung besteht, und die Antworten gehen automatisch an die neue Adresse. Deshalb reißt der Tunnel beim Netzwechsel nicht ab.
• Ruhe: Gibt es nichts zu senden, erzeugt der Tunnel keinerlei Verkehr – auf dem Handy spart das viel Akku. Nur wenn ein Gerät hinter einem Router sitzt und trotzdem jederzeit für die Gegenseite erreichbar sein muss, schalten Sie das regelmäßige Keepalive (PersistentKeepalive) ein, das alle paar Dutzend Sekunden ein kleines Paket schickt, um die Zuordnung im Router aufrechtzuerhalten.

• Es läuft im Kernel: Unter Linux ist WireGuard ein Kernelmodul, Pakete müssen nicht zwischen Kernel und Benutzerprogramm hin- und herkopiert werden; OpenVPN läuft traditionell im Benutzerbereich, und jedes Paket nimmt einen zusätzlichen Umweg.
• Algorithmen für jede CPU: ChaCha20 braucht keine speziellen Hardwarebefehle zur Beschleunigung und ist besonders auf Chips ohne AES-Befehle im Vorteil, wie in Handys und Routern.
• Kurzer Handshake: Nach einem Hin und Her können Daten fließen, der Verbindungsaufbau kostet kaum Wartezeit.
• Wenig Code: Die Wege sind kurz, und jede mögliche Optimierung steckt in den wenigen entscheidenden Schritten.
• Beachten Sie: Das alles betrifft den Aufwand von Protokoll und Implementierung selbst. Das tatsächliche Tempo auf grenzüberschreitenden Strecken hängt mehr vom Paketverlust der Leitung und davon ab, wie der Netzbetreiber mit UDP umgeht.

• Um 2015: Jason A. Donenfeld beginnt mit der Entwicklung von WireGuard und veröffentlicht es, zunächst als eigenständiges Kernelmodul für Linux.
• 2017: Das Papier, das sein Design beschreibt, erscheint auf der Sicherheitskonferenz NDSS; das Protokoll durchläuft danach mehrere unabhängige formale Verifikationen. Etwa zur selben Zeit beginnen VPN-Anbieter wie Mullvad, Zugang über WireGuard anzubieten.
• 2018: Linus Torvalds, der Schöpfer von Linux, lobt den Code auf der Mailingliste und nennt ihn im Vergleich zu OpenVPN und IPsec geradezu ein Kunstwerk – ein Satz, der WireGuard unter Entwicklern weithin bekannt macht.
• 2019: Cloudflare veröffentlicht BoringTun, eine in Rust geschriebene Implementierung für den Benutzerbereich, und setzt WireGuard für sein WARP ein; NordVPN bringt das auf WireGuard basierende NordLynx heraus; auch Tailscale startet in dieser Zeit mit WireGuard als Datenebene.
• März 2020: WireGuard wird mit Linux 5.6 offiziell in die Hauptlinie des Kernels aufgenommen, zugleich erscheint Version 1.0. Seitdem bringen die gängigen Linux-Distributionen WireGuard mit, ein Modul muss nicht mehr separat installiert werden. Im selben Jahr nimmt auch OpenBSD es in seinen Kernel auf.
• 2021: Für Windows erscheint mit WireGuardNT eine Implementierung im Kernel, deutlich schneller als die bisherige im Benutzerbereich; FreeBSD bekommt danach ebenfalls eine Kernel-Implementierung.
• Heute: Für Windows, macOS, Linux, iOS und Android gibt es offizielle Clients, Router- und NAS-Systeme wie OpenWrt und Synology unterstützen es meist von Haus aus, und die allermeisten kommerziellen VPNs führen es als Standard- oder Wahlprotokoll.

• Keine Schlüsselverteilung: Für jedes neue Gerät muss dessen öffentlicher Schlüssel in die Konfiguration der anderen Geräte eingetragen werden. Bei vielen Geräten wird das unübersichtlich – genau deshalb gibt es Werkzeuge wie Tailscale.
• Keine dynamische Adressvergabe: Die interne Adresse jeder Gegenstelle steht fest in der Konfiguration; einen Mechanismus wie bei OpenVPN, der nach dem Verbinden eine Adresse zuteilt, gibt es nicht. Kommerzielle VPNs, die es nutzen, müssen darum herum eine eigene Schicht bauen.
• Bedenken beim Datenschutz: Der Server muss sich die zuletzt genutzte öffentliche Adresse jeder Gegenstelle merken, um antworten zu können. VPN-Anbieter mit Anspruch auf „keine Protokolle“ müssen das meist zusätzlich behandeln (etwa durch regelmäßiges Löschen oder doppelte Adressumsetzung).
• Nur UDP: In Netzen, die UDP sperren oder drosseln, verbindet es nicht oder ist sehr langsam. Soll es über TCP oder Port 443 laufen, geht das nur mit einem weiteren Werkzeug drumherum.
• Keine Tarnung: Format und Länge von Handshake- und Datenpaketen haben feste Merkmale und sind leicht zu erkennen. Sein Designziel sind Sicherheit und Einfachheit, nicht das Umgehen von Zensur.
• Kein Kontosystem: Benutzernamen, Passwörter oder Ablaufdaten kennt das Protokoll nicht – es erkennt nur öffentliche Schlüssel.

• Codeumfang: Der Kern von WireGuard umfasst einige tausend Zeilen; OpenVPN samt der TLS-Bibliothek, von der es abhängt, und die verschiedenen IPsec-Implementierungen liegen in der Größenordnung von Hunderttausenden.
• Transport: WireGuard nur UDP; OpenVPN beides, auch TCP 443 auf dem Port des HTTPS-Verkehrs; IPsec nutzt eine eigene Protokollnummer sowie UDP 500/4500.
• Konfiguration: WireGuard ein paar Zeilen pro Gegenstelle; die Konfigurationsdateien von OpenVPN haben viele Optionen, sind aber sehr flexibel; IPsec ist am kompliziertesten.
• Leistung: In sauberen Netzen ist WireGuard meist am schnellsten und sparsamsten; OpenVPN hat in neueren Versionen ebenfalls eine Kernel-Beschleunigung (DCO), der Abstand schrumpft.
• Funktionen: Anmeldung mit Benutzername und Passwort, dynamische Vergabe von Adressen und Routen, Betrieb über TCP – das bringt OpenVPN mit, bei WireGuard muss es ein äußeres System ergänzen.
• Geräteunterstützung: OpenVPN gibt es schon lange, alte Router, NAS und alle möglichen eingebetteten Geräte verstehen es fast immer; WireGuard ist auf Systemen der letzten Jahre verbreitet, auf alten Geräten aber nicht unbedingt vorhanden.

• Tailscale: ergänzt WireGuard um Anmeldung, Schlüsselverteilung, NAT-Traversal und Relais und macht daraus ein automatisches Netzwerk, siehe Tailscale verstehen. Headscale ist eine quelloffene Implementierung seines Steuerungsservers.
• Netmaker, NetBird, Firezone und andere: ebenfalls Netzwerk- oder Zero-Trust-Produkte nach dem Muster „WireGuard als Datenebene, eigene Verwaltungsebene“.
• Cloudflare WARP: ein WireGuard-Client für Privatnutzer, der den Verkehr ins Netz von Cloudflare schickt.
• Eigene Verpackungen kommerzieller VPNs: NordLynx und andere legen eine Schicht für Adressvergabe und Datenschutz um WireGuard.
• Abwandlungen wie AmneziaWG: verändern Paketköpfe und Auffüllung, um die festen Merkmale von WireGuard zu verbergen, für streng kontrollierte Netze; mit Standard-WireGuard-Clients sind sie nicht kompatibel.

• Ob es funktioniert, hängt zuerst an UDP: Viele Festnetz- und Mobilfunknetze drosseln UDP bei großen Datenmengen – direkt nach dem Verbinden ist es schnell, nach einer Weile wird es langsam, oder es ruckelt abends deutlich.
• Direkte grenzüberschreitende Verbindungen werden leicht erkannt: Die Handshake-Pakete von WireGuard haben feste Merkmale und können auf grenzüberschreitenden Strecken erkannt und gestört werden – der Handshake kommt dann nicht zustande, oder der Datenfluss reißt nach einer Weile ab. Das ist die direkte Folge der fehlenden Tarnung.
• Netze zwischen Geräten innerhalb Chinas (Büro und Zuhause, Handy und NAS) laufen nicht über grenzüberschreitende Strecken und haben dieses Problem meist nicht; sie hängen nur von UDP-Drosselung und dem Erfolg des NAT-Traversals ab.
• Es eignet sich daher eher für Netzwerke zwischen eigenen Geräten und Fernzugriff; für dauerhaft stabile grenzüberschreitende Verbindungen braucht es eine getarnte Verbindungsart oder eine, die über TCP/TLS läuft. Einen Vergleich der Protokolle finden Sie in VPN-Protokolle im Vergleich.

Die Verbindungsart „Privat“ von LeoTun nutzt Tailscale, und dessen Datenebene ist WireGuard: Die Tunnel zwischen Ihren Geräten und die Tunnel zu den Ausgangsknoten der Regionen verschlüsselt und überträgt WireGuard. Sie müssen keine Schlüssel erzeugen und keine Konfiguration schreiben – das erledigt der Client, nachdem Sie sich mit Ihrem Konto dieser Website angemeldet haben. Wie es geht, steht in Was Privat (Tailscale) ist, der Einstieg liegt auf der Seite „Privat“.

Neben „Privat“ bietet dasselbe Konto Verbindungsarten, die nicht auf UDP angewiesen sind: Cisco (AnyConnect) läuft über TLS, OpenVPN kann über TCP laufen, und Hiddify (Hysteria2) ist speziell auf Paketverlust ausgelegt. Ist „Privat“ in Ihrem Netz langsam und instabil, wechseln Sie einfach die Verbindungsart, siehe Welche Verbindungsart wofür.