VPN-Server mit WireGuard auf Linux einrichten (Ubuntu, Schritt für Schritt 2026)

Ein eigener WireGuard-Server auf einem günstigen Linux-VPS liefert einen privaten, verschlüsselten Tunnel unter vollständiger eigener Kontrolle, für ein paar Dollar im Monat. Das ersetzt nicht den IP-Pool oder das Streaming-Entsperren eines kommerziellen VPNs, aber um den eigenen Traffic im öffentlichen WLAN zu sichern oder von unterwegs auf das Heimnetz zuzugreifen, ist es eine wirklich solide Option. Hier die komplette Einrichtung unter Ubuntu.

Was vorher gebraucht wird

Ein VPS mit Ubuntu 22.04 oder 24.04 (jeder günstige Anbieter funktioniert: die billigste Stufe reicht für persönliche WireGuard-Nutzung), Root- oder Sudo-Zugriff per SSH, und etwa fünfzehn Minuten Zeit. Dieselben Schritte funktionieren mit kleinen Anpassungen auch unter Debian.

Alle VPNs im direkten Vergleich? Unser vollständiger VPN-Vergleich zeigt Bewertungen nach 18 Kriterien.

Schritt 1: System aktualisieren und WireGuard installieren

Per SSH auf den VPS verbinden, dann ausführen:

sudo apt update && sudo apt upgrade -y
sudo apt install wireguard qrencode -y

qrencode ist für WireGuard selbst nicht nötig, erlaubt aber später, einen QR-Code zu erzeugen, der direkt in die mobile App gescannt werden kann, statt Schlüssel manuell auf ein Smartphone zu übertragen.

Schritt 2: Schlüsselpaar des Servers erzeugen

cd /etc/wireguard
umask 077
wg genkey | tee server_private.key | wg pubkey > server_public.key

umask 077 ist hier wichtig: Es stellt sicher, dass die Schlüsseldateien für andere Nutzer auf dem System nicht lesbar sind. Beide Dateien aufbewahren; der private Schlüssel wird in der Serverkonfiguration referenziert, der öffentliche Schlüssel bleibt serverseitig.

Schritt 3: Serverkonfiguration erstellen

/etc/wireguard/wg0.conf anlegen:

[Interface]
PrivateKey = <Inhalt von server_private.key einfügen>
Address = 10.8.0.1/24
ListenPort = 51820
SaveConfig = false

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

eth0 durch den tatsächlichen Namen der öffentlichen Netzwerkschnittstelle des VPS ersetzen, falls abweichend (prüfen mit ip a). Die Zeilen PostUp/PostDown sorgen dafür, dass Traffic verbundener Clients über die öffentliche IP des Servers hinausgeleitet wird; ohne sie hätte man einen funktionierenden Tunnel, der nirgendwohin führt.

Schritt 4: IP-Forwarding aktivieren

WireGuard braucht den Kernel, um Pakete zwischen Schnittstellen weiterzuleiten:

echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Diesen Schritt überspringen und Clients verbinden sich zwar, kommen aber nicht durch den Tunnel ins Internet, einer der häufigsten Fehler bei der WireGuard-Einrichtung.

Schritt 5: Firewall-Port öffnen

Mit UFW:

sudo ufw allow 51820/udp
sudo ufw allow OpenSSH
sudo ufw enable

Auch im Dashboard des VPS-Anbieters nach einer separaten Cloud-Firewall oder Security Group schauen; manche Anbieter blockieren Ports auf Netzwerkebene unabhängig davon, was UFW auf der Instanz selbst erlaubt, und das wird leicht übersehen, wenn eine Verbindung später still fehlschlägt.

Schritt 6: Client-Schlüsselpaar erzeugen und als Peer hinzufügen

Auf dem Server ein Schlüsselpaar für das erste Client-Gerät erzeugen:

wg genkey | tee client1_private.key | wg pubkey > client1_public.key

Den Client am Ende von /etc/wireguard/wg0.conf als Peer hinzufügen:

[Peer]
PublicKey = <Inhalt von client1_public.key einfügen>
AllowedIPs = 10.8.0.2/32

Schritt 7: Server starten

sudo systemctl enable --now wg-quick@wg0
sudo systemctl status wg-quick@wg0

Vor dem nächsten Schritt bestätigen, dass der Dienst aktiv läuft. Startet er nicht, den Schnittstellennamen aus Schritt 3 und die Syntax der Konfigurationsdatei noch einmal prüfen, meist steckt der Fehler in einer einzelnen falsch platzierten Zeile.

Schritt 8: Client-Konfiguration erstellen

Auf dem eigenen Gerät (oder in einer Textdatei, die sicher übertragen wird) eine Konfiguration mit dem privaten Schlüssel des Clients aus Schritt 6 erstellen:

[Interface]
PrivateKey = <Inhalt von client1_private.key>
Address = 10.8.0.2/32
DNS = 1.1.1.1

[Peer]
PublicKey = <Inhalt von server_public.key>
Endpoint = <öffentliche IP des VPS>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

AllowedIPs = 0.0.0.0/0 leitet den gesamten Client-Traffic durch den Tunnel, das übliche Verhalten eines vollständigen VPN. Wer nur das Heim- oder VPS-Netz erreichen will, ohne den gesamten Internetverkehr durchzuleiten, sollte dieses Feld stattdessen auf genau dieses Subnetz eingrenzen.

Für Mobilgeräte einen QR-Code aus dieser Konfiguration erzeugen und direkt in die WireGuard-App scannen:

qrencode -t ansiutf8 < client1.conf

