Netzwerk & WAN
WireGuard
WireGuard ist ein modernes VPN mit schlanker, formal geprüfter Kryptografie; verschlüsselte Tunnel über einen UDP-Port, im Linux-Kernel integriert.
- Fester, geprüfter Krypto-Stack
- Cryptokey Routing
- Schlanker Kernel-Code
- Roaming ohne Abbruch
- Ein UDP-Port
WireGuard ist ein VPN-Protokoll, das bewusst klein und meinungsstark gebaut ist. Statt einer breiten Auswahl aushandelbarer Verfahren legt es seine Kryptografie fest, kommt mit wenigen tausend Zeilen Code aus und ist seit Kernel 5.6 fester Bestandteil von Linux. Das Ergebnis ist ein Tunnel, der schnell aufbaut, wenig Overhead hat und gut zu prüfen ist.
Dieser Artikel erklärt den festen Krypto-Stack und warum es keine Aushandlung gibt, das zentrale Konzept des Cryptokey Routing über AllowedIPs, Transport, Roaming und das stille Verhalten gegenüber Unbefugten, das Handshake- und Keepalive-Timing, den MTU-Overhead sowie die bewusste Lücke bei Schlüsselverwaltung und dynamischem Routing.
1. Klein, fest, geprüft
WireGuard verzichtet auf die übliche Vielfalt aushandelbarer Cipher. Der Krypto-Stack ist im Protokoll fest verdrahtet, aufgebaut auf dem Noise-Framework: Curve25519 für den Schlüsselaustausch, ChaCha20-Poly1305 für die authentifizierte Verschlüsselung, BLAKE2s zum Hashen. Weil nichts ausgehandelt wird, gibt es auch keinen Downgrade-Angriff auf ein schwaches Verfahren.
Dazu kommt die geringe Größe: Die Kernel-Implementierung umfasst nur einige tausend Zeilen, was die Angriffsfläche klein und ein Audit überschaubar hält. Das Protokoll selbst wurde zudem in mehreren Modellen formal verifiziert.
Die bewusste Beschränkung ist das Sicherheitsmerkmal: ein fester, moderner Krypto-Stack und wenig Code lassen weniger Raum für Fehlkonfiguration und Schwachstellen.
2. Cryptokey Routing: AllowedIPs
Das Herzstück von WireGuard ist das Cryptokey Routing. Jeder Gegenstelle (Peer) ist ihr öffentlicher Schlüssel zugeordnet, und zu jedem Schlüssel gehört eine Liste erlaubter IP-Bereiche (AllowedIPs). Beim Senden wählt WireGuard anhand der Zieladresse den passenden Schlüssel, beim Empfangen verwirft es ein Paket, dessen Quelladresse nicht zu den AllowedIPs des Absenders passt.
Damit ist AllowedIPs gleichzeitig Routing-Entscheidung und Zugriffskontrolle, ein separates Regelwerk entfällt. Die Zuordnung von Schlüssel zu erlaubten Adressen ist statisch; allein der äußere Endpunkt eines Peers darf sich ändern, was das Roaming ermöglicht.
3. Transport, Roaming und Stille
WireGuard läuft ausschließlich über UDP, standardmäßig auf Port 51820, und kennt keine festen Server- oder Client-Rollen: Wer zuerst Verkehr hat, baut den Tunnel auf. Auf ein Paket ohne gültigen Handshake antwortet es mit gar nichts, für einen Portscanner ist der Port nicht von einem geschlossenen zu unterscheiden.
Beim Roaming aktualisiert WireGuard den gespeicherten Endpunkt eines Peers, sobald von dort ein gültiges Paket kommt. Ein Laptop, der von WLAN auf Mobilfunk wechselt, bleibt verbunden, ohne sich neu anzumelden, sobald das nächste Paket eintrifft.
4. Handshake, Keepalive und NAT
Bei aktivem Verkehr erneuert WireGuard die Sitzungsschlüssel etwa alle zwei Minuten und sorgt so für Forward Secrecy. Von sich aus sendet es keinen Leerlaufverkehr. Sitzt ein Peer hinter NAT und soll erreichbar bleiben, hält die Option PersistentKeepalive (üblich 25 Sekunden) den NAT-Eintrag offen.
Server-Konfiguration (wg-quick)
# /etc/wireguard/wg0.conf
[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <server-privatekey>
MTU = 1420
[Peer] # mobiler Client hinter NAT
PublicKey = <client-publickey>
AllowedIPs = 10.10.0.2/32 # zugleich Route und Zugriffsrecht
PersistentKeepalive = 255. MTU und Overhead
Die Kapselung kostet rund 60 Byte über IPv4 und rund 80 Byte über IPv6. Das Werkzeug wg-quick setzt die Tunnel-MTU deshalb konservativ auf 1420 Byte, sodass auch der größere IPv6-Overhead in eine 1500er-Leitung passt. Auf Strecken mit kleinerer MTU (etwa DSL mit PPPoE) oder bei blockierter Path MTU Discovery sollte der Wert angepasst werden, sonst kommt es bei großen Paketen zu Problemen.
6. Was WireGuard bewusst nicht mitbringt
WireGuard hat keine eingebaute PKI, keine Zertifikate, kein Benutzerverzeichnis und keine Sperrliste. Ein Peer ist ein Schlüsselpaar plus seine erlaubten Adressen, die Verteilung der Schlüssel und die Identitätsverwaltung liegen außerhalb. Für größere Installationen übernehmen das Management-Schichten wie NetBird oder einfache Werkzeuge wie wg-easy; ein optionaler Pre-Shared Key lässt sich als zusätzlicher Schutz gegen künftige Quantencomputer einmischen.
Auch dynamisches Routing kennt WireGuard nicht von Haus aus: AllowedIPs sind statisch. Wer OSPF oder BGP über den Tunnel fahren will, kombiniert WireGuard mit einem Routing-Daemon wie FRR oder BIRD.
Nur UDP
WireGuard hat keinen TCP-Fallback. In Netzen, die UDP vollständig sperren (manche Hotel- oder Unternehmens-Proxys), kommt es nicht durch. Eine andere Portwahl hilft nur, wenn UDP grundsätzlich erlaubt ist.
7. Topologien
WireGuard ist symmetrisch aufgebaut, daraus lassen sich verschiedene Muster bilden: Punkt-zu-Punkt für die Standortkopplung, Stern (Hub-and-Spoke) mit einem zentralen Knoten, über den die Außenstellen kommunizieren, und Remote Access für einzelne Geräte. Da jeder Peer nur die Bereiche erreicht, die in seinen AllowedIPs stehen, ist die Reichweite jeder Gegenstelle klar umrissen.
8. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Kleine Codebasis, geringe Angriffsfläche, formal geprüft | Kein TCP-Fallback; in UDP-sperrenden Netzen unbrauchbar |
| Fester, moderner Krypto-Stack ohne Downgrade-Risiko | Keine eingebaute Schlüsselverteilung, PKI oder Benutzerverwaltung |
| Roaming ohne Verbindungsabbruch | Kein dynamisches Routing nativ (AllowedIPs sind statisch) |
| Kernel-integriert, hohe Performance, wenig Overhead | Schlüssel-Sperrung nur manuell oder über externe Tools |
| Stilles Verhalten gegenüber Unbefugten (Stealth) | MTU-empfindlich; PMTUD-Probleme müssen beachtet werden |
Häufige Fragen zu WireGuard
Das ist Absicht. WireGuard verdrahtet seinen Krypto-Stack fest (Curve25519, ChaCha20-Poly1305, BLAKE2s) und handelt nichts aus. Dadurch gibt es keinen Downgrade-Angriff auf ein schwaches Verfahren und keine unsichere Fehlkonfiguration. Muss der Stack einmal gewechselt werden, geschieht das über eine neue Protokollversion, nicht über Optionen.
Von sich aus gar nicht. WireGuard kennt keine PKI, kein Benutzerverzeichnis und keine Sperrliste; ein Peer ist nur ein Schlüsselpaar mit erlaubten IP-Bereichen. Für größere Installationen übernehmen Management-Schichten wie NetBird oder Werkzeuge wie wg-easy die Schlüsselverteilung, Benutzerverwaltung und Anbindung an einen Identity-Provider.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
WireGuard im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.