IPv6 auf dem VPS: einrichten, prüfen, verstehen

IPv6 ist auf den meisten VPS bereits vorhanden, aber halb eingerichtet: eine Adresse konfiguriert, Reverse-DNS leer, Dienste hören nur auf IPv4, Firewall-Regeln decken nur die alte Welt ab. Das fällt monatelang nicht auf, bis eine Gegenstelle IPv6 bevorzugt und plötzlich etwas nicht funktioniert.

Die Zahlen, die im Panel stehen#

Anbieter vergeben typischerweise eines von zwei Dingen:

• Ein /64, ein Netz mit 2⁶⁴ Adressen. Das ist die kleinste sinnvolle Einheit in IPv6 und für einen einzelnen Server völlig ausreichend.
• Ein /56, 256 solcher /64-Netze. Braucht man, sobald man selbst weiterverteilt: Container mit eigenen Adressen, Gäste auf einem Proxmox-Host, ein VPN-Netz.

Statisch konfigurieren#

Die Konfiguration hängt davon ab, was die Distribution nutzt. Beide Wege führen zum selben Ergebnis.

netplan (Ubuntu)#

# /etc/netplan/60-ipv6.yaml
network:
  version: 2
  ethernets:
    ens3:
      addresses:
        - 203.0.113.10/24
        - "2001:db8:1234:5678::10/64"
      routes:
        - to: default
          via: 203.0.113.1
        - to: "::/0"
          via: "2001:db8:1234:5678::1"
          on-link: true
      nameservers:
        addresses: [9.9.9.9, 149.112.112.112, "2620:fe::fe", "2620:fe::9"]

sudo chmod 600 /etc/netplan/60-ipv6.yaml
sudo netplan try            # rollt nach 120 s automatisch zurück
sudo netplan apply

netplan try ist der Grund, warum man IPv6 mit netplan angenehm einrichten kann: Wenn die Änderung die Verbindung kappt, ist sie nach zwei Minuten von selbst wieder weg.

systemd-networkd (Debian)#

# /etc/systemd/network/10-ens3.network
[Match]
Name=ens3

[Network]
Address=203.0.113.10/24
Gateway=203.0.113.1
Address=2001:db8:1234:5678::10/64
DNS=9.9.9.9
DNS=2620:fe::fe
IPv6AcceptRA=no

[Route]
Destination=::/0
Gateway=2001:db8:1234:5678::1
GatewayOnLink=yes

sudo systemctl enable --now systemd-networkd
sudo networkctl reload
networkctl status ens3

IPv6AcceptRA=no verhindert, dass Router-Advertisements aus dem Anbieternetz eine zweite, automatisch erzeugte Adresse hinzufügen, sonst hat die Maschine zwei IPv6-Adressen und benutzt für ausgehende Verbindungen nicht unbedingt die, die im Reverse-DNS steht.

Prüfen, ob es wirklich läuft#

# Ist die Adresse da, und ist sie "global"?
ip -6 addr show scope global

# Steht eine Default-Route?
ip -6 route show default

# Kommt man raus? (Beides testen — eine Adresse, ein Name)
ping6 -c3 2606:4700:4700::1111
ping6 -c3 ipv6.google.com

# Welchen Weg nimmt eine Verbindung nach draußen wirklich?
curl -6 -s https://ifconfig.co
curl -4 -s https://ifconfig.co

Der letzte Befehl ist der wichtigste: Er zeigt, mit welcher Adresse dein Server nach außen auftritt. Genau diese Adresse muss im Reverse-DNS und in deinen SPF-Einträgen stehen.

Dienste hören nicht automatisch mit#

Die häufigste Ursache für „IPv6 geht nicht“: Der Dienst lauscht gar nicht darauf.

sudo ss -tulpn | grep LISTEN

0.0.0.0:443 heißt: nur IPv4. [::]:443 heißt: IPv6 und auf Linux standardmäßig auch IPv4 mit, über IPv4-mapped Adressen.

nginx braucht eine zweite listen-Zeile:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    # ...
}

Caddy macht es von allein richtig, wenn keine Adresse angegeben ist.

Docker braucht IPv6 explizit, das ist ein eigener Themenkomplex, den man beim ersten Mal unterschätzt:

// /etc/docker/daemon.json
{
  "ipv6": true,
  "fixed-cidr-v6": "2001:db8:1234:5678:1::/80",
  "ip6tables": true
}

Reverse-DNS: der Schritt, den alle vergessen#

Für Webserver ist Reverse-DNS Kosmetik. Für alles, was Mail versendet, ist es Voraussetzung: Viele Empfänger lehnen Verbindungen ohne passenden PTR-Eintrag ab, und zwar bevor die eigentliche Prüfung überhaupt beginnt.

Der Eintrag wird beim Anbieter gesetzt, nicht in deiner DNS-Zone, die Rückwärtszone gehört dem, dem das Netz gehört. Im Kundenpanel heißt es meist „rDNS“ oder „Reverse DNS“.

Prüfen:

dig -x 2001:db8:1234:5678::10 +short
# muss den Hostnamen zurückgeben, der auch vorwärts auf diese Adresse zeigt

Vorwärts und rückwärts müssen zusammenpassen. mail.example.com → 2001:db8::10 → mail.example.com. Stimmt eine Richtung nicht, ist das für viele Mailserver ein Ablehnungsgrund. Mehr dazu in Eigener Mailserver.

Firewall: dieselbe Sorgfalt, andere Tabelle#

Klassische iptables-Regeln gelten nur für IPv4. Wer iptables benutzt, braucht ip6tables mit denselben Regeln, oder wechselt zu nftables mit einer inet-Tabelle, die beides in einem Regelwerk abdeckt. Ausführlich in Firewall auf dem VPS.

Ein Punkt speziell für IPv6: ICMPv6 darf nicht pauschal geblockt werden. Anders als bei IPv4 ist es Teil der Grundfunktion, Neighbor Discovery ersetzt ARP, und „Packet Too Big“ ist die einzige Möglichkeit, die Pfad-MTU zu erfahren. Wer ICMPv6 komplett verwirft, bekommt Verbindungen, die den Handshake schaffen und dann bei der ersten größeren Antwort hängen.

Wenn es hakt: die üblichen drei Ursachen#

Der dritte Fall ist der unangenehmste, weil er wie ein Anwendungsfehler aussieht. Ein Test mit großen Paketen und gesetztem Don't-Fragment-Bit entlarvt ihn zuverlässig.

Und wenn man es einfach lässt?#

Legitime Option, solange man es bewusst tut. Dann aber richtig: IPv6 im Kernel deaktivieren oder wenigstens keine Adresse konfigurieren, damit kein Dienst versehentlich darüber erreichbar ist, während die Firewall nur IPv4 kennt.

Der schlechteste Zustand ist der mittlere: eine konfigurierte Adresse, offene Dienste, keine Regeln und niemand, der hinschaut.