Schritt 9: Verbindung testen

Den Tunnel auf dem Client aktivieren, dann die öffentliche IP prüfen (eine kurze Suche nach der eigenen IP oder curl ifconfig.me vom Client aus), um zu bestätigen, dass jetzt die Adresse des VPS angezeigt wird, nicht die ursprüngliche. Auch prüfen, dass die DNS-Auflösung nicht außerhalb des Tunnels erfolgt.

Weitere Geräte hinzufügen

Schritte 6 bis 8 für jedes weitere Gerät wiederholen, mit einer neuen 10.8.0.x-Adresse pro Gerät (.3, .4 und so weiter) und einem frischen Schlüsselpaar pro Gerät. Nie einen privaten Schlüssel auf mehreren Geräten wiederverwenden, wird ein Gerät kompromittiert, gefährdet ein gemeinsam genutzter Schlüssel alle anderen mit.

Die Einrichtung härten

Eine Standard-WireGuard-Installation ist für sich genommen schon angemessen sicher, das Protokoll selbst hat eine kleine, gut geprüfte Codebasis, aber ein paar zusätzliche Schritte schließen gängige Angriffswege auf dem hostenden VPS.

Den Standard-SSH-Port ändern und die Passwort-Authentifizierung deaktivieren. WireGuard schützt den Tunnel, nicht den SSH-Dienst, mit dem alles eingerichtet wurde. Auf schlüsselbasierte SSH-Anmeldung umstellen und erwägen, weg von Port 22 zu gehen, um automatisiertes Scan-Rauschen zu reduzieren.

fail2ban installieren. sudo apt install fail2ban sperrt automatisch und temporär IPs nach wiederholten fehlgeschlagenen SSH-Anmeldeversuchen, eine günstige zusätzliche Schutzschicht auf einem öffentlich erreichbaren VPS.

Das System aktuell halten. Regelmäßig sudo apt update && sudo apt upgrade -y ausführen oder unattended-upgrades für Sicherheitsupdates aktivieren. Ein selbstgehosteter Server ist nur so sicher wie die am schlechtesten gepatchte Abhängigkeit.

AllowedIPs pro Peer einschränken, wo möglich. Braucht ein Gerät nur das Heimnetz statt des gesamten Internets, dessen AllowedIPs auf dieses Subnetz statt auf 0.0.0.0/0 begrenzen. Ein engerer Zugriff begrenzt, was ein kompromittiertes Gerät über den Tunnel erreichen könnte.

Häufige Probleme und Lösungen

Handshake schlägt fehl, gar keine Verbindung: fast immer ein Firewall-Problem, entweder UFW auf dem VPS selbst oder eine separate Cloud-Security-Group, die UDP 51820 blockiert. Beides prüfen, sie werden an unterschiedlichen Stellen konfiguriert, und es ist leicht, das eine zu beheben und das andere zu vergessen.

Verbindung klappt, aber kein Internetzugriff durch den Tunnel: Das ist der IP-Forwarding-Schritt von weiter oben. Prüfen, ob net.ipv4.ip_forward wirklich auf 1 steht und ob die NAT-Regeln PostUp/PostDown den tatsächlichen Namen der öffentlichen Schnittstelle referenzieren, nicht einen beim Kopieren der Konfiguration übrig gebliebenen Platzhalter.

Funktioniert im WLAN, schlägt bei mobilen Daten fehl: Manche Mobilfunkanbieter blockieren oder drosseln nicht standardmäßige UDP-Ports. Tritt das durchgehend auf, löst eine Änderung von ListenPort in der Serverkonfiguration auf einen gängigen Port wie 443 (mit entsprechender Anpassung der Client-Konfiguration) das Problem oft, da Filterung auf Netzbetreiberebene einen Port, der auch normalen HTTPS-Traffic trägt, deutlich seltener anfasst.

Was Selbsthosting nicht bietet

Diese Einrichtung verschlüsselt und leitet den eigenen Traffic über einen selbst kontrollierten Server, was wirklich wertvoll ist, um WLAN in Hotels oder Flughäfen abzusichern und von unterwegs auf das Heimnetz zuzugreifen. Was fehlt, ist ein großer IP-Pool zum Entsperren von Streaming, da man immer über dieselbe einzelne VPS-IP nach außen geht, ebenso wie die Anonymität, die das Teilen einer IP-Adresse mit Tausenden anderen Nutzern bei den gemeinsam genutzten Servern eines kommerziellen VPNs bietet. Eine einzelne, feste IP lässt sich über die Zeit auch leichter erkennen und sperren als der häufig rotierende Pool eines kommerziellen Anbieters.

Wer vor allem Streaming-Zugang, geografische Flexibilität oder das Untertauchen in einer großen Nutzerbasis statt Kontrolle über die eigene Infrastruktur sucht, ist mit einem kommerziellen VPN für genau diese Aufgabe besser bedient; ein selbstgehosteter WireGuard-Server und ein kommerzielles VPN lösen unterschiedliche Probleme und ergänzen sich eher, als dass sie konkurrieren.

Weiterlesen

Für eine ähnliche Selbsthosting-Einrichtung auf günstigerer Hardware siehe WireGuard-VPN-Server auf Raspberry Pi mit PiVPN einrichten. Um WireGuard auf dem eigenen Router statt einem VPS laufen zu lassen, lesen Sie VPN auf einem OpenWrt-Router einrichten. Und wer sich noch zwischen Protokollen entscheiden muss, siehe VPN-Protokolle erklärt 2026: WireGuard, OpenVPN, IKEv2 im Vergleich.