Einrichtung eines WireGuard-Servers unter Linux (wg0, NAT, Peers)

Betreiben Sie einen WireGuard-Server, wenn Sie privaten Zugriff auf gehostete Infrastruktur wünschen, ohne Admin-Ports dem öffentlichen Internet preiszugeben. Er nutzt Public-Key-Authentifizierung, läuft seit Version 5.6 im Linux-Kernel und arbeitet im Hintergrund, sobald er einmal eingerichtet ist. Dieser Beitrag behandelt, wann ein WireGuard-Server eingesetzt werden sollte, wie man ihn in Betrieb nimmt wg0und wie man den täglichen Betrieb der Peers aufrechterhält.

Wann sollte ein WireGuard-Server verwendet werden?

Drei Anwendungsfälle decken die meisten Konfigurationen ab: Fernzugriff, Server-zu-Server-Verbindungen und Site-to-Site-Routing.

Für den Fernzugriff betreiben Sie den Server auf einem VPS oder einem dedizierten Host und leiten den Admin-Datenverkehr durch den Tunnel. Richten Sie AllowedIPs auf jedem Peer das private Verwaltungs-Subnetz ein (etwa 10.0.0.0/24), damit nur der Datenverkehr für interne Systeme den Tunnel nutzt. Alles andere verbleibt auf der lokalen Verbindung des Benutzers. Wenn sich Benutzer von zu Hause oder über Mobilfunknetze verbinden, fügen Sie PersistentKeepalive = 25 auf der Client-Seite hinzu, um zu verhindern, dass NAT-Sitzungen abgebrochen werden.

Bei Server-zu-Server-Verbindungen sollten Sie AllowedIPs schmal. In der Regel reicht ein einzelnes /32 oder ein kleines Backend-Subnetz. Dadurch wird vermieden, dass nicht relevanter Datenverkehr in den Tunnel gezogen wird, und das Routing bleibt vorhersehbar.

Bei Site-to-Site-Verbindungen verhält es sich anders. Der WireGuard-Host fungiert als Gateway zwischen Subnetzen, daher muss die IP-Weiterleitung aktiviert sein und die NAT-Regeln müssen den Rückverkehr über die richtige Schnittstelle leiten.

Server-Einrichtung

Der Server verwahrt den privaten Schlüssel, lauscht standardmäßig auf UDP 51820 und bildet den Tunnelabschluss. Die gleiche Grundkonfiguration gilt für alle drei oben genannten Muster.

Schlüssel und wg0.conf

Generieren Sie das Schlüsselpaar für den Server:

wg genkey | sudo tee /etc/wireguard/server_private.key | wg pubkey | sudo tee /etc/wireguard/server_public.key

Sichern Sie den privaten Schlüssel:

sudo chmod 600 /etc/wireguard/server_private.key

Der private Schlüssel verbleibt auf dem Server. Den öffentlichen Schlüssel gibst du an deine Peers weiter.

Erstellen /etc/wireguard/wg0.conf:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <SERVER_PRIVATE_KEY>
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o <PUBLIC_IFACE> -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o <PUBLIC_IFACE> -j MASQUERADE
 
[Peer]
PublicKey = <CLIENT_PUBLIC_KEY>
AllowedIPs = 10.8.0.2/32

Ermitteln Sie die ausgehende Schnittstelle, in die Sie <PUBLIC_IFACE> :

ip -o -4 route show to default | awk '{print $5}'

Weiterleitung, Firewall und NAT

Öffnen Sie den Listening-Port:

sudo ufw allow 51820/udp

Aktivieren Sie die IP-Weiterleitung, indem Sie diese Zeile zu /etc/sysctl.conf:

net.ipv4.ip_forward = 1

Anwenden ohne Neustart:

sudo sysctl -p

Die PostUp und PostDown Zeilen in wg0.conf fügen die NAT-Masquerade-Regel hinzu bzw. entfernen sie, wenn die Schnittstelle hoch- oder heruntergefahren wird. Ohne sie gelangt der Rückverkehr aus dem LAN niemals zum Peer zurück.

Den Tunnel aktivieren

wg-quick übernimmt die Schnittstelle, das Routing und die PostUp/PostDown Hooks in einem einzigen Befehl:

sudo wg-quick up wg0

Für den automatischen Start nach einem Neustart aktivieren Sie die systemd-Einheit:

sudo systemctl enable --now wg-quick@wg0

