netcup-Server nur mit IPv6: Was ohne IPv4 klappt und was nicht

Seit Generation 12 bietet netcup VPS und Root-Server mit der Netzwerkoption „IPv6 Connectivity“ an: nur ein /64-IPv6-Netz, keine öffentliche IPv4-Adresse. Das klingt modern, doch wie weit kommt ein Server heute ohne IPv4? Wir haben es auf unserem Testserver ausprobiert und jeweils geprüft, welche typischen Quellen für Updates, Container und Code noch erreichbar sind. Diese Anleitung zeigt Schritt für Schritt, was ohne IPv4 klappt, was nicht, und wie Sie die Lücken mit DNS64 und NAT64 schließen.

Dies ist Teil 7 der Reihe „netcup Spezial“. Welche Netzwerkoption Sie bei der Bestellung wählen sollten, zeigt Teil 6.

Voraussetzungen

• netcup-VPS oder Root-Server, im Test ein VPS 500 G12.5 mit Ubuntu 24.04 und Docker
• SSH-Zugang als root und die VNC-Konsole im SCP als Rückweg, falls die Verbindung abbricht
• Etwa 30 Minuten

Schritt 1: So haben wir getestet

Einen zweiten Server mit „IPv6 Connectivity“ hatten wir nicht. Wir haben deshalb auf unserem Testserver mit IPv4 und IPv6 in zwei Durchgängen getestet. Im ersten haben wir neue ausgehende IPv4-Verbindungen per Firewall abgewiesen, im zweiten, strengeren die IPv4-Standardroute ganz entfernt. Ohne diese Route kann der Server keine Ziele über IPv4 mehr erreichen, so wie ein Server ohne IPv4-Adresse. Eingehende Verbindungen von Besuchern ohne IPv6 bildet das nicht ab. Dass ein Server ohne IPv4 für sie unerreichbar ist, ergibt sich schon aus der Option selbst.

Wollen Sie das vor einer Bestellung selbst ausprobieren, tun Sie das nur auf einem Testserver. Mit der Route fällt auch eine SSH-Verbindung über IPv4 weg. Wir haben deshalb alle Testbefehle in ein Skript geschrieben und es als Hintergrundjob auf dem Server gestartet. Ein Zeitgeber stellt die Route nach zehn Minuten in jedem Fall wieder her:

GW=$(ip -4 route show default | awk '{print $3}')
[ -n "$GW" ] && systemd-run --on-active=600 --unit=v4-zurueck /bin/sh -c "ip -4 route show default | grep -q . || ip -4 route add default via $GW dev eth0 onlink" && systemd-run --unit=v6test /root/v6test.sh

Das Skript /root/v6test.sh enthält Ihre Tests und am Anfang ip -4 route del default, am Ende ip -4 route add default via … mit dem gemerkten Gateway. Läuft der Zeitgeber danach noch, beenden Sie ihn mit systemctl stop v4-zurueck.timer. Können Sie den Server von Ihrem Arbeitsplatz aus per IPv6 erreichen, ist ssh -6 der einfachere Weg, dann bleibt die Sitzung bestehen. Als letzter Rückweg dient die VNC-Konsole im SCP, und auch ein Neustart bringt die fest eingetragene Route zurück.

Verifizieren: Im Skript zeigt ip -4 route show default nach dem Entfernen keine Zeile mehr, und curl -4 -s -m 5 https://ifconfig.co endet mit Exit-Code 7.

Schritt 2: DNS ohne IPv4

Zuerst die Namensauflösung. Das Image von netcup trägt die Resolver nicht am Interface ein, sondern global in /etc/systemd/resolved.conf:

grep "^DNS=" /etc/systemd/resolved.conf

DNS=46.38.252.230 46.38.225.230 2a03:4000:0:1::e1e6 2a03:4000:8000::fce6

Zwei der vier Resolver sind über IPv6 erreichbar. Ohne IPv4-Route lösten Namen deshalb weiter auf, sonst hätte etwa git keine Adresse für github.com gefunden. DNS selbst ist ohne IPv4 also kein Problem. Ob ein Server, der mit „IPv6 Connectivity“ bestellt wurde, dieselbe Datei bekommt, fanden wir in der netcup-Dokumentation nicht. Prüfen Sie das nach der Einrichtung mit demselben Befehl.

Verifizieren: resolvectl status zeigt unter Global mindestens einen Resolver mit IPv6-Adresse.

Schritt 3: Was ohne IPv4 funktionierte

Diese Quellen erreichte unser Server ohne IPv4. Die Spalte Durchgang zeigt, ob der Test bei abgewiesenen IPv4-Verbindungen (Sperre) oder ohne IPv4-Route (Route) lief:

