{"id":56,"date":"2026-06-11T16:25:33","date_gmt":"2026-06-11T16:25:33","guid":{"rendered":"https:\/\/shattered.io\/at\/2026\/06\/11\/wireguard-einrichten\/"},"modified":"2026-06-11T16:25:33","modified_gmt":"2026-06-11T16:25:33","slug":"wireguard-einrichten","status":"publish","type":"post","link":"https:\/\/shattered.io\/at\/2026\/06\/11\/wireguard-einrichten\/","title":{"rendered":"WireGuard einrichten: VPN-Server in 12 Schritten [2026]"},"content":{"rendered":"\n

Ein eigener VPN-Server kostet weniger als ein Kaffee pro Monat und gibt dir die volle Kontrolle \u00fcber deinen verschl\u00fcsselten Datenverkehr. WireGuard einrichten<\/strong> dauert mit dieser Anleitung rund 30 Minuten, selbst wenn du noch nie einen Linux-Server administriert hast. WireGuard steckt seit Kernel 5.6 fest im Linux-Kern, besteht aus nur etwa 4.000 Zeilen Code und nutzt moderne Kryptografie wie Curve25519 und ChaCha20. Das Ergebnis: ein schlankes, schnelles und auditierbares VPN, das kommerzielle Dienste in puncto Geschwindigkeit deutlich abh\u00e4ngt.<\/p>\n\n\n\n

In dieser Schritt-f\u00fcr-Schritt-Anleitung baust du einen kompletten WireGuard-Server auf Ubuntu 24.04 LTS auf, verbindest Desktop und Smartphone (per QR-Code) und h\u00e4rtest die Installation f\u00fcr den Dauerbetrieb. Du bekommst kopierfertige Konfigurationen, echte Ausgabebeispiele, eine Troubleshooting-Tabelle mit acht L\u00f6sungen und Profi-Tipps f\u00fcr mehrere Clients, Split-Tunneling und IPv6. Alle Befehle sind f\u00fcr \u00d6sterreich und den deutschsprachigen Raum getestet und auf dem Stand von 2026.<\/p>\n\n\n\n

Was ist WireGuard und warum 2026 die erste Wahl?<\/h2>\n\n\n\n

WireGuard ist ein modernes VPN-Protokoll, das der Sicherheitsforscher Jason A. Donenfeld entwickelt hat. Sein Designziel war radikale Einfachheit: weniger Code bedeutet weniger Angriffsfl\u00e4che und eine kleinere Menge, die Sicherheitsforscher pr\u00fcfen m\u00fcssen. W\u00e4hrend OpenVPN auf \u00fcber 100.000 Zeilen Code kommt und klassische IPsec-Stacks noch deutlich umfangreicher sind, bringt es das WireGuard-Kernmodul auf rund 4.000 Zeilen. Diese Zahl stammt aus dem offiziellen WireGuard-Whitepaper und ist der wichtigste Grund f\u00fcr die hohe Vertrauensw\u00fcrdigkeit des Projekts.<\/p>\n\n\n\n

Im M\u00e4rz 2020 wanderte WireGuard mit Linux 5.6 in die Mainline des Kernels. Seitdem l\u00e4uft das Protokoll direkt im Kernel-Space, was die hohe Geschwindigkeit und die niedrige Latenz erkl\u00e4rt. Linus Torvalds selbst bezeichnete den WireGuard-Code als ein Kunstwerk im Vergleich zu den Schrecken von OpenVPN und IPsec. Diese Einsch\u00e4tzung des Kernel-Erfinders trug ma\u00dfgeblich zur schnellen Verbreitung bei.<\/p>\n\n\n\n

Kryptografisch setzt WireGuard auf eine feste Auswahl moderner Verfahren, ganz ohne die gef\u00e4hrliche Algorithmus-Vielfalt \u00e4lterer Protokolle. Der Schl\u00fcsselaustausch l\u00e4uft \u00fcber Curve25519 (Elliptische-Kurven-Diffie-Hellman), die Verschl\u00fcsselung \u00fcbernimmt ChaCha20, die Authentifizierung der Nachrichten erledigt Poly1305. F\u00fcr die Schl\u00fcsselableitung kommen BLAKE2s und HKDF zum Einsatz, f\u00fcr interne Hashtabellen SipHash24. Der gesamte Handshake basiert auf dem Noise-Protokoll-Framework. Diese Bausteine gelten 2026 als Stand der Technik und sind in der WireGuard-Spezifikation fest verdrahtet.<\/p>\n\n\n\n

Ein praktischer Vorteil: WireGuard verbindet sich nur \u00fcber UDP, standardm\u00e4\u00dfig auf Port 51820. Es gibt kein langes Aushandeln von Zertifikaten und keine komplexe Public-Key-Infrastruktur. Stattdessen tauschst du nur \u00f6ffentliche Schl\u00fcssel aus, \u00e4hnlich wie bei SSH. Mehr Hintergrund zu Verschl\u00fcsselung im Web findest du in unserer Erkl\u00e4rung zu HTTPS und TLS<\/a>. Wer wissen will, wie sich Verschl\u00fcsselung gegen Quantencomputer wappnet, liest unseren Beitrag zur Post-Quanten-Kryptografie<\/a>.<\/p>\n\n\n\n

Voraussetzungen: Das brauchst du, bevor du WireGuard einrichten kannst<\/h2>\n\n\n\n

Bevor du loslegst, brauchst du einen Linux-Server mit \u00f6ffentlicher IP-Adresse. F\u00fcr rund 4 bis 6 Euro pro Monat bekommst du bei Anbietern wie Hetzner, netcup oder einem \u00f6sterreichischen Hoster einen kleinen virtuellen Server (VPS). Dieser reicht f\u00fcr mehrere Nutzer locker aus, da WireGuard kaum Ressourcen verbraucht. Die folgende Tabelle fasst alle Voraussetzungen mit den getesteten Versionen zusammen.<\/p>\n\n\n\n\n
Komponente<\/th>Empfohlene Version (Stand 2026)<\/th>Zweck<\/th><\/tr><\/thead>
Betriebssystem Server<\/td>Ubuntu 24.04 LTS (oder neuer) bzw. Debian 12<\/td>Stabile Basis mit Kernel-WireGuard<\/td><\/tr>\n
Linux-Kernel<\/td>5.6 oder h\u00f6her (24.04 nutzt 6.8)<\/td>Enth\u00e4lt das WireGuard-Modul nativ<\/td><\/tr>\n
wireguard-tools<\/td>1.0.20260223 (Stand Februar 2026)<\/td>Liefert die Befehle wg und wg-quick<\/td><\/tr>\n
VPS-Ressourcen<\/td>1 vCPU, 1 GB RAM, 10 GB Disk<\/td>Reicht f\u00fcr 10+ gleichzeitige Clients<\/td><\/tr>\n
Zugang<\/td>SSH mit root- oder sudo-Rechten<\/td>Administration des Servers<\/td><\/tr>\n
\u00d6ffentliche IP<\/td>Statische IPv4 (optional IPv6)<\/td>Erreichbarkeit als VPN-Endpunkt<\/td><\/tr>\n
Client<\/td>WireGuard-App f\u00fcr Windows, macOS, Linux, Android, iOS<\/td>Verbindung zum Server<\/td><\/tr>\n<\/tbody><\/table>\n\n\n\n

Auf der Client-Seite installierst du die offizielle WireGuard-App. F\u00fcr Android und iOS findest du sie kostenlos in Google Play und im App Store, f\u00fcr Windows und macOS gibt es Installer auf wireguard.com. Linux-Desktops nutzen dasselbe wg-quick-Werkzeug wie der Server. Grundlegende Kenntnisse im Umgang mit der Kommandozeile helfen dir, sind aber nicht zwingend n\u00f6tig: Du kannst die Befehle dieser Anleitung Zeile f\u00fcr Zeile kopieren.<\/p>\n\n\n\n

Wichtig: Halte die Zugangsdaten deines VPS und die sp\u00e4ter erzeugten privaten Schl\u00fcssel streng geheim. Ein privater WireGuard-Schl\u00fcssel ist wie ein Hauptschl\u00fcssel zu deinem Tunnel. Wie schnell gestohlene Zugangsdaten zum Problem werden, zeigen die F\u00e4lle in unserem Beitrag \u00fcber Datenlecks<\/a>.<\/p>\n\n\n\n

WireGuard vs. OpenVPN und IPsec: Der Technik-Vergleich<\/h2>\n\n\n\n

Warum solltest du 2026 zu WireGuard greifen und nicht zum altbew\u00e4hrten OpenVPN? Die Antwort liegt in drei Bereichen: Geschwindigkeit, Codegr\u00f6\u00dfe und Konfigurationsaufwand. WireGuard arbeitet im Kernel-Space und verzichtet auf rechenintensive Aushandlungen. In unserem ausf\u00fchrlichen Vergleich WireGuard vs. OpenVPN<\/a> erreichte WireGuard 892 Mbit\/s gegen\u00fcber 222 Mbit\/s bei OpenVPN, also rund das Vierfache an Durchsatz.<\/p>\n\n\n\n\n
Merkmal<\/th>WireGuard<\/th>OpenVPN<\/th>IPsec\/IKEv2<\/th><\/tr><\/thead>
Codegr\u00f6\u00dfe<\/td>~4.000 Zeilen<\/td>~100.000 Zeilen<\/td>Mehrere Hunderttausend Zeilen<\/td><\/tr>\n
Transport<\/td>UDP (Port 51820)<\/td>UDP oder TCP<\/td>UDP (500, 4500)<\/td><\/tr>\n
Verschl\u00fcsselung<\/td>ChaCha20-Poly1305<\/td>AES, viele Optionen<\/td>AES, viele Optionen<\/td><\/tr>\n
Schl\u00fcsselaustausch<\/td>Curve25519 (Noise)<\/td>TLS, Zertifikate<\/td>IKE, Zertifikate<\/td><\/tr>\n
Ort der Ausf\u00fchrung<\/td>Kernel-Space<\/td>User-Space<\/td>Kernel-Space<\/td><\/tr>\n
Konfiguration<\/td>Sehr einfach (Textdatei)<\/td>Komplex (PKI)<\/td>Komplex<\/td><\/tr>\n
Roaming (NAT\/WLAN-Wechsel)<\/td>Nahtlos<\/td>Verbindungsabbruch m\u00f6glich<\/td>Teilweise<\/td><\/tr>\n<\/tbody><\/table>\n\n\n\n

Der Tabelle entnimmst du den entscheidenden Punkt: WireGuard nutzt eine einzige, fest definierte Krypto-Suite. Diese Reduktion klingt nach einer Einschr\u00e4nkung, ist aber ein Sicherheitsgewinn. Bei OpenVPN und IPsec entstehen viele Schwachstellen durch falsch gew\u00e4hlte Algorithmen oder veraltete Cipher-Suites. WireGuard schlie\u00dft diese Fehlerquelle von vornherein aus. Gilt ein Verfahren irgendwann als unsicher, erscheint eine neue Protokollversion mit ausgetauschten Bausteinen, statt unz\u00e4hlige Konfigurationsoptionen offen zu halten.<\/p>\n\n\n\n

Ein weiterer Vorteil betrifft mobile Ger\u00e4te. Dank des Konzepts der Cryptokey-Routing-Tabelle und kurzer Handshakes \u00fcbersteht eine WireGuard-Verbindung den Wechsel zwischen WLAN und Mobilfunk fast unbemerkt. Dein Smartphone h\u00e4lt den Tunnel auch dann, wenn du das Netz wechselst. Bei OpenVPN brach die Verbindung in solchen Situationen h\u00e4ufig ab und musste neu aufgebaut werden.<\/p>\n\n\n\n

Schritt 1 bis 3: Server vorbereiten und WireGuard installieren<\/h2>\n\n\n\n

Verbinde dich zun\u00e4chst per SSH mit deinem Server. Ersetze die Beispiel-IP durch die echte Adresse deines VPS. Danach bringst du das System auf den neuesten Stand, denn aktuelle Pakete schlie\u00dfen bekannte Sicherheitsl\u00fccken. Das ist der wichtigste erste Schritt, bevor du irgendeinen Dienst \u00f6ffentlich erreichbar machst.<\/p>\n\n\n\n

# Schritt 1: Per SSH auf dem Server anmelden\nssh root@203.0.113.10\n\n# Schritt 2: Paketquellen aktualisieren und System upgraden\nsudo apt update && sudo apt upgrade -y\n\n# Schritt 3: WireGuard und die Werkzeuge installieren\nsudo apt install wireguard wireguard-tools qrencode -y<\/code><\/pre>\n\n\n\n
Das Paket wireguard<\/strong> zieht das Kernel-Modul und alle Abh\u00e4ngigkeiten nach, wireguard-tools<\/strong> liefert die zentralen Befehle wg<\/code> und wg-quick<\/code>. Das Paket qrencode<\/strong> brauchst du sp\u00e4ter, um Smartphone-Clients per QR-Code einzurichten. Bei Ubuntu 24.04 ist das WireGuard-Modul bereits im Kernel enthalten, du musst also nichts kompilieren.<\/p>\n\n\n\n
Pr\u00fcfe nach der Installation, ob die Werkzeuge korrekt vorliegen. Der folgende Befehl zeigt die installierte Version an. Eine Ausgabe ohne Fehlermeldung best\u00e4tigt, dass alles bereit ist.<\/p>\n\n\n\n
$ wg --version\nwireguard-tools v1.0.20260223 - https:\/\/git.zx2c4.com\/wireguard-tools\/\n\n$ lsmod | grep wireguard\nwireguard             createsize  0\nip6_udp_tunnel         16384  1 wireguard\nudp_tunnel             32768  1 wireguard<\/code><\/pre>\n\n\n\n
Falls lsmod<\/code> keine Zeile mit wireguard ausgibt, l\u00e4dst du das Modul manuell mit sudo modprobe wireguard<\/code>. Auf modernen Ubuntu- und Debian-Systemen geschieht das automatisch, sobald die erste WireGuard-Schnittstelle hochf\u00e4hrt. Damit ist die Grundinstallation abgeschlossen, und du wechselst in das Konfigurationsverzeichnis \/etc\/wireguard<\/code>.<\/p>\n\n\n\n
Schritt 4 und 5: Schl\u00fcsselpaare mit Curve25519 erzeugen<\/h2>\n\n\n\n
WireGuard authentifiziert jeden Teilnehmer \u00fcber ein Schl\u00fcsselpaar aus privatem und \u00f6ffentlichem Schl\u00fcssel. Der private Schl\u00fcssel bleibt geheim auf dem jeweiligen Ger\u00e4t, der \u00f6ffentliche Schl\u00fcssel wandert zur Gegenstelle. Dieses Prinzip kennst du von SSH oder von digitalen Signaturen, die wir in unserem Beitrag zu TLS und Zertifikaten<\/a> n\u00e4her beleuchten. Wechsle zuerst in das Konfigurationsverzeichnis und setze strenge Rechte.<\/p>\n\n\n\n
# Ins WireGuard-Verzeichnis wechseln\ncd \/etc\/wireguard\n\n# Restriktive Umask setzen, damit niemand sonst die Schl\u00fcssel lesen kann\numask 077\n\n# Schritt 4: Server-Schl\u00fcsselpaar erzeugen\nwg genkey | tee server_private.key | wg pubkey > server_public.key\n\n# Schritt 5: Client-Schl\u00fcsselpaar erzeugen\nwg genkey | tee client_private.key | wg pubkey > client_public.key<\/code><\/pre>\n\n\n\n
Der Befehl wg genkey<\/code> erzeugt einen zuf\u00e4lligen privaten Curve25519-Schl\u00fcssel. Die Pipe an tee<\/code> speichert ihn in eine Datei und leitet ihn gleichzeitig an wg pubkey<\/code> weiter, das daraus den passenden \u00f6ffentlichen Schl\u00fcssel berechnet. Die umask 077<\/code> sorgt daf\u00fcr, dass nur der Eigent\u00fcmer (root) die Dateien lesen darf. Das ist entscheidend, denn ein offen lesbarer privater Schl\u00fcssel kompromittiert deinen gesamten Tunnel.<\/p>\n\n\n\n
Lass dir die vier Schl\u00fcssel anzeigen und notiere sie. Du f\u00fcgst sie gleich in die Konfigurationsdateien ein. Achte penibel darauf, private und \u00f6ffentliche Schl\u00fcssel nicht zu verwechseln, denn das ist die h\u00e4ufigste Fehlerquelle beim ersten Aufbau.<\/p>\n\n\n\n
$ cat server_private.key\noK7m...gekuerzt...=  (privat, bleibt auf dem Server)\n\n$ cat server_public.key\nHIGr...gekuerzt...=  (oeffentlich, kommt in die Client-Config)\n\n$ cat client_public.key\nqm2T...gekuerzt...=  (oeffentlich, kommt in die Server-Config)<\/code><\/pre>\n\n\n\n
Schritt 6: Die Server-Konfiguration wg0.conf erstellen<\/h2>\n\n\n\n
Jetzt baust du die zentrale Konfigurationsdatei \/etc\/wireguard\/wg0.conf<\/code>. Der Name wg0 bezeichnet die virtuelle Netzwerkschnittstelle. Du legst ein privates Tunnel-Subnetz fest (hier 10.8.0.0\/24), den Lauschport und die NAT-Regeln. \u00d6ffne die Datei mit einem Editor wie nano.<\/p>\n\n\n\n
sudo nano \/etc\/wireguard\/wg0.conf<\/code><\/pre>\n\n\n\n
Trage den folgenden Inhalt ein. Ersetze SERVER_PRIVATE_KEY durch den Inhalt von server_private.key und CLIENT_PUBLIC_KEY durch den Inhalt von client_public.key. Pr\u00fcfe mit ip route list default<\/code>, wie deine \u00f6ffentliche Netzwerkschnittstelle hei\u00dft (oft eth0 oder ens3), und passe den Namen in den PostUp- und PostDown-Zeilen an.<\/p>\n\n\n\n
[Interface]\n# Privater Schluessel des Servers\nPrivateKey = SERVER_PRIVATE_KEY\n# Tunnel-IP des Servers im VPN-Subnetz\nAddress = 10.8.0.1\/24\n# UDP-Port, auf dem WireGuard lauscht\nListenPort = 51820\n\n# NAT-Regel beim Start setzen, beim Stopp entfernen\nPostUp   = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE\nPostUp   = iptables -A FORWARD -i wg0 -j ACCEPT\nPostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE\nPostDown = iptables -D FORWARD -i wg0 -j ACCEPT\n\n[Peer]\n# Oeffentlicher Schluessel des Clients\nPublicKey = CLIENT_PUBLIC_KEY\n# Welche Tunnel-IP darf dieser Client nutzen\nAllowedIPs = 10.8.0.2\/32<\/code><\/pre>\n\n\n\n
Der Abschnitt [Interface]<\/strong> beschreibt den Server selbst. Address<\/strong> vergibt ihm die VPN-interne IP 10.8.0.1. ListenPort<\/strong> legt den UDP-Port fest. Die PostUp<\/strong>-Zeilen werden ausgef\u00fchrt, sobald die Schnittstelle hochf\u00e4hrt: Die MASQUERADE-Regel ersetzt die Absenderadresse der Client-Pakete durch die Server-IP, damit Antworten den Weg zur\u00fcck durch den Tunnel finden. Die FORWARD-Regel erlaubt die Weiterleitung. PostDown<\/strong> r\u00e4umt diese Regeln beim Herunterfahren wieder auf.<\/p>\n\n\n\n
Der Abschnitt [Peer]<\/strong> beschreibt den Client. AllowedIPs<\/strong> hat hier eine doppelte Bedeutung: Auf der Serverseite legt der Wert mit dem \/32-Suffix fest, dass genau diese eine Tunnel-IP zu diesem Client geh\u00f6rt. Das ist gleichzeitig eine Zugriffskontrolle, denn Pakete von anderen IPs lehnt der Server ab. Speichere die Datei mit Strg+O und verlasse nano mit Strg+X.<\/p>\n\n\n\n
Schritt 7: IP-Forwarding und NAT dauerhaft aktivieren<\/h2>\n\n\n\n
Damit dein Server Pakete zwischen dem Tunnel und dem Internet weiterleitet, musst du das IP-Forwarding im Kernel aktivieren. Standardm\u00e4\u00dfig ist es aus Sicherheitsgr\u00fcnden deaktiviert. Du schaltest es sowohl sofort als auch dauerhaft ein, damit die Einstellung einen Neustart \u00fcbersteht.<\/p>\n\n\n\n
# Sofort aktivieren (gilt bis zum naechsten Neustart)\nsudo sysctl -w net.ipv4.ip_forward=1\n\n# Dauerhaft aktivieren: eigene Konfigurationsdatei anlegen\necho \"net.ipv4.ip_forward=1\" | sudo tee \/etc\/sysctl.d\/99-wireguard.conf\necho \"net.ipv6.conf.all.forwarding=1\" | sudo tee -a \/etc\/sysctl.d\/99-wireguard.conf\n\n# Alle sysctl-Einstellungen neu einlesen\nsudo sysctl --system<\/code><\/pre>\n\n\n\n
Die erste Zeile aktiviert das Forwarding sofort im laufenden Betrieb. Die zweite und dritte Zeile schreiben die Einstellung in eine eigene Datei unter \/etc\/sysctl.d\/<\/code>. Diese Methode ist sauberer als das direkte Editieren der zentralen \/etc\/sysctl.conf<\/code>, weil deine Anpassungen klar getrennt bleiben. Die letzte Zeile l\u00e4dt alle Einstellungen neu, sodass keine L\u00fccke entsteht.<\/p>\n\n\n\n
Kontrolliere das Ergebnis mit dem folgenden Befehl. Eine Ausgabe von 1 best\u00e4tigt, dass die Weiterleitung aktiv ist. Ohne diesen Schritt baust du zwar eine Verbindung zum Server auf, kommst aber nicht ins Internet. Das ist eines der h\u00e4ufigsten Probleme, das wir weiter unten in der Fehlertabelle aufgreifen.<\/p>\n\n\n\n
$ sysctl net.ipv4.ip_forward\nnet.ipv4.ip_forward = 1<\/code><\/pre>\n\n\n\n
Schritt 8: Firewall mit UFW konfigurieren und Port 51820 \u00f6ffnen<\/h2>\n\n\n\n
Ohne offenen Port erreicht dich kein Client. Du \u00f6ffnest den UDP-Port 51820 f\u00fcr WireGuard und beh\u00e4ltst gleichzeitig deinen SSH-Zugang. Die unkomplizierte Firewall UFW ist auf Ubuntu vorinstalliert und macht das Regelwerk \u00fcbersichtlich. Achte unbedingt darauf, zuerst SSH freizugeben, sonst sperrst du dich selbst aus.<\/p>\n\n\n\n
# Zuerst SSH erlauben, damit du dich nicht aussperrst\nsudo ufw allow OpenSSH\n\n# WireGuard-Port (UDP 51820) freigeben\nsudo ufw allow 51820\/udp\n\n# Firewall aktivieren\nsudo ufw enable\n\n# Status mit Regeln anzeigen\nsudo ufw status verbose<\/code><\/pre>\n\n\n\n
Die erwartete Ausgabe listet beide Regeln auf. Falls du einen Cloud-Anbieter wie Hetzner oder AWS nutzt, pr\u00fcfe zus\u00e4tzlich dessen vorgelagerte Sicherheitsgruppe oder Cloud-Firewall im Webinterface. Diese blockiert UDP 51820 unter Umst\u00e4nden, bevor die Pakete \u00fcberhaupt deinen Server erreichen. Das ist eine h\u00e4ufige, schwer zu findende Stolperfalle.<\/p>\n\n\n\n
$ sudo ufw status verbose\nStatus: active\n\nTo                         Action      From\n--                         ------      ----\nOpenSSH                    ALLOW IN    Anywhere\n51820\/udp                  ALLOW IN    Anywhere\nOpenSSH (v6)               ALLOW IN    Anywhere (v6)\n51820\/udp (v6)             ALLOW IN    Anywhere (v6)<\/code><\/pre>\n\n\n\n
Schritt 9: WireGuard-Dienst starten und beim Boot aktivieren<\/h2>\n\n\n\n
Jetzt f\u00e4hrst du die WireGuard-Schnittstelle hoch. Das Werkzeug wg-quick<\/code> liest deine wg0.conf, erzeugt die Schnittstelle, setzt die Routen und f\u00fchrt die PostUp-Regeln aus. Danach aktivierst du den passenden systemd-Dienst, damit WireGuard nach jedem Neustart automatisch startet.<\/p>\n\n\n\n
# Schnittstelle wg0 sofort starten\nsudo wg-quick up wg0\n\n# Dienst dauerhaft beim Systemstart aktivieren\nsudo systemctl enable wg-quick@wg0\n\n# Status der Schnittstelle pruefen\nsudo wg show<\/code><\/pre>\n\n\n\n
Der Befehl sudo wg show<\/code> ist dein wichtigstes Diagnosewerkzeug. Er zeigt die \u00f6ffentliche Schl\u00fcsselkennung, den Lauschport und alle konfigurierten Peers. Solange noch kein Client verbunden ist, fehlt die Zeile mit dem letzten Handshake. Das ist normal. Eine typische Ausgabe direkt nach dem Start sieht so aus:<\/p>\n\n\n\n
$ sudo wg show\ninterface: wg0\n  public key: HIGr...gekuerzt...=\n  private key: (hidden)\n  listening port: 51820\n\npeer: qm2T...gekuerzt...=\n  allowed ips: 10.8.0.2\/32<\/code><\/pre>\n\n\n\n
Falls wg-quick up wg0<\/code> mit einer Fehlermeldung abbricht, liegt meist ein Tippfehler in der wg0.conf vor. H\u00e4ufige Ursachen sind ein fehlerhaft kopierter Schl\u00fcssel oder ein falscher Schnittstellenname in der PostUp-Zeile. Mit sudo wg-quick down wg0<\/code> f\u00e4hrst du die Schnittstelle wieder herunter, korrigierst die Datei und startest erneut.<\/p>\n\n\n\n
Schritt 10: Client einrichten f\u00fcr Desktop und Smartphone<\/h2>\n\n\n\n
Der Server l\u00e4uft, nun fehlt die Client-Konfiguration. Diese Datei kommt auf das Endger\u00e4t, also auf deinen Laptop oder dein Smartphone. Erstelle auf dem Server eine Datei client.conf<\/code> mit dem folgenden Inhalt. Trage CLIENT_PRIVATE_KEY (aus client_private.key) und SERVER_PUBLIC_KEY (aus server_public.key) ein und ersetze die Beispiel-IP durch die \u00f6ffentliche Adresse deines Servers.<\/p>\n\n\n\n
[Interface]\n# Privater Schluessel des Clients\nPrivateKey = CLIENT_PRIVATE_KEY\n# Tunnel-IP des Clients\nAddress = 10.8.0.2\/24\n# DNS-Server, der ueber den Tunnel genutzt wird\nDNS = 1.1.1.1\n\n[Peer]\n# Oeffentlicher Schluessel des Servers\nPublicKey = SERVER_PUBLIC_KEY\n# Gesamter Verkehr durch den Tunnel (Full-Tunnel)\nAllowedIPs = 0.0.0.0\/0, ::\/0\n# Oeffentliche IP und Port des Servers\nEndpoint = 203.0.113.10:51820\n# Verbindung durch NAT aufrechterhalten\nPersistentKeepalive = 25<\/code><\/pre>\n\n\n\n
Die Einstellung AllowedIPs = 0.0.0.0\/0, ::\/0<\/strong> auf der Client-Seite leitet den gesamten Datenverkehr (IPv4 und IPv6) durch den Tunnel. Das ist der klassische Full-Tunnel-Modus, mit dem du deine echte IP verbirgst und in \u00f6ffentlichen WLANs sicher surfst. PersistentKeepalive = 25<\/strong> sendet alle 25 Sekunden ein kleines Paket, damit NAT-Router und Firewalls die Verbindung nicht vorzeitig schlie\u00dfen. Das ist besonders f\u00fcr Ger\u00e4te hinter einem Heim-Router wichtig.<\/p>\n\n\n\n
Smartphone per QR-Code verbinden<\/h3>\n\n\n\n
F\u00fcr Android und iOS musst du die Konfiguration nicht abtippen. Du erzeugst aus der client.conf einen QR-Code direkt im Terminal und scannst ihn mit der WireGuard-App. Dieser Trick spart Zeit und vermeidet Tippfehler in den langen Schl\u00fcsseln.<\/p>\n\n\n\n
# QR-Code direkt im Terminal anzeigen\nqrencode -t ansiutf8 < client.conf\n\n# Alternativ als PNG-Bild speichern\nqrencode -o client-qr.png < client.conf<\/code><\/pre>\n\n\n\n
\u00d6ffne die WireGuard-App auf dem Smartphone, tippe auf das Plus-Symbol und w\u00e4hle Aus QR-Code erstellen. Scanne den im Terminal angezeigten Code, vergib einen Namen und aktiviere den Tunnel mit dem Schalter. Auf dem Desktop importierst du die client.conf stattdessen \u00fcber Tunnel importieren in der WireGuard-App. Wichtig: L\u00f6sche die client.conf und das PNG nach dem Import vom Server, da sie den privaten Client-Schl\u00fcssel im Klartext enthalten.<\/p>\n\n\n\n
Schritt 11: Verbindung testen und DNS-Leaks pr\u00fcfen<\/h2>\n\n\n\n
Aktiviere den Tunnel auf deinem Client und pr\u00fcfe, ob alles funktioniert. Der erste Test ist der Handshake. F\u00fchre auf dem Server erneut sudo wg show<\/code> aus. Jetzt sollte eine Zeile mit dem Zeitpunkt des letzten Handshakes und den \u00fcbertragenen Datenmengen erscheinen. Das beweist, dass die kryptografische Verbindung steht.<\/p>\n\n\n\n
$ sudo wg show\ninterface: wg0\n  public key: HIGr...gekuerzt...=\n  listening port: 51820\n\npeer: qm2T...gekuerzt...=\n  endpoint: 84.115.xxx.xxx:54213\n  allowed ips: 10.8.0.2\/32\n  latest handshake: 18 seconds ago\n  transfer: 1.24 MiB received, 940.51 KiB sent<\/code><\/pre>\n\n\n\n
Pr\u00fcfe als N\u00e4chstes auf dem Client, ob deine \u00f6ffentliche IP-Adresse jetzt die deines Servers ist. Rufe dazu eine Seite wie ifconfig.me oder ip.me im Browser auf, oder nutze die Kommandozeile. Erscheint die IP deines VPS, l\u00e4uft der Full-Tunnel korrekt. Zum Schluss testest du auf DNS-Leaks, also ob DNS-Anfragen versehentlich an deinen lokalen Provider gehen.<\/p>\n\n\n\n
# Oeffentliche IP pruefen (sollte die Server-IP sein)\ncurl https:\/\/ifconfig.me\n\n# DNS-Test: Aufloesung sollte ueber 1.1.1.1 laufen\nnslookup shattered.io<\/code><\/pre>\n\n\n\n
F\u00fcr eine gr\u00fcndliche Pr\u00fcfung auf undichte Stellen rufst du im Browser einen DNS-Leak-Test auf. Zeigt dieser ausschlie\u00dflich den im Client gesetzten Resolver (hier Cloudflare 1.1.1.1) und nicht deinen heimischen Provider an, ist alles dicht. Wer mehr \u00fcber sichere Namensaufl\u00f6sung erfahren will, findet in unserem Privacy-Bereich<\/a> weiterf\u00fchrende Artikel.<\/p>\n\n\n\n
Schritt 12: Server h\u00e4rten und absichern<\/h2>\n\n\n\n
Ein laufender Tunnel ist nicht automatisch ein sicherer Server. Mit ein paar Ma\u00dfnahmen reduzierst du die Angriffsfl\u00e4che deutlich. Diese Schritte geh\u00f6ren 2026 zum Pflichtprogramm f\u00fcr jeden \u00f6ffentlich erreichbaren Linux-Server, nicht nur f\u00fcr VPN-Gateways.<\/p>\n\n\n\n