WireGuard VPN unter Linux einrichten: Schlanke, moderne Verschlüsselung

1. Warum WireGuard leichtgewichtiger ist als OpenVPN und IPsec

OpenVPN basiert auf OpenSSL und bietet eine enorme Bandbreite an konfigurierbaren Chiffren, Authentifizierungsmethoden und Betriebsmodi, was in der Praxis zu Konfigurationsdateien mit dutzenden Optionen und einem entsprechend großen Angriffsvektor führt. IPsec wiederum verteilt seine Logik auf mehrere Protokolle wie IKE, ESP und AH, deren Zusammenspiel selbst erfahrene Administratoren regelmäßig vor Debugging-Herausforderungen stellt, insbesondere wenn NAT-Traversal ins Spiel kommt.

WireGuard verfolgt einen radikal anderen Ansatz: Es bietet genau einen modernen Kryptografie-Satz, Curve25519 für den Schlüsselaustausch und ChaCha20-Poly1305 für die authentifizierte Verschlüsselung, ohne Verhandlungsoptionen zwischen mehreren Chiffren. Diese bewusste Einschränkung reduziert den Kernel-Code auf etwa viertausend Zeilen gegenüber teils mehreren hunderttausend Zeilen bei etablierten IPsec-Implementierungen, was sowohl die Angriffsfläche als auch die Menge potenzieller Implementierungsfehler drastisch verkleinert.

2. Das Noise Protocol Framework und der schlanke Handshake

WireGuard basiert auf dem Noise Protocol Framework, einer formal verifizierten Sammlung von Handshake-Mustern für authentifizierte Schlüsselaushandlung. Der verwendete Handshake, bekannt als Noise_IK, benötigt nur einen einzigen Roundtrip zwischen zwei Peers, um eine neue Sitzung mit Perfect Forward Secrecy aufzubauen, während klassische IPsec IKEv2-Handshakes je nach Konfiguration mehrere Roundtrips durchlaufen.

Jede Verbindung ist zudem konzeptionell zustandslos gegenüber dem klassischen Verbindungsmodell: WireGuard kennt keine explizite Verbindung im Sinne eines TCP-Handshakes, sondern verarbeitet UDP-Pakete anhand kryptografischer Identität. Das bedeutet, ein Client kann die öffentliche IP-Adresse wechseln, etwa beim Wechsel zwischen Mobilfunk und WLAN, und die Verbindung bleibt bestehen, sobald das nächste authentifizierte Paket eintrifft, ohne dass eine erneute vollständige Aushandlung notwendig wird.

3. Schlüsselpaare generieren: Der erste Schritt jeder WireGuard Konfiguration

WireGuard verwendet für jeden Peer ein eigenes Curve25519 Schlüsselpaar, bestehend aus einem privaten und einem öffentlichen Schlüssel. Anders als bei klassischen VPN-Lösungen mit zentraler Zertifizierungsstelle gibt es keine Public Key Infrastructure, keine Zertifikatsketten und keine Widerrufslisten zu verwalten, was die initiale Einrichtung erheblich vereinfacht, aber auch bedeutet, dass Schlüsselrotation und Peer-Verwaltung bei vielen Servern organisatorisch selbst geregelt werden müssen.

Der private Schlüssel verlässt im Idealfall niemals den Server, auf dem er generiert wurde, während der öffentliche Schlüssel an die Gegenstelle weitergegeben wird und dort in deren Peer-Konfiguration eingetragen wird. Für Umgebungen mit vielen Servern empfiehlt sich ein zentrales, aber sicher verwahrtes Verzeichnis der öffentlichen Schlüssel, etwa in einem Secrets-Management-System, während die privaten Schlüssel ausschließlich lokal mit restriktiven Dateiberechtigungen liegen.

# Privaten Schlüssel generieren und Berechtigungen sofort einschraenken
umask 077
wg genkey > /etc/wireguard/privatekey

# Oeffentlichen Schlüssel aus dem privaten Schlüssel ableiten
wg pubkey < /etc/wireguard/privatekey > /etc/wireguard/publickey

cat /etc/wireguard/publickey

4. Interface-Konfiguration: Aufbau der wg0.conf im Detail