Quelle	Test	Ergebnis	Durchgang
Ubuntu-Paketquellen	apt-get update	erfolgreich	Sperre und Route
Docker Hub	docker pull busybox:1.37	Image geladen	Sperre und Route
PyPI	curl https://pypi.org/simple/	HTTP 200	Sperre
npm	curl https://registry.npmjs.org/	HTTP 200	Sperre
Let's Encrypt	curl https://acme-v02.api.letsencrypt.org/directory	HTTP 200	Sperre
netcup.com	curl https://www.netcup.com/	HTTP 302	Sperre
raw.githubusercontent.com	curl	HTTP 301	Sperre

Beim Docker Hub haben wir ein Image gewählt, das noch nicht im Cache lag. Docker meldete Status: Downloaded newer image for busybox:1.37, die Daten kamen also wirklich über IPv6. Dass Ubuntu über IPv6 erreichbar ist, zeigt auch die Namensauflösung, etwa getent ahostsv6 archive.ubuntu.com mit einer echten IPv6-Adresse.

Verifizieren: apt-get update und ein docker pull eines neuen Images laufen ohne Fehler.

Schritt 4: Was ohne IPv4 scheiterte

GitHub war die große Lücke. Die Seite selbst, git clone und die Container Registry ghcr.io waren nicht erreichbar:

fatal: unable to access 'https://github.com/louislam/uptime-kuma.git/': Failed to connect to github.com port 443 after 1 ms: Couldn't connect to server

Error response from daemon: failed to resolve reference "ghcr.io/linuxserver/baseimage-alpine:3.20": failed to do request: Head "https://ghcr.io/v2/linuxserver/baseimage-alpine/manifests/3.20": dial tcp 20.250.119.73:443: connect: network is unreachable

Der Grund steht im DNS: Für github.com gab es keinen AAAA-Eintrag, also keine IPv6-Adresse.

resolvectl query --type=AAAA github.com

github.com: resolve call failed: Name 'github.com' does not have any RR of the requested type

Auch der Download-Host objects.githubusercontent.com antwortete im Durchgang mit Sperre nicht. Für einen Server mit Docker ist das ein echtes Problem: Viele Images liegen auf ghcr.io, und viele Installationsskripte laden Dateien von GitHub. Ohne IPv4 müssen Sie dafür eine Lösung haben.

Verifizieren: Prüfen Sie für jede Quelle Ihrer Dienste mit getent ahostsv6 name, ob es eine echte IPv6-Adresse gibt. Eine Ausgabe mit ::ffff: davor ist nur eine umgeschriebene IPv4-Adresse. Machen Sie diese Prüfung vor dem Einrichten von DNS64, danach sehen synthetische Adressen wie echte aus.

Schritt 5: DNS64 und NAT64 als Brücke

Die übliche Lösung heißt DNS64 mit NAT64. Ein DNS64-Resolver erzeugt für Namen ohne IPv6-Adresse eine synthetische IPv6-Adresse, in der die IPv4-Adresse steckt. Verbindungen dorthin landen bei einem NAT64-Gateway, das sie über IPv4 weiterleitet. Wir haben den öffentlichen Dienst von nat64.net genutzt, der beides kostenlos anbietet. Zuerst haben wir direkt bei ihm nachgefragt:

dig +short AAAA github.com @2a00:1098:2c::1

2a00:1098:2b::1:141a:9cd7
2a00:1098:2c::5:141a:9cd7
2a01:4f8:c2c:123f:64:5:141a:9cd7

Die letzten 32 Bit 141a:9cd7 sind hexadezimal die IPv4-Adresse 20.26.156.215, unter der github.com in diesem Moment erreichbar war. Über eine dieser Adressen lieferte github.com HTTP 200, getestet im ersten Durchgang mit Sperre. Bedenken Sie: Ein kostenloser Dienst eines Dritten hat keine Garantien. Mit der Einstellung aus Schritt 6 gehen alle DNS-Anfragen des Servers an diesen Dienst, und der Datenverkehr zu IPv4-Zielen läuft über dessen Gateway. Fällt der Dienst aus, hat der Server keine Namensauflösung mehr. Ausgehende E-Mails sollten nicht über ein fremdes NAT64-Gateway laufen, weil die Gegenstelle dessen IPv4-Adresse sieht. Für einen produktiven Server ist ein eigenes NAT64-Gateway oder schlicht die Option mit IPv4 die sicherere Wahl.

Verifizieren: dig +short AAAA github.com @2a00:1098:2c::1 liefert IPv6-Adressen.

Schritt 6: DNS64 dauerhaft eintragen

Unser erster Versuch, den Resolver nur zur Laufzeit umzustellen, scheiterte ohne IPv4-Route:

resolvectl dns eth0 2a00:1098:2c::1 2a01:4f8:c2c:123f::1

Danach lieferte resolvectl query github.com im Durchgang ohne Route weiter nur die IPv4-Adresse, und GitHub blieb unerreichbar. Im Durchgang mit Sperre klappte so zwar der Aufruf von github.com, docker pull von ghcr.io aber nicht. Zuverlässig war erst ein fester Eintrag in netplan. Wir haben dafür eine eigene Datei angelegt, sodass die Datei von netcup unverändert bleibt:

