WireGuard ist die einfachste Art, von außen in ein eigenes Netz zu kommen: ein Tunnel, der aus zwei Schlüsselpaaren und einer knappen Konfigurationsdatei besteht. Wer einmal mit Zertifikaten gearbeitet hat, ist überrascht, wie wenig dazugehört — es gibt keine Zertifizierungsstelle, keine Aushandlung von Verfahren und keine Benutzerverwaltung.
Genau daraus folgt aber auch, was WireGuard nicht tut: Es verteilt keine Adressen an die Gegenstellen, es kennt keine Anmeldung mit Benutzername und Kennwort, und es läuft ausschließlich über UDP. Jede Gegenstelle wird von Hand eingetragen. Für einen Betrieb mit einer Handvoll Zugängen ist das ideal; für hundert wechselnde Nutzer ist es das falsche Werkzeug.
Installation
Seit Linux 5.6 steckt WireGuard im Kernel selbst, installiert wird nur noch das Werkzeug drumherum:
sudo apt install wireguardFür Windows, macOS, Android und iOS gibt es fertige Apps vom Projekt selbst. Die Konfiguration ist überall dieselbe Textdatei.
Schlüssel erzeugen
Jede Seite — Server wie Gegenstelle — bekommt ein eigenes Schlüsselpaar. Der private Schlüssel verlässt das Gerät nie, der öffentliche wird der anderen Seite mitgeteilt. Das umask 077 davor ist kein Zierrat: Ohne es liegt der private Schlüssel für jeden lesbar auf der Platte.
umask 077
wg genkey > privatekey
wg pubkey < privatekey > publickeyZusätzlich lässt sich ein gemeinsames Geheimnis erzeugen, das beide Seiten identisch eintragen. Es legt eine zweite, symmetrische Schicht über die Verbindung; die Dokumentation begründet das mit Widerstandsfähigkeit gegen künftige Quantenrechner.
wg genpskDie Konfiguration des Servers
Die Datei liegt unter /etc/wireguard/wg0.conf und ist nach dem Gerät benannt, das daraus entsteht. Sie besteht aus einem Abschnitt für die eigene Seite und je einem Abschnitt pro Gegenstelle.
# /etc/wireguard/wg0.conf
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <privater Schlüssel des Servers>
[Peer]
# Notebook
PublicKey = <öffentlicher Schlüssel des Notebooks>
AllowedIPs = 10.8.0.2/32
[Peer]
# Telefon
PublicKey = <öffentlicher Schlüssel des Telefons>
AllowedIPs = 10.8.0.3/32ListenPort ist laut Dokumentation optional — fehlt er, wird ein zufälliger Port gewählt. Auf einem Server, den andere erreichen sollen, gehört er also hin. Der Wert 51820 ist kein Zwang, aber die Zahl, die in der offiziellen Dokumentation durchgehend verwendet wird.
Beim Empfang wirkt der Eintrag als Zugriffsliste: Von dieser Gegenstelle werden nur Pakete angenommen, deren Absenderadresse dort steht. Beim Senden wirkt er als Wegetabelle: Pakete an eine dieser Adressen gehen zu genau dieser Gegenstelle. Deshalb trägt der Server pro Gegenstelle nur deren eigene Adresse ein, ein Client dagegen das, was er durch den Tunnel schicken will.
Die Konfiguration der Gegenstelle
# Notebook
[Interface]
Address = 10.8.0.2/32
PrivateKey = <privater Schlüssel des Notebooks>
DNS = 10.8.0.1
[Peer]
PublicKey = <öffentlicher Schlüssel des Servers>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.8.0.0/24
PersistentKeepalive = 25Mit AllowedIPs = 10.8.0.0/24 geht nur der Verkehr ins Firmennetz durch den Tunnel, alles andere läuft weiter direkt ins Internet. Soll der gesamte Verkehr durch den Tunnel, steht dort 0.0.0.0/0 — und dann braucht der Server zusätzlich die beiden Dinge aus dem nächsten Abschnitt.
PersistentKeepalive hält die Verbindung durch Router und Firewalls hindurch offen. WireGuard sendet von sich aus nichts, wenn es nichts zu senden gibt; ohne diesen Eintrag vergisst ein Router die Zuordnung nach einigen Minuten, und die Gegenstelle ist von außen nicht mehr erreichbar. Die Dokumentation nennt dafür 25 Sekunden.
Wenn der ganze Verkehr durch den Tunnel soll
Zwei Dinge fehlen dem Server dann noch. Erstens die Erlaubnis, Pakete überhaupt weiterzuleiten:
# in /etc/sysctl.conf eintragen
net.ipv4.ip_forward = 1
# übernehmen
sudo sysctl -pZweitens eine Regel, die den Verkehr aus dem Tunnel auf die Internetadresse des Servers umschreibt. Üblich ist, sie an das Gerät zu hängen, damit sie mit ihm kommt und geht — eth0 ist dabei durch die tatsächliche Schnittstelle zu ersetzen:
# in den Abschnitt [Interface] des Servers
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADEBeide Richtungen gehören in die Regel. Auf einem frisch aufgesetzten Ubuntu fällt es nicht auf, wenn die Rückrichtung fehlt, weil dort ohnehin alles weitergeleitet wird — auf einem System mit Docker oder einer gehärteten Firewall schon.
Starten und dauerhaft betreiben
sudo wg-quick up wg0 # einmalig starten
sudo wg show # Status und letzter Handshake
sudo systemctl enable --now wg-quick@wg0 # beim Hochfahren mitstartenwg show ist das wichtigste Werkzeug bei der Fehlersuche. Steht dort ein aktueller latest handshake, haben sich beide Seiten erfolgreich begrüßt — ein Problem liegt dann nicht mehr an Schlüsseln oder Erreichbarkeit, sondern an Wegen oder Firewallregeln dahinter.
Steht SaveConfig = true im Abschnitt [Interface], schreibt WireGuard beim Herunterfahren den aktuellen Zustand in die Datei zurück. Alles, was Sie in der Zwischenzeit von Hand geändert haben — auch Ihre Kommentare — ist dann weg. Auf einem Server, dessen Konfiguration Sie pflegen, lassen Sie den Eintrag besser aus.
Gegenstellen bequem einrichten
Für Telefone ist Abtippen der falsche Weg. Die fertige Konfigurationsdatei lässt sich als QR-Code ausgeben, den die App einliest:
sudo apt install qrencode
qrencode -t ansiutf8 < telefon.confEine neue Gegenstelle bedeutet immer drei Schritte: Schlüsselpaar erzeugen, einen [Peer]-Abschnitt auf dem Server ergänzen, und der Gegenstelle ihre eigene Datei geben. Nach einer Änderung an den Wegen reicht ein Neuladen nicht — dann ist ein Neustart des Geräts mit systemctl restart wg-quick@wg0 nötig.
Wenn es nicht funktioniert
- Kein Handshake in
wg show: Der Server ist nicht erreichbar. Prüfen Sie, ob der UDP-Port in der Firewall offen ist und — falls der Server hinter einem Router steht — ob er dorthin weitergeleitet wird. - Handshake ja, aber nichts geht: Fast immer fehlt die Weiterleitung oder die Umschreibungsregel. Testen Sie zuerst einen Ping auf die Tunneladresse des Servers. Kommt der an, funktioniert der Tunnel und der Fehler liegt dahinter.
- Der Tunnel steht, aber Namen werden nicht aufgelöst: Der Eintrag
DNSin der Konfiguration der Gegenstelle fehlt oder zeigt auf einen Server, der durch den Tunnel nicht erreichbar ist. - Die Verbindung schläft ein:
PersistentKeepaliveauf der Seite ergänzen, die hinter einem Router sitzt. - Es funktioniert aus dem Firmen- oder Hotelnetz nicht: Dort ist ausgehendes UDP gesperrt. WireGuard beherrscht kein TCP, und das ist eine bewusste Entscheidung des Projekts. In solchen Netzen bleibt nur ein Zusatzwerkzeug — oder OpenVPN über Port 443.
Stand: 2026-09-22. Die Angaben habe ich zu diesem Zeitpunkt anhand der Dokumentation der jeweiligen Hersteller geprüft. Anbieter ändern Adressen, Bezeichnungen und Menüwege ohne Ankündigung; prüfen Sie im Zweifel die Angaben Ihres Anbieters. Wer an fremden Systemen arbeitet, braucht die Erlaubnis des Betreibers.