Dual-Stack (IPv4 + IPv6) WireGuard VPN-Server mit Unbound DNS auf Netcup aufbauen
Da jeder Netcup VPS und Root Server auf hardwaregestützter KVM-Virtualisierung mit eigenem Linux-Kernel, bis zu 2,5 Gbit/s schnellen Netzwerkschnittstellen, einem gerouteten /64-IPv6-Subnetz und großzügigem Fair-Use-Inklusivtraffic an den Standorten Nürnberg, Wien, Amsterdam, Manassas und Singapur basiert, übertrifft selbst ein kompakter Netcup Einstiegs-VPS (wie der VPS pico G11.5s mit 1 GB RAM oder der VPS nano G11.5s mit 2 GB RAM) kommerzielle Consumer-VPN-Abonnements deutlich. Dieser Systems-Engineering-Leitfaden baut ein gehärtetes Dual-Stack-(IPv4 + IPv6)-WireGuard-VPN-Gateway auf – komplett mit MTU 1420-Kapselungsberechnung, TCP MSS Clamping gegen PMTU-Blackholes, einem lokalen rekursiven Unbound-DNS-Resolver ohne DNS-Leaks und einem automatisierten Peer-Provisioning-Skript mit quantensicheren PresharedKey-Schlüsseln.
wireguard-tools und unbound 1.19 auf einer Netcup-KVM-Instanz in Nürnberg (AS197540) mit Dual-Stack IPv4-/32- und IPv6-/64-Routing. VORAUSSETZUNGEN // ANFORDERUNGEN
CHECKLISTE- ✓ Ein beliebiger Netcup KVM VPS (einschließlich der kompakten Modelle VPS pico G11.5s, VPS nano G11.5s, VPS 500 G12.5 oder VPS 1000 G12.5) oder Root Server (wie der RS 1000 G12.5) mit Ubuntu 24.04 LTS oder Debian 12
- ✓ Freigegebener eingehender UDP-Port
51820in UFW und in der Netcup SCP Firewall - ✓ Root- oder
sudo-SSH-Zugang
Wichtige Erkenntnisse (Key Takeaways)
KURZFAZIT- 01 WireGuard läuft auf Netcup KVM-Servern direkt im Linux-Kernel 6.8+ mit ChaCha20-Poly1305-SIMD-Beschleunigung und liefert selbst auf einem 2-vCore-VPS problemlos über 800 Mbit/s Durchsatz.
-
02 Berechnen und setzen Sie
MTU = 1420explizit auf Server- und Client-Interfaces, um den Overhead von IPv6 (40 Bytes) + UDP (8 Bytes) + WireGuard-Header/Tag (32 Bytes) innerhalb von 1500-Byte-virtio-net-Frames abzufangen. -
03 Konfigurieren Sie TCP MSS Clamping (
--clamp-mss-to-pmtu) inPostUp, damit TLS-Handshakes über Mobilfunknetze (5G/LTE) oder PPPoE-DSL-Anschlüsse niemals durch verworfene ICMP-Fragmentierungspakete hängen bleiben. -
04 Tunneln Sie in Client-Profilen immer sowohl IPv4 (
0.0.0.0/0) als auch IPv6 (::/0); fehlt IPv6, leiten moderne Smartphones und Dual-Stack-WLANs den Datenverkehr am VPN-Tunnel vorbei. -
05 Betreiben Sie einen lokalen rekursiven
Unbound-DNS-Resolver, der strikt an daswg0-Interface (10.66.66.1,fd42:66:66::1) gebunden ist und DNSSEC-Validierung sowie QNAME-Minimierung erzwingt.
📑 Inhaltsverzeichnis (5 Abschnitte) ▼
- 01 Schritt 1: Netcup virtio-net MTU-Kapselung verstehen & Kernel-Forwarding aktivieren
- 02 Schritt 2: wireguard-tools installieren und kryptografische Schlüsselhierarchie aufbauen
- 03 Schritt 3: Lokalen rekursiven Unbound-DNS-Resolver ohne DNS-Leaks konfigurieren
- 04 Schritt 4: /etc/wireguard/wg0.conf mit Dual-Stack-NAT & TCP MSS Clamping erstellen
- 05 Schritt 5: Automatisiertes Peer-Provisioning-Skript mit PresharedKey & QR-Code-Generator
Schritt 1: Netcup virtio-net MTU-Kapselung verstehen & Kernel-Forwarding aktivieren
Die häufigste Ursache für träge oder abbrechende Verbindungen auf selbst gehosteten WireGuard-Servern ist eine falsch dimensionierte Maximum Transmission Unit (MTU) in Kombination mit fehlendem TCP Maximum Segment Size (MSS) Clamping. Auf Netcup KVM-Instanzen arbeitet die primäre virtuelle Netzwerkkarte (eth0 oder ens3 auf Basis von virtio_net) mit einer Standard-Ethernet-MTU von 1500 Bytes.
Wenn sich ein Client über IPv6 (oder IPv4) mit Ihrem Netcup-WireGuard-Endpunkt verbindet, wird jedes innere Tunnel-Paket in zusätzliche äußere Protokoll-Header verpackt. Wird die MTU des inneren WireGuard-Interfaces (wg0) nicht um mindestens 80 Bytes reduziert (1500 - 80 = 1420), überschreiten die gekapselten Pakete die 1500-Byte-Grenze und lösen permanente Paketfragmentierung oder Path-MTU-Discovery-(PMTUD)-Blackholes aus.
Auf realen Zugangsnetzen der Clients verschärft sich diese Situation weiter: Viele heimische Glasfaser- und VDSL-Anschlüsse nutzen PPPoE-Kapselung (die die äußere Pfad-MTU auf 1492 Bytes senkt), während 5G/LTE-Mobilfunknetze durch GTP-Tunneling oft nur 1428 oder 1380 Bytes zulassen. Wenn ein Webserver während des TLS-1.3-Handshakes eine große Zertifikatskette mit gesetztem Don’t-Fragment-Bit (DF) sendet und ein Router auf dem Weg die ICMP Fragmentation Needed- bzw. ICMPv6 Packet Too Big-Nachricht verwirft, friert die Verbindung kommentarlos ein. Das Setzen von MTU = 1420 zusammen mit dynamischem TCP MSS Clamping (Schritt 4) verhindert solche Blackholes zuverlässig.
virtio-net 1500 MTU)| Protokollschicht | Äußerer IPv4-Transport | Äußerer IPv6-Transport | Technische Erläuterung |
|---|---|---|---|
Physische / KVM virtio-net Link-MTU | 1500 Bytes | 1500 Bytes | Überprüfbar per ip -br link show auf Ihrer Netcup-VM |
| Äußerer IP-Header | -20 Bytes (IPv4) | -40 Bytes (IPv6) | Der feste IPv6-Header ist 20 Bytes größer als IPv4 |
Äußerer UDP-Header (Port 51820) | -8 Bytes | -8 Bytes | Standard-UDP-Datagramm-Header (8 Bytes) |
| WireGuard Typ + Key-Index + Nonce | -16 Bytes | -16 Bytes | 4B Typ + 4B Empfänger-Index + 8B Zähler |
| Poly1305 Authentifizierungs-Tag | -16 Bytes | -16 Bytes | Kryptografischer 128-Bit-MAC-Integritäts-Tag |
Maximale sichere wg0-Interface-MTU | 1440 Bytes | 1420 Bytes | Nutzen Sie universell 1420 (oder 1412 für PPPoE-DSL-Clients) |
# 1. Namen des primären Netcup-Netzwerk-Interfaces ermitteln (meist eth0 oder ens3)
PRIMARY_IF=$(ip -4 route show default | awk '{print $5; exit}')
echo "Detected Primary Netcup Interface: ${PRIMARY_IF}"
# 2. Dauerhaftes Dual-Stack-IP-Forwarding und BBR-Staukontrolle konfigurieren
sudo tee /etc/sysctl.d/99-wireguard-router.conf > /dev/null <<'EOF'
# IPv4- und IPv6-Paketweiterleitung zwischen Interfaces aktivieren
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1
# Lockeres Reverse Path Filtering aktivieren, damit asymmetrische VPN-Rückpfade nicht verworfen werden
net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2
# BBR-TCP-Staukontrolle für hohen VPN-Durchsatz aktivieren
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF
sudo sysctl --system Befehlserklärung: Erkennt automatisch, ob Ihre Netcup-VM eth0 oder ens3 verwendet, und aktiviert dauerhaftes IPv4/IPv6-Kernel-Forwarding zusammen mit der BBR-Staukontrolle.
Detected Primary Netcup Interface: eth0
* Applying /etc/sysctl.d/99-wireguard-router.conf ...
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1 Schritt 2: wireguard-tools installieren und kryptografische Schlüsselhierarchie aufbauen
Seit Linux-Kernel 5.6 ist die WireGuard-Data-Plane (wireguard.ko) direkt in den Mainline-Kernel von Ubuntu und Debian integriert. Sie müssen lediglich die User-Space-Werkzeuge (wireguard-tools), qrencode (für das direkte Scannen von QR-Codes auf Smartphones) sowie unbound installieren.
Aus kryptografischer Sicht verzichtet WireGuard auf komplexe TLS-Zertifikatsketten und setzt stattdessen auf das Noise_IKpsk2-Protokollframework: statische und ephemere Curve25519-ECDH-Schlüsselvereinbarung, ChaCha20-Poly1305-AEAD-Paketverschlüsselung sowie BLAKE2s-Hashing. Indem wir jedes Peer-Schlüsselpaar mit einem symmetrischen 256-Bit-PresharedKey (wg genpsk) kombinieren, wird der Sitzungsschlüssel zusätzlich gegen „Harvest Now, Decrypt Later“-Angriffe zukünftiger Quantencomputer geschützt. Zudem ist ein WireGuard-Server für Internet-Scanner wie Shodan unsichtbar: Besitzt ein eingehendes UDP-Paket auf Port 51820 keinen gültigen kryptografischen MAC1-Tag, verwirft das Kernel-Modul das Paket im SoftIRQ-Kontext lautlos, ohne jemals ein Antwortpaket zu senden.
Legen Sie unter /etc/wireguard/{keys,clients} eine saubere Verzeichnisstruktur an, die durch chmod 0700 geschützt ist, sodass kein unprivilegierter lokaler Benutzer jemals private Schlüssel oder Client-Profile einsehen kann.
sudo apt update
sudo apt install -y wireguard wireguard-tools qrencode iptables unbound dns-root-data
# Abgesicherte Verzeichnisse für Schlüssel und Client-Profile anlegen
sudo mkdir -p /etc/wireguard/{keys,clients}
sudo chmod -R 0700 /etc/wireguard
# Privates und öffentliches Curve25519-Schlüsselpaar des Servers mit striktem umask 077 erzeugen
sudo sh -c 'umask 077; wg genkey | tee /etc/wireguard/keys/server_private.key | wg pubkey > /etc/wireguard/keys/server_public.key'
# Schlüsselberechtigungen überprüfen
sudo ls -la /etc/wireguard/keys/ Befehlserklärung: Installiert die WireGuard-User-Space-Tools, qrencode und unbound und erzeugt anschließend das Curve25519-Schlüsselpaar des Servers unter /etc/wireguard/keys/ mit strikten 0600-Berechtigungen (-rw-------).
drwx------ 2 root root 4096 Nov 4 11:15 .
-rw------- 1 root root 45 Nov 4 11:15 server_private.key
-rw------- 1 root root 45 Nov 4 11:15 server_public.key Schritt 3: Lokalen rekursiven Unbound-DNS-Resolver ohne DNS-Leaks konfigurieren
Viele oberflächliche WireGuard-Anleitungen tragen pauschal DNS = 1.1.1.1 oder 8.8.8.8 in die Client-Profile ein und übermitteln damit Ihre gesamte DNS-Abfragehistorie an externe Drittanbieter. Indem Sie auf Ihrem Netcup-Server einen eigenen rekursiven Unbound-Resolver einrichten, der direkt auf den Gateway-IPs des WireGuard-Tunnels (10.66.66.1 und fd42:66:66::1) lauscht, löst jedes verbundene Endgerät Domainnamen direkt über die autoritativen Root-Nameserver auf.
Unsere Unbound-Konfiguration erzwingt zwei zentrale Datenschutz- und Sicherheitsmechanismen: QNAME-Minimierung (qname-minimisation: yes) sorgt dafür, dass Unbound bei der Abfrage eines mehrstufigen Domainnamens gegenüber jedem Zwischen-Nameserver nur das unmittelbar nächste Label preisgibt (die .de-Registry erfährt also niemals die gesuchte Subdomain), während DNSSEC-Validierung (harden-dnssec-stripped: yes) über die in /usr/share/dns/root.key hinterlegten Root-Anker kryptografisch prüft, dass keine DNS-Antwort unterwegs manipuliert wurde.
Ein wichtiger Praxis-Kniff für systemd-basierte Server: Wenn unbound.service beim Booten wenige Millisekunden vor [email protected] startet, existiert die IP-Adresse 10.66.66.1 noch nicht auf dem Host. Durch die Direktive ip-freebind: yes nutzt Unbound die Linux-Socket-Option IP_FREEBIND, kann sich bereits vor dem Start von wg0 erfolgreich an die Tunnel-IPs binden und nimmt DNS-Anfragen entgegen, sobald der Tunnel steht.
server:
num-threads: 2
interface: 127.0.0.1
interface: 10.66.66.1
interface: fd42:66:66::1
port: 53
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
# Rekursive Abfragen strikt auf Localhost und das WireGuard-Subnetz beschränken
access-control: 0.0.0.0/0 refuse
access-control: ::0/0 refuse
access-control: 127.0.0.0/8 allow
access-control: 10.66.66.0/24 allow
access-control: fd42:66:66::/64 allow
# Datenschutz- & Sicherheitshärtung
hide-identity: yes
hide-version: yes
qname-minimisation: yes
harden-glue: yes
harden-dnssec-stripped: yes
use-caps-for-id: yes
prefetch: yes
# Speicher-Cache-Dimensionierung (Leichtgewichtige ~64 MB Gesamtauslastung)
msg-cache-size: 16m
rrset-cache-size: 32m
neg-cache-size: 4m
so-rcvbuf: 4m
so-sndbuf: 4m Befehlserklärung: Konfiguriert Unbound so, dass es auf den IPv4- (10.66.66.1) und IPv6-Gateway-Adressen (fd42:66:66::1) von WireGuard lauscht, während unautorisierte Abfragen aus dem öffentlichen Internet strikt abgewiesen werden (0.0.0.0/0 refuse).
SICHERHEITSHINWEIS: Da sich Unbound an 10.66.66.1 und fd42:66:66::1 bindet, setzen wir im nächsten Schritt ip-freebind: yes im server:-Block, damit Unbound beim Systemstart auch dann sauber startet, wenn das Interface wg0 erst wenige Millisekunden später initialisiert wird.
sudo sed -i '/port: 53/a \ ip-freebind: yes' /etc/unbound/unbound.conf.d/wg-vpn.conf
sudo unbound-checkconf
sudo systemctl enable --now unbound
dig @127.0.0.1 netcup.com +dnssec +short Befehlserklärung: Fügt ip-freebind: yes hinzu, prüft die Konfigurationssyntax mit unbound-checkconf und testet die lokale DNSSEC-Auflösung.
unbound-checkconf: no errors in /etc/unbound/unbound.conf
46.38.224.21 Schritt 4: /etc/wireguard/wg0.conf mit Dual-Stack-NAT & TCP MSS Clamping erstellen
Beim Design des IPv6-Routings für WireGuard auf Netcup müssen Sie eine Besonderheit der Netcup-KVM-Netzwerkarchitektur beachten: Netcup weist jedem VPS und Root Server zwar ein vollwertiges öffentliches /64-IPv6-Subnetz über das Link-Local-Gateway fe80::1 zu, delegiert dieses Präfix jedoch nicht per DHCPv6-PD, sondern erwartet Neighbor-Discovery-(NDP)-Antworten für diese Adressen auf Layer 2 an eth0. Würden Sie ein öffentliches /80-Teilnetz direkt an wg0 vergeben, verwirft der Upstream-Router von Netcup die Antwortpakete, sofern Sie nicht zusätzlich den NDP-Proxy-Daemon ndppd betreiben.
Die wartungsärmste und datenschutzfreundlichste Lösung für ein Road-Warrior-VPN ist die Zuweisung eines RFC-4193-Unique-Local-Address-(ULA)-Subnetzes (fd42:66:66::/64) auf wg0 in Kombination mit zustandsbehaftetem ip6tables-NAT66-Masquerading auf die primäre öffentliche IPv6-Adresse Ihres Netcup-Servers. Dadurch funktioniert das Dual-Stack-Routing auf jedem Netcup-Tarif sofort deterministisch, ohne dass dauerhafte Interface-Identifier Ihrer Mobilgeräte nach außen sichtbar werden.
Zusätzlich zu den MASQUERADE-Regeln für IPv4 (10.66.66.0/24) und ULA-IPv6 (fd42:66:66::/64) fügt unser PostUp-Hook die Regel --clamp-mss-to-pmtu in die FORWARD-Kette der mangle-Tabelle für IPv4 und IPv6 ein. Diese Regel passt die TCP-SYN-MSS-Option dynamisch auf 1380 Bytes (IPv4) bzw. 1360 Bytes (IPv6) an und verhindert zuverlässig hängende TLS-Handshakes.
PRIMARY_IF=$(ip -4 route show default | awk '{print $5; exit}')
SERVER_PRIVKEY=$(sudo cat /etc/wireguard/keys/server_private.key)
sudo tee /etc/wireguard/wg0.conf > /dev/null <<EOF
[Interface]
Address = 10.66.66.1/24, fd42:66:66::1/64
ListenPort = 51820
PrivateKey = ${SERVER_PRIVKEY}
MTU = 1420
SaveConfig = false
# Paketweiterleitung, TCP MSS Clamping und Dual-Stack NAT-Masquerading aktivieren
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT
PostUp = iptables -t mangle -A FORWARD -i wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
PostUp = iptables -t mangle -A FORWARD -o wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
PostUp = iptables -t nat -A POSTROUTING -s 10.66.66.0/24 -o ${PRIMARY_IF} -j MASQUERADE
PostUp = ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -A FORWARD -o wg0 -j ACCEPT
PostUp = ip6tables -t mangle -A FORWARD -i wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
PostUp = ip6tables -t mangle -A FORWARD -o wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
PostUp = ip6tables -t nat -A POSTROUTING -s fd42:66:66::/64 -o ${PRIMARY_IF} -j MASQUERADE
# Beim Stoppen von wg0 alle Firewall-Regeln sauber wieder entfernen
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT
PostDown = iptables -t mangle -D FORWARD -i wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
PostDown = iptables -t mangle -D FORWARD -o wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
PostDown = iptables -t nat -D POSTROUTING -s 10.66.66.0/24 -o ${PRIMARY_IF} -j MASQUERADE
PostDown = ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -D FORWARD -o wg0 -j ACCEPT
PostDown = ip6tables -t mangle -D FORWARD -i wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
PostDown = ip6tables -t mangle -D FORWARD -o wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
PostDown = ip6tables -t nat -D POSTROUTING -s fd42:66:66::/64 -o ${PRIMARY_IF} -j MASQUERADE
EOF
sudo chmod 0600 /etc/wireguard/wg0.conf
sudo ufw allow 51820/udp comment 'WireGuard VPN'
sudo systemctl enable --now wg-quick@wg0
sudo wg show wg0 Befehlserklärung: Erzeugt /etc/wireguard/wg0.conf unter Verwendung der erkannten primären Netzwerkkarte, konfiguriert Dual-Stack-NAT und MSS Clamping, gibt UDP 51820 in UFW frei und aktiviert wg-quick@wg0.
interface: wg0
public key: <SERVER_PUBLIC_KEY>
private key: (hidden)
listening port: 51820 SICHERHEITSHINWEIS: Belassen Sie SaveConfig = false in /etc/wireguard/wg0.conf. Wenn SaveConfig = true gesetzt ist, überschreibt wg-quick beim Stoppen die Datei /etc/wireguard/wg0.conf, löscht sämtliche Kommentare und beschädigt strukturierte Provisioning-Skripte.
Schritt 5: Automatisiertes Peer-Provisioning-Skript mit PresharedKey & QR-Code-Generator
Das manuelle Berechnen von IP-Offsets und Kopieren öffentlicher Schlüssel zwischen verschiedenen Dateien ist fehleranfällig. Erstellen Sie /usr/local/sbin/wg-add-peer, um das Hinzufügen von Laptops und Smartphones vollständig zu automatisieren. Für jeden Peer erzeugt das Skript sowohl ein eigenes Curve25519-Schlüsselpaar ALS AUCH einen symmetrischen 256-Bit-PresharedKey (wg genpsk), was den Noise_IKpsk2-Handshake zusätzlich gegen Post-Quanten-Angriffe absichert.
Entscheidend für den laufenden Betrieb: Das Skript aktiviert neue Peers über wg syncconf wg0 <(wg-quick strip wg0) anstatt über einen Neustart des Dienstes. wg-quick strip filtert zunächst die wg-quick-spezifischen Direktiven (Address, MTU, PostUp) heraus und übergibt das reine WireGuard-Format über eine /dev/fd/*-Pipe direkt an wg syncconf, sodass der Kernel den neuen Peer im laufenden Betrieb hinzufügt, ohne bestehende VPN-Sitzungen anderer Geräte zu unterbrechen.
sudo tee /usr/local/sbin/wg-add-peer > /dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
if [[ $# -lt 2 ]]; then
echo "Usage: sudo wg-add-peer <client-name> <octet-2-to-254>"
echo "Example: sudo wg-add-peer macbook-pro 10"
exit 1
fi
CLIENT_NAME="$1"
OCTET="$2"
SERVER_IP=$(ip -4 addr show "$(ip -4 route show default | awk '{print $5; exit}')" | awk '/inet / {split($2,a,"/"); print a[1]; exit}')
SERVER_PUBKEY=$(cat /etc/wireguard/keys/server_public.key)
CLIENT_DIR="/etc/wireguard/clients/${CLIENT_NAME}"
if [[ -d "${CLIENT_DIR}" ]]; then
echo "Error: Peer ${CLIENT_NAME} already exists in ${CLIENT_DIR}"
exit 1
fi
umask 077
mkdir -p "${CLIENT_DIR}"
wg genkey | tee "${CLIENT_DIR}/private.key" | wg pubkey > "${CLIENT_DIR}/public.key"
wg genpsk > "${CLIENT_DIR}/preshared.key"
CLIENT_PRIVKEY=$(cat "${CLIENT_DIR}/private.key")
CLIENT_PUBKEY=$(cat "${CLIENT_DIR}/public.key")
CLIENT_PSK=$(cat "${CLIENT_DIR}/preshared.key")
# 1. Neuen Peer-Block an /etc/wireguard/wg0.conf anhängen
cat >> /etc/wireguard/wg0.conf <<PEER_EOF
# Peer: ${CLIENT_NAME}
[Peer]
PublicKey = ${CLIENT_PUBKEY}
PresharedKey = ${CLIENT_PSK}
AllowedIPs = 10.66.66.${OCTET}/32, fd42:66:66::${OCTET}/128
PEER_EOF
# 2. wg0-Konfiguration unterbrechungsfrei im laufenden Kernel aktualisieren
wg syncconf wg0 <(wg-quick strip wg0)
# 3. Vollständige Client-.conf-Datei erzeugen
cat > "${CLIENT_DIR}/${CLIENT_NAME}.conf" <<CLIENT_EOF
[Interface]
PrivateKey = ${CLIENT_PRIVKEY}
Address = 10.66.66.${OCTET}/32, fd42:66:66::${OCTET}/128
DNS = 10.66.66.1, fd42:66:66::1
MTU = 1420
[Peer]
PublicKey = ${SERVER_PUBKEY}
PresharedKey = ${CLIENT_PSK}
Endpoint = ${SERVER_IP}:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25
CLIENT_EOF
echo "==> Peer-Profil erstellt: ${CLIENT_DIR}/${CLIENT_NAME}.conf"
echo "==> QR-Code unten mit der offiziellen WireGuard iOS/Android App scannen:"
qrencode -t ansiutf8 < "${CLIENT_DIR}/${CLIENT_NAME}.conf"
EOF
sudo chmod 0700 /usr/local/sbin/wg-add-peer
sudo /usr/local/sbin/wg-add-peer iphone-16 10 Befehlserklärung: Erstellt /usr/local/sbin/wg-add-peer, generiert Schlüssel + PresharedKey, lädt wg0 per wg syncconf im laufenden Betrieb neu (ohne bestehende VPN-Tunnel zu trennen), schreibt die Client-.conf und gibt einen ANSI-UTF-8-QR-Code direkt im Terminal aus.
wg syncconf Führen Sie niemals systemctl restart wg-quick@wg0 aus, nur um einen Peer hinzuzufügen oder zu widerrufen – ein Neustart des Interfaces trennt aktive SSH- oder VoIP-Sitzungen aller verbundenen Benutzer. Mit sudo wg syncconf wg0 <(sudo wg-quick strip wg0) werden Änderungen atomar im laufenden Kernel übernommen.
Häufige Fehlerbehebung
DIAGNOSE-GUIDE [SYMPTOM] WireGuard-Handshake ist erfolgreich (latest handshake: 5 seconds ago), aber bestimmte HTTPS-Websites laden endlos
Ursache: Path-MTU-Discovery-(PMTUD)-Blackhole. Entweder fehlt MTU = 1420 im Client-Profil, oder der Client nutzt eine PPPoE-DSL- bzw. Mobilfunkverbindung mit einer äußeren MTU unter 1500 Bytes.
Lösung: Prüfen Sie mit sudo iptables -t mangle -S FORWARD und sudo ip6tables -t mangle -S FORWARD, ob die TCPMSS --clamp-mss-to-pmtu-Regeln aktiv sind, und senken Sie die [Interface]-MTU des Clients testweise auf 1380 oder 1280.
[SYMPTOM] Client verbindet sich und kann 10.66.66.1 anpingen, erreicht aber keine externen IPv4/IPv6-Websites
Ursache: Entweder blockiert die Standard-Forward-Policy von UFW (DEFAULT_FORWARD_POLICY="DROP" in /etc/default/ufw) weitergeleitete Pakete, oder die MASQUERADE-Regel verweist auf den falschen Interface-Namen (eth0 statt ens3).
Lösung: Prüfen Sie den Interface-Namen mit ip -4 route show default und setzen Sie in /etc/default/ufw die Option DEFAULT_FORWARD_POLICY="ACCEPT" (oder fügen Sie die Regel mit -I FORWARD 1 ganz oben in die Kette ein).
[SYMPTOM] IPv6-Leak-Test zeigt trotz aktiver WireGuard-Verbindung die echte ISP-IPv6-Adresse des Clients
Ursache: Unter [Peer] enthält AllowedIPs im Client-Profil nur 0.0.0.0/0 ohne ::/0, sodass das Betriebssystem des Clients IPv6-Datenverkehr am VPN-Tunnel vorbei direkt ins Internet routet.
Lösung: Setzen Sie in jedem Full-Tunnel-Client-Profil zwingend AllowedIPs = 0.0.0.0/0, ::/0 und vergeben Sie Dual-Stack-Tunneladressen (10.66.66.X/32, fd42:66:66::X/128).
[SYMPTOM] Clients können über 10.66.66.1 keine Domains auflösen (DNS_PROBE_FINISHED_NO_INTERNET)
Ursache: UFW auf dem Netcup-Server blockiert eingehende UDP/TCP-Port-53-Anfragen, die über das Tunnel-Interface wg0 eintreffen.
Lösung: Erlauben Sie DNS-Abfragen auf dem wg0-Interface explizit mit sudo ufw allow in on wg0 to any port 53 und testen Sie die Auflösung vom Client aus mit dig @10.66.66.1 netcup.com.
Häufig gestellte Fragen (FAQ)
GEPRÜFTE ANTWORTENVerstößt der Betrieb eines eigenen WireGuard-VPNs gegen die Netcup-AGB oder die Fair-Use-Traffic-Regeln?
Der Betrieb eines privaten WireGuard-VPNs für Ihre eigenen Endgeräte, mobiles Arbeiten oder Ihr Unternehmensteam ist auf Netcup VPS und Root Servern zu 100 % erlaubt. Lediglich öffentliche Open-Proxys, kommerzielles VPN-Reselling oder anonyme Tor-Exit-Nodes, die Urheberrechts- oder Abuse-Meldungen verursachen, verstoßen gegen die Nutzungsbedingungen.
Wie konfiguriere ich ein Split-Tunnel-Profil, sodass nur interne Netcup-Docker-Subnetze über das VPN geroutet werden?
Ändern Sie in der .conf-Datei Ihres Clients die Zeile AllowedIPs = 0.0.0.0/0, ::/0 so ab, dass nur Ihr internes WireGuard-Subnetz sowie Ihre privaten Docker-Subnetze aufgelistet werden – z. B. AllowedIPs = 10.66.66.0/24, fd42:66:66::/64, 172.28.0.0/16 – und entfernen Sie die Zeile DNS = 10.66.66.1.
Warum nutzen wir Unique Local Addresses (fd42:66:66::/64) mit IPv6-NAT66 anstelle eines Teilnetzes aus dem öffentlichen /64-Block von Netcup?
Netcup routet Ihr öffentliches IPv6-/64-Subnetz direkt auf die MAC-/Link-Adresse Ihres Servers und nicht per DHCPv6-PD-Präfixdelegation. Das Abspalten eines /80-Subnetzblocks für wg0 würde daher einen zusätzlichen ndppd-Daemon (NDP Proxy) erfordern. Die Nutzung von ULA (fd42:66:66::/64) mit ip6tables MASQUERADE funktioniert dagegen auf jedem Netcup VPS und Root Server sofort deterministisch und verbirgt zudem die Interface-Identifier Ihrer Endgeräte nach außen.
Wie kann ich ein verlorenes Smartphone oder Notebook sofort sperren?
Löschen Sie den zugehörigen [Peer]-Block aus /etc/wireguard/wg0.conf, entfernen Sie das Verzeichnis /etc/wireguard/clients/<name> und führen Sie sudo wg syncconf wg0 <(sudo wg-quick strip wg0) (oder sudo wg set wg0 peer <PUBLIC_KEY> remove) aus. Der Kernel verwirft die kryptografische Sitzung des Geräts augenblicklich.
QUELLEN // GEPRÜFTE TECHNISCHE DOKUMENTATION
- [1] WireGuard Kryptografisches Protokoll & Whitepaper (Jason A. Donenfeld) (https://www.wireguard.com/papers/wireguard.pdf)
- [2] Unbound Rekursiver DNS-Server Offizielle Dokumentation (NLnet Labs) (https://unbound.docs.nlnetlabs.nl/en/latest/)
- [3] Linux-Kernel-Networking — IP-Sysctl & Forwarding-Referenz (https://docs.kernel.org/networking/ip-sysctl.html)