Ein WireGuard-Server auf dem VPS ist die Voraussetzung für fast alles andere, was man nicht offen ins Internet stellen will: Panels, Datenbanken, Home Assistant, das eigene Monitoring. Der Aufbau ist kurz und die Fehler sind immer dieselben drei.
Server einrichten#
apt install wireguard
umask 077
wg genkey | tee /etc/wireguard/privat.key | wg pubkey > /etc/wireguard/oeffentlich.key
cat /etc/wireguard/oeffentlich.key # den brauchen die Clients
# /etc/wireguard/wg0.conf
[Interface]
Address = 10.9.0.1/24
ListenPort = 51820
PrivateKey = <server-privat>
# Erster Client
[Peer]
PublicKey = <client-oeffentlich>
AllowedIPs = 10.9.0.2/32
echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/99-wg.conf
echo "net.ipv6.conf.all.forwarding=1" >> /etc/sysctl.d/99-wg.conf
sysctl --system
nft add table inet nat
nft add chain inet nat postrouting '{ type nat hook postrouting priority 100; }'
nft add rule inet nat postrouting oifname "eth0" masquerade
systemctl enable --now wg-quick@wg0
wg show
Nach außen bleibt genau ein Port offen, UDP 51820. Der Rest gehört zu (nftables).
Client einrichten#
# Auf dem Client (oder auf dem Server erzeugt und übertragen)
wg genkey | tee client.key | wg pubkey > client.pub
# client.conf
[Interface]
PrivateKey = <client-privat>
Address = 10.9.0.2/24
DNS = 10.9.0.1
[Peer]
PublicKey = <server-oeffentlich>
Endpoint = vps.example.com:51820
AllowedIPs = 10.9.0.0/24 # nur das VPN-Netz …
# AllowedIPs = 0.0.0.0/0, ::/0 # … oder der gesamte Verkehr
PersistentKeepalive = 25
Für das Telefon erzeugt man daraus einen QR-Code:
apt install qrencode
qrencode -t ansiutf8 < client.conf
Die drei Fehler#
1. AllowedIPs bedeutet zweierlei#
Auf dem Client ist es die Frage „was schicke ich in den Tunnel?“. Auf dem Server ist es die Frage „welche Absender akzeptiere ich von diesem Peer?“ und gleichzeitig die Route zurück.
Das ist der häufigste Denkfehler: Wenn der Server für einen Peer 10.9.0.2/32 einträgt, der Peer aber Pakete mit Absender 192.168.178.5 schickt (weil dahinter ein Netz hängt), verwirft der Server sie kommentarlos. Es gibt keine Fehlermeldung, es kommt nur nichts an.
# Server, wenn hinter dem Peer ein ganzes Netz liegt:
[Peer]
PublicKey = <fritzbox-oeffentlich>
AllowedIPs = 10.9.0.2/32, 192.168.178.0/24
2. MTU#
Im Tunnel ist weniger Platz pro Paket. Kleine Pakete kommen durch, also Ping und Anmeldung, große nicht. Das Ergebnis: SSH baut auf und friert ein (banner exchange timeout), Webseiten laden halb. Das sieht aus wie ein Serverproblem und ist keins.
# Größtes Paket, das ohne Fragmentierung durchgeht:
ping -M do -s 1372 10.9.0.1
# Gegenmittel auf dem Server, wirkt für alle Peers:
nft add rule inet filter forward tcp flags syn tcp option maxseg size set rt mtu
# oder pro Client: MTU = 1380 im [Interface]-Block
3. PersistentKeepalive#
Clients hinter einer Adressumsetzung (also fast alle) müssen den Rückweg offen halten. Ohne PersistentKeepalive = 25 funktioniert der Tunnel, solange der Client sendet und ist genau dann tot, wenn der Server ihn erreichen will.
Auf dem Server ist der Wert nicht nötig, wenn er eine feste öffentliche Adresse hat.
Mehrere Clients sauber verwalten#
Jeder Peer bekommt einen eigenen Schlüssel und eine eigene Adresse. Keine Sammel-Konfiguration, keine geteilten Schlüssel, sonst kann man einen einzelnen Zugang nicht entziehen.
# Peer im Betrieb hinzufügen, ohne Neustart:
wg set wg0 peer <neuer-oeffentlicher-schluessel> allowed-ips 10.9.0.7/32
wg-quick save wg0 # in die Datei übernehmen
# Und wieder entfernen:
wg set wg0 peer <schluessel> remove && wg-quick save wg0
# Wer ist verbunden, wann zuletzt?
wg show wg0 latest-handshakes
wg show wg0 transfer
Ein Handshake, der älter als ein paar Minuten ist, heißt: Der Peer ist weg. Diese Zahl ist die einzige verlässliche Zustandsanzeige, die WireGuard hat, es gibt keine „Verbindung“ im klassischen Sinn.
DNS im Tunnel#
Steht DNS = 10.9.0.1 in der Client-Konfiguration, muss dort auch etwas antworten. Zwei Wege:
- Weiterreichen: ein schlanker Resolver auf dem VPS (eigener DNS-Resolver).
- Weglassen: Zeile streichen, dann behält der Client seinen DNS. Für einen reinen Zugangs-Tunnel ist das die einfachere Wahl.
Häufige Fragen#
Reicht ein kleiner VPS?#
Ja. WireGuard ist sparsam; der Engpass ist die Anbindung, nicht die CPU. Für ein paar Personen genügt die kleinste Größe.
Wie leite ich den gesamten Verkehr durch den Tunnel?#
AllowedIPs = 0.0.0.0/0, ::/0 auf dem Client. Dann läuft alles über den VPS, inklusive der Frage, wer die Protokolle dort liest. Für den reinen Zugriff auf eigene Dienste ist das unnötig.
Warum sehe ich den Server nicht in der Prozessliste?#
Weil WireGuard im Kernel läuft, nicht als Dienst. wg show und ip link show wg0 sind die richtigen Blicke; systemctl status wg-quick@wg0 zeigt nur, ob das Einrichten geklappt hat.
Ist WireGuard sicher genug für Verwaltungszugänge?#
Ja, es ist der empfohlene Weg, ein Panel oder eine Datenbank nicht ins Internet zu stellen. Wichtig bleibt: aktuelle Kernel, Schlüssel pro Gerät, und Zugänge entziehen, wenn ein Gerät verloren geht.
Und IPv6?#
Funktioniert genauso; Adressbereich zusätzlich vergeben und die Weiterleitung für IPv6 einschalten (steht oben). Details zum Adressplan: IPv6 auf dem VPS.
Kurz gesagt#
- Ein Port nach außen: UDP. Alles andere bleibt zu.
AllowedIPsheißt auf beiden Seiten etwas anderes, hier entstehen die meisten Fehler.- Verbindung steht, Übertragung hängt: MTU.
PersistentKeepalive = 25auf allen Clients hinter einer Adressumsetzung.- Ein Schlüssel pro Gerät, sonst lässt sich nichts einzeln entziehen.
Geschrieben aus dem laufenden Betrieb: MRMedia betreibt eigene Proxmox- Hosts, einen Backup-Server und Kundendienste in der EU. Fehler in einer Anleitung sind Fehler im eigenen Betrieb. Korrekturen bitte über Discord.