Die zentrale Konfigurationsdatei eines WireGuard Interfaces folgt einer einfachen INI-ähnlichen Struktur mit genau zwei Abschnittstypen: einem einzigen [Interface] Block für die lokale Konfiguration und beliebig vielen [Peer] Blöcken für jede Gegenstelle. Der [Interface] Abschnitt legt den privaten Schlüssel, die dem Interface zugewiesene IP-Adresse im VPN-Subnetz sowie den UDP-Listen-Port fest, über den WireGuard eingehende Handshakes entgegennimmt.

Optional lässt sich im [Interface] Block über PostUp und PostDown zusätzliche Shell-Logik hinterlegen, etwa um beim Aktivieren des Interfaces automatisch Firewall-Regeln für Forwarding zu setzen und beim Deaktivieren wieder zu entfernen. Diese Hooks sind besonders bei Server-zu-Server-Szenarien nützlich, in denen das WireGuard Interface als Gateway für weiteren Netzwerkverkehr dient, etwa für eine Datenbank-Replikation, die über den Tunnel geroutet werden soll.

# /etc/wireguard/wg0.conf auf dem primaeren Datenbankserver
[Interface]
PrivateKey = <privater_schluessel_server_a>
Address = 10.10.0.1/24
ListenPort = 51820
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT

[Peer]
# Replikations-Standby am zweiten Standort
PublicKey = <oeffentlicher_schluessel_server_b>
AllowedIPs = 10.10.0.2/32
Endpoint = replica.example.com:51820
PersistentKeepalive = 25

5. Peer-Setup und die Bedeutung von AllowedIPs

AllowedIPs erfüllt bei WireGuard eine doppelte Funktion, die häufig unterschätzt wird: Zum einen definiert es, welche Quell-IP-Adressen von diesem Peer akzeptiert werden, zum anderen fungiert es als Routing-Tabelle für ausgehenden Verkehr, der über diesen Peer getunnelt werden soll. Wer AllowedIPs zu weit fasst, etwa mit 0.0.0.0/0, leitet ungewollt den gesamten Datenverkehr des Servers über den Tunnel, während eine zu enge Definition legitime Pakete stillschweigend verwirft, ohne eine Fehlermeldung zu erzeugen.

Für ein Server-zu-Server-Szenario mit Datenbank-Replikation über zwei Standorte reicht es in der Regel, AllowedIPs auf die einzelne /32-Adresse des jeweiligen Peers im VPN-Subnetz zu beschränken. Sollen zusätzlich ganze Subnetze hinter einem Peer erreichbar sein, etwa ein internes Netzwerksegment am zweiten Standort, wird das entsprechende Subnetz zu AllowedIPs hinzugefügt und muss zusätzlich über IP-Forwarding und passende Routing-Einträge auf beiden Seiten unterstützt werden.

6. PersistentKeepalive: Verbindungen hinter NAT stabil halten

Da WireGuard auf UDP basiert und keine expliziten Verbindungszustände wie TCP kennt, können NAT-Gateways und stateful Firewalls die Zuordnung eines Client-Ports zu einer Sitzung nach einer gewissen Inaktivität verwerfen. Ohne Gegenmaßnahme führt das dazu, dass eingehende Pakete vom Server nicht mehr zum ursprünglichen Client durchgereicht werden, sobald dessen NAT-Mapping abgelaufen ist, was die Verbindung effektiv einseitig unterbricht.

Die Option PersistentKeepalive löst dieses Problem, indem sie in festgelegten Intervallen, typischerweise alle 25 Sekunden, ein leeres UDP-Paket an die Gegenstelle sendet, um das NAT-Mapping künstlich aktiv zu halten. Für reine Server-zu-Server-Verbindungen mit festen, öffentlich erreichbaren IP-Adressen auf beiden Seiten ist PersistentKeepalive oft verzichtbar, wird aber empfohlen, sobald mindestens eine Seite hinter NAT oder einer restriktiven Firewall mit Session-Timeout betrieben wird.

# Interface aktivieren und Status inklusive Handshake Zeitpunkt pruefen
wg-quick up wg0
wg show wg0

# Erwartete Ausgabe zeigt latest handshake und transferierte Bytes
# peer: <public_key>
#   endpoint: replica.example.com:51820
#   allowed ips: 10.10.0.2/32
#   latest handshake: 12 seconds ago
#   transfer: 4.21 MiB received, 3.98 MiB sent

