WireGuard: Das schlanke VPN-Protokoll – einfach erklärt

WireGuard ist ein modernes VPN-Protokoll, das bewusst klein, schnell und einfach zu prüfen sein soll. Statt jahrzehntelang gewachsener Parameterwelten setzt es auf wenige, aktuelle kryptografische Verfahren und einen Kernel-Treiber. Die Implementierung umfasst nur rund 4.000 Zeilen Code — ein Grund für die schnelle Verbreitung als Alternative zu IPsec und OpenVPN.

Wie es entstand

Entwickelt wurde WireGuard von Jason A. Donenfeld und ab 2015 veröffentlicht. Seit Linux-Kernel 5.6 (März 2020) ist der Code fester Bestandteil des Kernels, sodass unter Linux kein zusätzlicher Userspace-Dienst nötig ist. Ein VPN auf Protokollebene wird damit zu einem Kernel-Modul.

Die Kryptografie

Statt Auswahlmenüs für Dutzende Algorithmen gibt es genau einen Satz, der als sicher gilt:

  • Curve25519 für den Schlüsselaustausch (Elliptic-Curve-Diffie-Hellman).
  • ChaCha20-Poly1305 als AEAD-Verfahren zum Verschlüsseln und Authentifizieren in einem Schritt.
  • BLAKE2s als Hashfunktion und SipHash24 für die interne Hashtabelle.
  • Noise_IKpsk2 als Handshake-Muster — WireGuard nutzt damit das erprobte Noise Protocol Framework, das auch andere moderne Protokolle verwenden.

Cryptokey Routing statt Client und Server

WireGuard kennt keine Rollen „Client“ und „Server“. Jede Gegenstelle ist ein Peer, beschrieben durch zwei Angaben:

  • den öffentlichen Schlüssel des Gegenübers,
  • die erlaubten Adressen (AllowedIPs) — das sind zugleich die Ziele, die über diesen Peer geroutet werden.

Diese Zuordnung von öffentlichem Schlüssel zu Adressbereich heißt Cryptokey Routing. Sie wirkt in beide Richtungen: Sie bestimmt, wohin ausgehende Pakete gehen, und welche Quelladressen ein eingehendes Paket haben darf. Die Konfiguration selbst bleibt dadurch auf wenige Zeilen beschränkt.

Handshake und Betrieb

  • Der Handshake braucht nur einen Umlauf (1-RTT) und läuft über UDP, standardmäßig Port 51820.
  • Alle zwei Minuten wird das Schlüsselmaterial erneuert (Rekey), nach 180 Sekunden verfallen alte Schlüssel — das sorgt für Forward Secrecy.
  • Ein Cookie-Mechanismus mit den Feldern MAC1/MAC2 wehrt Handshake-Flutangriffe ab, indem der Responder einen Beweis der Erreichbarkeit verlangt, bevor er teure Rechenoperationen ausführt.
  • Roaming: Die aktuelle Adresse einer Gegenstelle lernt WireGuard aus dem jeweils letzten gültigen Paket. Wechselt ein Laptop vom WLAN ins Mobilfunknetz, läuft der Tunnel ohne Neuaufbau weiter.

Konfiguration in der Praxis

Profile liegen im INI-Format vor; die Werkzeuge wg und wg-quick verwalten sie. Typische Einträge sind PrivateKey, PublicKey, AllowedIPs, Endpoint und PersistentKeepalive. Schlüsselpaare erzeugt man direkt auf der Kommandozeile:

wg genkey | tee privatekey | wg pubkey > publickey

Ein Weg, mit dem ein Peer den Tunnel dauerhaft offen hält, ist PersistentKeepalive = 25 — nützlich hinter NAT, damit die Zuordnung nicht ausläuft (siehe NAT).

Wo WireGuard eingesetzt wird

  • Standort- und Server-Vernetzung: schlanke Site-to-Site-Tunnel, oft dort, wo IP-Tunnel sonst aufwendig zu konfigurieren wären.
  • Kubernetes: Container-Netzwerke wie Calico und Cilium können die Kommunikation zwischen den Nodes optional per WireGuard verschlüsseln.
  • Fernzugriff: Road-Warrior-Profile für Mitarbeiter, ähnlich wie bei OpenVPN.

Grenzen

WireGuard spricht ausschließlich UDP. In Netzen, die nur TCP über Port 443 zulassen, bleibt es damit außen vor — hier hilft eher ein TLS-basierter Tunnel. Ebenso vergibt WireGuard im Tunnel keine Adressen dynamisch: Die AllowedIPs werden fest eingetragen, ein Adressverteiler wie bei DHCP fehlt. Für klassische Einwahl-Szenarien mit Aushandlung existieren deshalb weiterhin L2TP und SSTP.

Verwandte Grundlagen: VPN, VPN-Grundlagen, Network Policies, IPsec-Befehle, OpenVPN-Befehle.