Jeder VPS-Vergleich auf dieser Seite führt es auf: „ein einzelnes /128 IPv6 standardmäßig", „/64 IPv6", „kein IPv6 im Basistarif". Es liest sich wie ein Datenblattdetail. Für einen selbst gehosteten WireGuard-Server ist es keines - es entscheidet, ob Ihre Peers überhaupt IPv6 haben können.
WireGuard ist der Stack gleichgültig
Beginnen wir mit dem Einfachen. Die WireGuard-Dokumentation ist eindeutig: „Any combination of IPv4 and IPv6 can be used, for any of the fields." - jede Kombination aus IPv4 und IPv6 ist möglich, für jedes der Felder.
Der Endpunkt kann IPv4 sein, während der Tunnel IPv6 transportiert, oder umgekehrt. Es gibt keinen separaten IPv6-Modus und keinen zweiten Dienst. Ein Dual-Stack-Tunnel sind schlicht zwei Adressen auf derselben Schnittstelle.
Was /64 und /128 praktisch bedeuten
Hier beginnt das Datenblatt des Hosters zu zählen.
Ein /128 ist eine einzige Adresse. Es ist die eigene IPv6 Ihres Servers, mehr nicht. Sie können dem Server IPv6-Konnektivität geben, haben aber keine Adressen zu vergeben - Ihre Peers können nicht jeweils eine bekommen.
Ein /64 ist ein Block. Es ist die Standardzuteilung für ein Netzsegment und lässt Ihnen die Freiheit, jedem Peer daraus eine Adresse zuzuweisen.
Ein Hoster, der „IPv6 inklusive" mit einem einzelnen /128 bewirbt, sagt die Wahrheit und liefert dennoch nicht, was ein VPN-Server braucht. Das ist die Zeile, die man in einer Vergleichstabelle zweimal lesen sollte - auch in unserer.
AllowedIPs erledigt zwei verschiedene Aufgaben
Das ist der Teil, den man falsch versteht, und er ist unmissverständlich dokumentiert. Dasselbe Feld verhält sich je nach Richtung anders:
„beim Senden von Paketen verhält sich die Liste erlaubter IPs wie eine Art Routing-Tabelle"
„beim Empfangen von Paketen verhält sich die Liste erlaubter IPs wie eine Art Zugriffssteuerungsliste"
WireGuard nennt das Ganze eine Cryptokey Routing Table - „die einfache Zuordnung von öffentlichen Schlüsseln und erlaubten IPs".
Die Folge für IPv6 ist unmittelbar: Soll der IPv6-Verkehr eines Peers durch den Tunnel gehen, muss ::/0 in dessen AllowedIPs stehen. Nur 0.0.0.0/0 routet ausschließlich IPv4, und der IPv6-Verkehr des Peers verlässt das Gerät über die normale Verbindung - außerhalb des Tunnels, mit seiner echten Adresse.
Das ist ein Leck, und es ist kein WireGuard-Fehler. Es ist die Zugriffssteuerungsliste, die genau das tut, was ihr gesagt wurde.
Die Konfiguration in der Praxis
Geben Sie der Schnittstelle auf dem Server je eine IPv4- und eine IPv6-Adresse aus Ihrer Zuteilung. Führen Sie bei jedem Peer beide Stacks in AllowedIPs auf. Soll alles getunnelt werden, ist das 0.0.0.0/0, ::/0; für eine Aufteilung listen Sie die konkreten Präfixe je Stack.
Zweierlei ist zu beachten. Forwarding muss für beide Familien aktiviert sein, nicht nur für IPv4 - das sind getrennte sysctl-Einstellungen, und die eine zu aktivieren bewirkt für die andere nichts. Und Ihre Firewall-Regeln existieren ebenfalls doppelt: iptables und ip6tables sind verschiedene Tabellen, sodass ein Masquerade oder ein Kill Switch, der nur für IPv4 geschrieben ist, IPv6 ungeschützt lässt.
Prüfen statt annehmen
Kontrollieren Sie nach der Einrichtung vom Client aus, dass Ihre öffentliche IPv6 die des Servers ist und nicht Ihre eigene. Ein Tunnel, der IPv4 korrekt trägt und dabei IPv6 leckt, wirkt von innen völlig gesund: Der Handshake gelingt, Verkehr fließt, und in den Logs beschwert sich nichts.
Gibt Ihr Hoster nur ein /128, sind die ehrlichen Optionen: im Tunnel bei IPv4 bleiben und IPv6 auf den Peers blockieren, damit es nicht lecken kann - oder den Hoster wechseln. Ein halb konfigurierter Dual Stack ist schlechter als gar kein IPv6.
★ Nürnberger DSGVO-Rechenzentrum · ✓ Dedizierte IPv4 inklusive · 200+ Mbps garantiert
Hoste dein VPN auf deinem eigenen VPS → ContaboVoller Root-Zugriff · öffentliche IPv4 · wähle deine Region→