7. MTU-Besonderheiten und Best Practices für den produktiven Einsatz

WireGuard kapselt jedes Paket in UDP und fügt dabei einen eigenen Protokoll-Header hinzu, wodurch das Interface standardmäßig eine MTU von 1420 Byte statt der üblichen 1500 Byte verwendet, um Fragmentierung innerhalb des Tunnels zu vermeiden. Wird WireGuard zusätzlich über eine bereits reduzierte Basis-MTU betrieben, etwa innerhalb eines weiteren Tunnels oder über eine PPPoE-Verbindung, muss die WireGuard-MTU manuell angepasst werden, da sonst dieselben Path MTU Discovery Probleme auftreten können, die auch andere Tunnel-Technologien betreffen.

Für den produktiven Einsatz empfiehlt sich außerdem, private Schlüssel niemals mit Weltlese-Rechten abzulegen, sondern konsequent mit dem Modus 600 und Eigentümer root zu versehen, sowie AllowedIPs so eng wie möglich zu fassen, statt aus Bequemlichkeit auf 0.0.0.0/0 auszuweichen. Auf Debian- und Ubuntu-Systemen lässt sich WireGuard zudem nativ über systemd-networkd konfigurieren, was gegenüber dem klassischen wg-quick Skript den Vorteil bietet, dass Interface-Zustand und Routing konsistent über dieselbe Netzwerkverwaltung wie alle übrigen Interfaces des Servers erfolgen.

# MTU eines WireGuard Interfaces manuell anpassen, falls der
# zugrunde liegende Pfad selbst bereits eine reduzierte MTU aufweist
ip link set mtu 1380 dev wg0

# Rechte des privaten Schluessels vor dem produktiven Einsatz pruefen
chmod 600 /etc/wireguard/privatekey
chown root:root /etc/wireguard/privatekey

8. Praxisbeispiel: Datenbank-Replikation über Standorte absichern

Ein typischer Einsatzzweck im Hosting-Kontext ist die Absicherung einer MySQL- oder PostgreSQL-Replikation zwischen zwei physisch getrennten Rechenzentren, ohne den Replikationsverkehr ungeschützt über das offene Internet zu senden. Statt die Datenbank selbst mit TLS-Zertifikaten pro Verbindung abzusichern, kapselt WireGuard den gesamten Datenverkehr auf Netzwerkebene, sodass die Datenbank-Konfiguration unverändert bleibt und lediglich auf die VPN-interne IP-Adresse der Gegenstelle verweist.

In der Praxis bindet der primäre Datenbankserver dabei nur auf die WireGuard-Adresse im 10.10.0.0/24 Subnetz, während der öffentliche Netzwerk-Interface für den Datenbank-Port geschlossen bleibt. Damit ist die Replikationsverbindung selbst dann geschützt, wenn ein Angreifer den öffentlichen Datenbank-Port eines Servers direkt erreichen könnte, weil der eigentliche Replikationsverkehr ausschließlich innerhalb des verschlüsselten WireGuard-Tunnels stattfindet.

9. Troubleshooting und Monitoring von WireGuard Verbindungen

Die wichtigste Diagnosequelle ist der Zeitstempel latest handshake in der Ausgabe von wg show: Liegt dieser Wert weit in der Vergangenheit oder fehlt ganz, findet keine gültige Kommunikation zwischen den Peers statt, meist wegen falscher öffentlicher Schlüssel, blockierter UDP-Pakete auf Firewall-Ebene oder eines falsch konfigurierten Endpoints. Da WireGuard bei ungültigen Paketen bewusst schweigt, statt Fehlermeldungen zu senden, hilft ein Blick auf transferierte Byte-Zahlen häufig mehr als klassisches Logging.

Für dauerhaftes Monitoring lässt sich wg show wg0 dump maschinenlesbar auswerten und in Monitoring-Systeme wie Prometheus über einen einfachen Exporter integrieren, um Handshake-Alter und Transfervolumen pro Peer kontinuierlich zu überwachen. Ein Handshake, der älter als etwa drei Minuten ist, deutet in produktiven Server-zu-Server-Verbindungen zuverlässig auf ein Problem hin und sollte alarmieren, bevor die Replikation selbst ins Stocken gerät.

10. Zusammenfassung

11. FAQ: WireGuard VPN