Überprüfen Sie den Status mit:

sudo wg show

Eine aktuelle latest handshake Zeile bestätigt, dass der Tunnel funktioniert. Wenn sie veraltet oder leer aussieht, überprüfen Sie die Firewall, die Schlüssel auf beiden Seiten und die des Peers AllowedIPs.

Hinzufügen und Entfernen von Peers

Jeder Peer benötigt ein eigenes Schlüsselpaar. Generieren Sie dieses auf dem Client und fügen Sie anschließend den öffentlichen Schlüssel des Peers wg0.conf in einen neuen [Peer] Block mit einem AllowedIPs Eintrag, der dessen Tunnel-IP zuweist.

Verwenden Sie /32 für ein einzelnes Gerät:

AllowedIPs = 10.8.0.3/32

Dadurch wird verhindert, dass ein Peer Adressen beansprucht, die einem anderen zugewiesen sind. Für den Split-Tunnel-Zugriff listen Sie nur die privaten Subnetze auf, die durch den Tunnel geleitet werden sollen, zum Beispiel AllowedIPs = 10.8.0.0/24.

Konfigurationsänderungen anwenden, ohne aktive Sitzungen zu beenden:

sudo wg syncconf wg0 <(wg-quick strip wg0)

Das Entfernen eines Peers funktioniert auf die gleiche Weise. Löschen Sie dessen [Peer] Block aus wg0.conf und führen Sie syncconf erneut aus.

Fehlerbehebung

Wenn ein Peer eine Verbindung herstellt, aber nichts auf der anderen Seite erreichen kann, liegt die Ursache in der Regel in einem der folgenden vier Punkte:

• Die IP-Weiterleitung ist deaktiviert
• Die NAT-Masquerade-Regel fehlt
• Die ausgehende Schnittstelle in der NAT-Regel ist falsch
• AllowedIPs beinhaltet das Ziel nicht

Weiterleitung prüfen:

cat /proc/sys/net/ipv4/ip_forward

Sollte 1. Wenn der Wert 0, wurde die sysctl-Änderung nicht übernommen oder nicht gespeichert.

Überprüfen Sie die NAT-Regel und die ausgehende Schnittstelle:

sudo iptables -t nat -L POSTROUTING
ip route get 1.1.1.1

Der zweite Befehl zeigt den tatsächlichen Namen der ausgehenden Schnittstelle an, z. B. ens3, enp1s0oder eth0. Dieser muss mit der Schnittstelle in der MASQUERADE-Regel übereinstimmen.

Falls der Handshake selbst fehlt, überprüfen Sie, ob UDP 51820 an der Firewall und bei allen vorgelagerten Anbietern offen ist und dass beide Seiten über den richtigen öffentlichen Schlüssel des jeweils anderen verfügen.

Für Peers hinter einem privaten oder mobilen NAT, das inaktive UDP-Sitzungen unterbricht, setzen Sie PersistentKeepalive = 25 auf dem Client ein.

Schlüsselrotation und vorab geteilte Schlüssel

Bei Tunneln, die über Monate hinweg bestehen bleiben, sollten die Schlüssel etwa einmal jährlich rotiert werden. Generieren Sie ein neues Schlüsselpaar, aktualisieren Sie beide Enden und wenden Sie es mit wg syncconf. Verwenden Sie einen privaten Schlüssel nicht für zwei verschiedene Peers. Dies führt zu Routing-Konflikten und unterbricht die Datenübertragung zwischen ihnen.

Für eine zusätzliche Sicherheitsstufe zusätzlich zur Public-Key-Authentifizierung fügen Sie pro Peer einen vorab geteilten Schlüssel hinzu:

wg genpsk

Fügen Sie das Ergebnis als PresharedKey = <PSK> im [Peer] Block auf beiden Seiten ein. WireGuard integriert den PSK in den Handshake, sodass ein Angreifer, der einen der asymmetrischen Schlüssel irgendwie kompromittiert, den Datenverkehr ohne diesen Schlüssel dennoch nicht entschlüsseln kann.

Nützliche Befehle für den täglichen Gebrauch:

Wenn Sie einen stabilen, öffentlich erreichbaren Host benötigen, um WireGuard-Tunnel zu beenden und privaten Datenverkehr in Ihre Infrastruktur weiterzuleiten, sehen Sie sich die unbegrenzten VPS-Tarife von FDC an.