Sie haben WireGuard auf Ihrem VPS installiert. Sie haben drei widersprüchliche Tutorials gelesen. Die wg0.conf, die Sie eingefügt haben, pingt nicht, oder sie pingt, aber DNS leckt, oder der Kill-Switch legt Ihre gesamte Maschine lahm, wenn Sie die Verbindung trennen. Die Ursache ist fast immer dieselbe: eine Vorlage, die ohne Verständnis des ursprünglichen Kontexts kopiert wurde.
Dieser Leitfaden liefert 8 praxiserprobte wg0.conf-Vorlagen, die auf Contabo VPS S laufen, mit Anwendungsfall, bekannten Stolpersteinen und den vier Zeilen, die Sie anpassen müssen. Wählen Sie diejenige, die zu Ihrem Szenario passt, tauschen Sie die Schlüssel aus, verbinden Sie sich. Fünf Minuten.
Warum Vorlagen verwenden statt alles von Hand zu generieren
WireGuard ist bekannt für seine minimalistische Konfiguration im Vergleich zu OpenVPN, aber minimalistisch bedeutet nicht trivial. Jeder Abschnitt hat eine implizite Bedeutung, die Tutorials kopieren und einfügen, ohne sie zu erklären, und ein einziger falscher Wert kann entweder den Tunnel stillschweigend brechen oder den Verkehr unverschlüsselt lecken lassen, ohne sofort sichtbare Symptome. In den letzten sechs Monaten haben wir mehr als zwanzig Reddit-Threads gezählt, in denen Anfänger dieselbe Frage stellten: "Mein Tunnel kommt hoch, Ping funktioniert zum Server, aber keine HTTP-Verbindung funktioniert vom Client aus." In 9 von 10 Fällen war es ein falsch platzierter AllowedIPs oder ein fehlendes PostUp/PostDown.
Die untenstehenden Vorlagen decken 8 unterschiedliche, reale Einsatzszenarien ab. Jede wird mit einem Kontextkommentar geliefert, der beschreibt, für wen sie gedacht ist, was sie garantiert und die bekannten Grenzen. Wenn Ihr Fall zu 80 % zur Vorlage passt, passen Sie die verbleibenden 20 % an; wenn Ihr Fall zu keiner Vorlage passt, bauen Sie von der nächstgelegenen Vorlage aus neu und behalten nur die Direktiven, die für Sie gelten. Das ist schneller als von Grund auf neu zu beginnen und zuverlässiger als das Zusammenstückeln aus einer zufälligen Stack Overflow-Antwort von 2020.
Der andere Grund, Vorlagen zu verwenden, ist die langfristige Wartung. Wenn WireGuard 1.1 erscheint (voraussichtlich 2026-2027) mit Änderungen an den Direktiven, werden wir die Vorlagen mit den klar markierten Anpassungen neu veröffentlichen, und Sie wissen genau, welche Zeile Sie in Ihrer wg0.conf aktualisieren müssen. Es ist das VPN-Äquivalent eines versionierten Kubernetes-Manifests — der Wert liegt nicht im ursprünglichen Inhalt, sondern in der Fähigkeit, sauber darauf aufzubauen.
Gemeinsame Konventionen
Jede Vorlage folgt denselben Regeln — vereinfachen Sie Ihr mentales Modell:
- Client-Subnetz:
10.66.66.0/24(Peers.2→.254) - Öffentliche Server-Schnittstelle:
eth0(überprüfen mitip route | awk '/default/ {print $5}') - UDP-Port:
51820(änderbar, siehe Vorlage 7 Verschleierung) - Schlüssel: generiert über
wg genkey | tee server.key | wg pubkey > server.pub - Sysctl:
net.ipv4.ip_forward=1auf dem Server aktiviert (/etc/sysctl.conf) - MTU: standardmäßig 1420, bei Bedarf angepasst
PrivateKey-Blöcke unten sind Platzhalter — ersetzen Sie sie durch Ihre eigenen. Niemals diese Dateien in ein öffentliches Git-Repo einfügen.
Vorlage 1 — Standard-WireGuard-Server (1 Roadwarrior-Client)
Der häufigste Fall: Ihr Contabo VPS stellt einen Tunnel für Ihr MacBook auf Reisen bereit.
# /etc/wireguard/wg0.conf (Server)
[Interface]
PrivateKey = SERVER_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820
MTU = 1420
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
# Erics MacBook
PublicKey = CLIENT_PUBLIC_KEY_HERE
AllowedIPs = 10.66.66.2/32
Client-Seite:
# /etc/wireguard/wg0.conf (macOS/Linux-Client)
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9, 149.112.112.112
MTU = 1420
[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25
Beobachtungspunkte:
AllowedIPs = 0.0.0.0/0, ::/0leitet den gesamten Client-Verkehr über den VPS — das ist das, was Sie für ein klassisches VPN wollen.PersistentKeepalive = 25ist zwingend erforderlich, wenn der Client hinter NAT sitzt (Hotelnetzwerk, 4G) — ohne es stirbt der Tunnel nach ~3 Minuten Inaktivität.DNS = 9.9.9.9erzwingt die Quad9-Auflösung — andernfalls verwendet der Client lokalen DNS und Ihre Anfragen lecken.
Vorlage 2 — Heim-VPN (Split-Tunnel: lokales LAN ausgeschlossen)
Sie möchten VPN für Ihren Webverkehr, aber lokalen LAN-Zugriff (Drucker, NAS) ohne den Tunnel beibehalten.
# Heim-Client
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9
MTU = 1420
[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
# Alles außer RFC1918 LAN + Multicast + APIPA
AllowedIPs = 0.0.0.0/1, 128.0.0.0/2, 192.0.0.0/3, 224.0.0.0/4, 240.0.0.0/5, 248.0.0.0/6, 252.0.0.0/7, 254.0.0.0/8, 255.0.0.0/9
PersistentKeepalive = 25
Der fragmentierte Subnetz-Trick (anstelle von 0.0.0.0/0) lässt WireGuard spezifische Routen hinzufügen, die die Standardroute nicht überschreiben. Ihr 192.168.x.x und 10.x.x.x LAN bleiben direkt erreichbar.
Online-Tools zur Generierung dieser Bereiche: wg-allowed-ips.compute() oder Tunsafe / WireGuard Network Calc.
Vorlage 3 — Reise-VPN mit striktem Netfilter-Kill-Switch
Sie fliegen nach China, Iran, Russland. Wenn der Tunnel abbricht, leckt nichts. Lösung: Netfilter-Kill-Switch, der alles außer Verkehr über wg0 und den Server-Handshake blockiert.
# Reise-Kill-Switch-Client
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9
MTU = 1280
PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PostUp = ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25
Diese vier PostUp/PreDown-Zeilen sind der echte Kill-Switch — kein Popup einer Anwendung. Bis wg-quick down wg0 ausgeführt wird, verlässt kein Paket die Schnittstelle, das nicht WireGuard-markiert ist.
MTU 1280 für anspruchsvolle Netzwerke (Hotels, 3G). 1 % Durchsatzverlust ist besser als ein instabiler Tunnel.
Vorlage 4 — Multi-Peer (5 Geräte, derselbe Benutzer)
Sie haben ein MacBook, iPhone, iPad, Arbeits-VPS, Raspberry Pi. Sie möchten, dass alle über dasselbe VPN mit separaten Subnetzen für die Überwachung geroutet werden.
# /etc/wireguard/wg0.conf (Server)
[Interface]
PrivateKey = SERVER_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
# MacBook
PublicKey = MAC_PUBKEY
AllowedIPs = 10.66.66.2/32
[Peer]
# iPhone
PublicKey = IPHONE_PUBKEY
AllowedIPs = 10.66.66.3/32
[Peer]
# iPad
PublicKey = IPAD_PUBKEY
AllowedIPs = 10.66.66.4/32
[Peer]
# Arbeits-VPS (Hetzner)
PublicKey = WORKER_PUBKEY
AllowedIPs = 10.66.66.5/32
[Peer]
# Raspberry Pi zuhause
PublicKey = RPI_PUBKEY
AllowedIPs = 10.66.66.6/32
Jeder Peer hat eine feste IP im 10.66.66.0/24-Subnetz. Wenn Sie über Prometheus überwachen (siehe den Überwachungsleitfaden), können Sie nach IP kennzeichnen und wissen, wer wie viel Bandbreite verbraucht.
Vorlage 5 — Hub-and-Spoke (Peer-to-Peer zwischen Clients)
Standardmäßig routet WireGuard nicht zwischen Peers. Wenn Sie möchten, dass Ihr iPhone mit Ihrem Raspberry Pi über den Hub-Server kommuniziert:
Auf dem Server hinzufügen:
sysctl -w net.ipv4.ip_forward=1
Und in den [Peer]-Blöcken des Servers AllowedIPs = 10.66.66.X/32 (eindeutige IP des Peers) festlegen.
Auf den Clients AllowedIPs ändern:
[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
# Ganzes Subnetz, nicht nur 0.0.0.0/0
AllowedIPs = 10.66.66.0/24
Jetzt können Sie von Ihrem iPhone (10.66.66.3) direkt ssh pi@10.66.66.6 ausführen — der Hub leitet weiter.
Vorlage 6 — Egress-Beschränkung pro Peer (Erlaubnisliste)
Fortgeschrittener Fall: Ein Peer (Ihr Kind, ein Gast, ein automatisierter Dienst) sollte sich mit dem Tunnel verbinden aber nur bestimmte Domains/IPs erreichen.
Zum Server-PostUp hinzufügen, zusätzlich zu MASQUERADE:
iptables -A FORWARD -s 10.66.66.50/32 -d 1.1.1.1 -j ACCEPT
iptables -A FORWARD -s 10.66.66.50/32 -d 142.250.0.0/15 -j ACCEPT # Google
iptables -A FORWARD -s 10.66.66.50/32 -j REJECT
Peer 10.66.66.50 kann nur 1.1.1.1 (DNS) und Google-IPs erreichen. Alles andere wird abgelehnt.
Vorlage 7 — Verschleierung auf Port 443 via udp2raw
Einige Unternehmensfirewalls blockieren ausgehendes UDP. Lösung: WireGuard in falsches TCP/443 über udp2raw einkapseln.
Server-Seite:
udp2raw_amd64 -s -l 0.0.0.0:443 -r 127.0.0.1:51820 -k "p@ssw0rd_long" --raw-mode faketcp
Client-Seite:
udp2raw_amd64 -c -l 127.0.0.1:50000 -r vpn.example.com:443 -k "p@ssw0rd_long" --raw-mode faketcp
Im Client wg0.conf, Endpoint ändern:
Endpoint = 127.0.0.1:50000
Der Durchsatz sinkt (~30 % Overhead), aber es tunnelt durch fast jede Unternehmens-DPI.
Vorlage 8 — Site-to-Site (zwei LANs verbunden)
Zwei Häuser, zwei Raspberry Pi Gateways, ein Contabo VPS als Hub. Jedes LAN sieht das andere, als wäre es lokal.
Server (VPS-Hub):
[Interface]
PrivateKey = HUB_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
[Peer]
# Standort A (LAN 192.168.10.0/24)
PublicKey = SITE_A_PUBKEY
AllowedIPs = 10.66.66.10/32, 192.168.10.0/24
[Peer]
# Standort B (LAN 192.168.20.0/24)
PublicKey = SITE_B_PUBKEY
AllowedIPs = 10.66.66.20/32, 192.168.20.0/24
Standort A (Raspberry Pi):
[Interface]
PrivateKey = SITE_A_PRIVATE_KEY_HERE
Address = 10.66.66.10/24
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
[Peer]
PublicKey = HUB_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 10.66.66.0/24, 192.168.20.0/24
PersistentKeepalive = 25
Vergessen Sie nicht ip_forward auf beiden Raspberries und eine statische Route auf anderen LAN-Maschinen, wenn sie von der anderen Seite antworten müssen.
Schnelle Diagnose, wenn nichts funktioniert
Sie haben die Vorlage eingefügt, Sie führen wg-quick up wg0 aus, es startet — aber Ping schlägt fehl. Checkliste in dieser Reihenfolge:
wg show: letzter Handshake aktuell? Wenn "nie" → Handshake KO, überprüfen SieEndpoint, UDP-Port auf der Server-Firewall (ufw statusoderiptables -L).ip routeauf dem Client: Route zum VPN-Subnetz vorhanden? Wenn nicht → ClientAllowedIPsfehlerhaft.dig @9.9.9.9 ifconfig.me +shortvom verbundenen Client: Gibt es die VPS-IP zurück? Wenn nicht → MASQUERADE fehlt auf dem Server oderip_forward = 0.tcpdump -i wg0auf dem Server: Sehen Sie eingehende Pakete? Wenn ja, aber nichts verlässteth0→ FORWARD/MASQUERADE-Regel fehlt.- MTU:
ping -M do -s 1400 1.1.1.1vom Client. Wenn "Frag benötigt" → MTU inwg0.confauf 1380 oder 1280 senken.
Wenn Sie von Grund auf neu beginnen und feststecken, führt der Contabo Schritt-für-Schritt-Einrichtungsleitfaden die gesamte Installation von der ersten SSH aus durch.
In Produktion: Was diese Vorlagen auslassen
Sie sind absichtlich minimal. Für den langfristigen Einsatz planen Sie:
- Regelmäßige Sicherung von
/etc/wireguard/(Verlust des Server-Schlüssels = alle Clients neu generieren) - Schlüsselrotation alle 12-18 Monate (Vorgehensweise: neuen Schlüssel generieren, parallelen Peer hinzufügen, Clients einzeln migrieren, alten Peer zurückziehen)
- Überwachung über Prometheus +
wireguard_exporter(siehe Überwachungsleitfaden) - Fail2ban auf UDP-Port 51820, wenn Sie Port-Scan-Versuche in
journalctl -u wg-quick@wg0bemerken - Pro-Peer-Bandbreitenbegrenzung über
tc(Linux Traffic Control), wenn ein Peer den Durchsatz beansprucht
Und vor allem: niemals eine echte wg0.conf in ein Repo einfügen, selbst nicht in ein privates. Halten Sie sie .gitignore'd oder verschlüsseln Sie sie mit age / sops.
Wenn WireGuard nicht ausreicht: V2Ray für zensierte Länder
WireGuard ist hervorragend für Standard-Datenschutzanwendungen. Allerdings wird das normale WireGuard (einschließlich NordLynx) jetzt systematisch von Chinas Great Firewall blockiert und zunehmend in Russland und Iran gefiltert — GFWs ML-DPI erkennt WireGuard-Sitzungen innerhalb von Minuten.
Wenn Ihr Ziel darin besteht, aktive Zensur (China, Iran, Russland) zu umgehen, helfen WireGuard-Vorlagen allein nicht. Sie benötigen Verschleierung: entweder WireGuard + Cloak (TLS-Verschleierungsschicht) oder einen vollständigen Protokollwechsel zu V2Ray VMess/VLESS mit REALITY für China, Iran, Russland. V2Rays REALITY-Protokoll macht Ihren Server von einem Microsoft-CDN-Knoten nicht unterscheidbar — der aktuelle Stand der Technik gegen GFWs Deep Packet Inspection im Jahr 2026.
Tiefergehende Informationen
Wenn Sie verstehen möchten, warum WireGuard OpenVPN bei gleicher CPU-Leistung übertrifft, haben wir einen detaillierten technischen Vergleich mit realen iperf3-Benchmarks auf Contabo, Kernel-Modul vs. Userspace und iPhone-Akku-Profil durchgeführt.
Und für den Leckschutz-Teil zeigt der Linux-Kill-Switch-Leitfaden (iptables + systemd), wie man garantiert, dass kein Leck auftritt, selbst wenn WireGuard abstürzt.
Bevorzugen Sie einen visuellen Assistenten gegenüber rohen INI-Blöcken? Unser WireGuard-Konfigurationsgenerator nimmt Ihre Server-IP, Ihr Subnetz und die Anzahl der Peers und gibt eine einsatzbereite wg0.conf in weniger als einer Minute aus. Und um zu überprüfen, ob der Contabo VPS S günstiger ist als Ihr aktueller NordVPN-Plan über 2 Jahre, geben Sie die Zahlen in unseren Kostenrechner für selbst gehostete VPNs ein.
Jede der oben genannten Vorlagen ist so konzipiert, dass sie auf einem Contabo VPS S für 4,99 €/Monat (/go/contabo-vps-2y) läuft — genug Spielraum für einen stabilen Produktionstunnel plus andere selbst gehostete Dienste daneben.
★ Nürnberger DSGVO-Rechenzentrum · ✓ Dedizierte IPv4 inklusive · 200+ Mbps garantiert
Self-host your VPN on your own VPS → ContaboFull root access · public IPv4 · pick your region→