cat > /etc/netplan/60-dns64.yaml <<'EOF'
network:
  version: 2
  ethernets:
    eth0:
      nameservers:
        addresses:
          - "2a00:1098:2c::1"
          - "2a01:4f8:c2c:123f::1"
EOF
chmod 600 /etc/netplan/60-dns64.yaml
netplan generate && netplan apply

netplan generate prüft die Datei vorher auf Fehler. Halten Sie trotzdem die VNC-Konsole bereit, ein Fehler in der Netzwerkkonfiguration kann die Verbindung kosten.

Danach stand der DNS64-Resolver am Interface und ging den globalen Resolvern von netcup vor:

Link 2 (eth0): 2a00:1098:2c::1 2a01:4f8:c2c:123f::1
github.com: 2a00:1098:2b::1:141a:9cd7                       -- link: eth0

Ohne IPv4-Route klappten nun alle drei Tests, die vorher scheiterten: curl https://github.com lieferte HTTP 200, git clone lud das Repository, und der Docker-Daemon zog das Image von ghcr.io. Zum Rückgängigmachen löschen Sie die Datei und rufen erneut netplan apply auf. Im Test waren danach wieder die globalen Resolver von netcup aktiv, und github.com löste auf seine IPv4-Adresse auf.

Verifizieren: resolvectl query github.com zeigt Adressen aus dem Netz des DNS64-Dienstes.

Schritt 7: Eingehende Verbindungen nicht vergessen

DNS64 und NAT64 helfen nur dem Server selbst, wenn er Ziele im IPv4-Internet erreichen will. Besucher, deren Anschluss kein IPv6 hat, erreichen einen Server ohne IPv4-Adresse trotzdem nicht. Für eine öffentliche Website brauchen Sie dann einen Dienst davor, der über IPv4 erreichbar ist, etwa einen Reverse-Proxy auf einem zweiten Server mit IPv4 oder ein CDN, das Ihre Seite über IPv6 abholt. Für Mail gilt dasselbe: Viele Gegenstellen liefern weiterhin über IPv4 aus. Planen Sie das vor der Bestellung, siehe Teil 6.

Verifizieren: Ihre Dienste sind entweder nur intern gedacht oder haben einen Einstieg über IPv4.

Typische Fehler

Symptom	Ursache und Lösung
Couldn't connect to server bei github.com	GitHub hat keine IPv6-Adresse. DNS64 und NAT64 einrichten.
network is unreachable bei ghcr.io	Gleiche Ursache, ghcr.io gehört zu GitHub. DNS64 per netplan eintragen.
DNS64 per resolvectl wirkt nicht	Laufzeiteinstellung reichte im Test nicht. Resolver fest in netplan eintragen.
Adresse mit ::ffff: bei getent ahostsv6	Nur eine umgeschriebene IPv4-Adresse, keine echte IPv6-Erreichbarkeit.

Häufige Fragen

Bietet netcup selbst NAT64 an?

In der netcup-Dokumentation zur Netzwerkkonfiguration fanden wir dazu keinen Hinweis. Wir haben deshalb einen öffentlichen Dienst genutzt.

Reicht IPv6 für einen reinen Docker-Host?

Images vom Docker Hub ließen sich im Test ohne IPv4 laden. Sobald Images von ghcr.io oder Skripte von GitHub ins Spiel kommen, brauchen Sie DNS64 und NAT64 oder IPv4. Ob Ihre Container selbst ausgehend Ziele erreichen, hängt zusätzlich von deren Netzwerk ab, das zeigt Teil 8 dieser Reihe.

Kann ich später doch noch IPv4 dazubuchen?

Laut netcup nicht. Bei „IPv6 Connectivity“ lassen sich nur weitere IPv6-Netze hinzufügen.

Fazit

Ein Server ohne IPv4 kommt bei netcup erstaunlich weit: Ubuntu, Docker Hub, PyPI, npm und die ACME-Schnittstelle von Let's Encrypt waren im Test ohne Umwege erreichbar. Die große Ausnahme ist GitHub mit ghcr.io. Mit einem DNS64-Resolver fest in netplan und einem NAT64-Gateway lässt sich auch das lösen, für den produktiven Betrieb aber besser mit einem Gateway, das Sie selbst kontrollieren. Für öffentlich erreichbare Dienste bleibt IPv4 vorerst die einfachere Wahl.

Weiterführende Anleitungen und Quellen

• Teil 6: Netzwerkkonfiguration bei der Bestellung
• IPv6 auf dem netcup-Server einrichten und prüfen
• Docker Compose unter Linux: die Grundlage
• netcup: Netzwerkkonfiguration auswählen
• nat64.net: öffentlicher DNS64- und NAT64-Dienst
• netplan-Dokumentation