- Nach einem Stromausfall war auf ISP-Seite nur die IPv4-Verbindung ausgefallen, während IPv6 weiter funktionierte. Um den Zugriff auf reine IPv4-Websites wiederherzustellen, wurde ein Hetzner-VPS mit IPv4 und IPv6 zusammen mit einem WireGuard-Tunnel verwendet.
- Die Störung schien in einer CG-NAT-Schicht zu liegen, wo IPv4-Pakete nicht korrekt umgesetzt wurden und deshalb verworfen wurden. Dienste mit IPv6-Unterstützung wie Google oder Meta blieben weiter erreichbar.
- Mit einem WireGuard-Server auf dem VPS und der IPv6-Adresse des VPS als Endpoint auf dem Client lässt sich IPv4-Traffic über den VPS leiten und normales Web-Browsing wiederherstellen.
- Für das Arbeits-VPN und Docker war eine getrennte Behandlung nötig; sie wurden daher in einem auf vopono basierenden Netzwerk-Namespace mit Workarounds wie
unshare und einem /sys-Bind-Mount innerhalb dieses Namespace ausgeführt.
- Dass nur manche Websites luden, lag daran, dass die WireGuard-MTU zu groß war. Das Absenken auf die IPv6-Mindest-MTU von 1280 löste das Problem sofort.
Ausfall nur von IPv4 nach dem Stromausfall
- Nach dem Stromausfall wurde der Sicherungsschalter zwar wieder eingeschaltet, aber GitHub und mehrere Websites waren nicht erreichbar, während Google und Meta normal funktionierten.
- Prüfungen mit
ping -6 und traceroute auf dem lokalen Rechner und auf der Router-Diagnoseseite zeigten, dass das Problem nur beim Zugriff auf IPv4-Server lag.
- Der ISP teilte mit, dass eventuell ein Techniker kommen müsse und die Behebung erst nach dem Wochenende mehrere Tage dauern könnte; wegen Arbeitszugang und laufender Paper-Arbeit war Abwarten keine Option.
- Auf einem vorhandenen Hetzner-VPS gab es bereits statische IPv4- und IPv6-Adressen, und da die Hetzner-Website IPv6 unterstützt, konnte die Konfiguration über die Konsole vorgenommen werden.
NAT und CG-NAT als Ursache der IPv4-Abhängigkeit
- IPv4-Adressen sind 32 Bit lang, und abzüglich reservierter Blöcke gibt es nur etwa 3,7 Milliarden öffentliche IPv4-Adressen. Daher kann nicht jedes mit dem Internet verbundene Gerät direkt eine öffentliche Adresse erhalten.
- NAT sorgt dafür, dass mehrere Geräte sich eine öffentliche IP teilen können.
- Der Heimrouter übersetzt lokale IPs interner Geräte wie
192.168.1.xxx in seine eigene öffentliche IPv4-Adresse.
- Linux-conntrack speichert dabei ein Mapping aus ursprünglicher Quell-IP und Port sowie dem übersetzten Port.
- Wenn Antwortpakete an diesem Port eintreffen, setzt conntrack das Ziel wieder auf die ursprüngliche interne IP und den ursprünglichen Port zurück.
- Unter Linux lassen sich die gespeicherten Mappings mit
conntrack -L aus conntrack-tools anzeigen.
- NAT wirkt wie eine implizite Firewall: Dienste auf lokalen Geräten hinter dem Router sind von außen ohne explizites Port Forwarding nur schwer erreichbar.
- Wegen IPv4-Knappheit kann ein ISP intern noch einmal NAT anwenden; das nennt man Carrier Grade NAT (CG-NAT).
- So wie der Heimrouter mehrere lokale Geräte per NAT umsetzt, setzt der Router des ISP mehrere Heimrouter per NAT um.
- Je nach Anzahl verfügbarer IPv4-Adressen und Vergabepolitik des ISP kann das über mehrere Ebenen hinweg wiederholt werden, etwa regional gestaffelt.
- In diesem Ausfall schien irgendwo in einer CG-NAT-Schicht die NAT-Umsetzung von IPv4-Paketen fehlerhaft zu sein, sodass sie verworfen wurden und der gesamte IPv4-Traffic ausfiel.
- Für Umgehungsmethoden bei NAT Traversal lohnt sich ein Blick auf Tailscales How NAT Traversal Works.
Warum IPv6 weiter funktionierte
- IPv6-Adressen sind 128 Bit lang und bieten selbst unter Berücksichtigung reservierter Blöcke etwa 3.4E38 Adressen.
- Heimrouter erhalten häufig ein
/64-Subnetz, was 1.84E19 Adressen entspricht.
- Mit IPv6 muss der Heimrouter kein NAT verwenden; jedes Gerät kann direkt eine eigene Adresse im Internet haben.
- Probleme mit Port Forwarding werden dadurch geringer.
- Stattdessen brauchen Router oder einzelne Geräte geeignete Firewall-Regeln, um beliebige neue eingehende Verbindungen von außen zu blockieren.
- Da auf IPv6 kein CG-NAT angewendet wurde, war es von diesem Ausfall nicht betroffen.
- Es gibt jedoch weiterhin Webserver wie GitHub, die sich nicht per IPv6 erreichen lassen; mit nur einer IPv6-Verbindung konnte also nicht das gesamte Internet direkt genutzt werden.
Mit WireGuard einen IPv4-Tunnel über IPv6 bauen
- Die Lösung bestand darin, auf dem VPS WireGuard zu installieren und den Tunnel so einzurichten, dass der Client die IPv6-Adresse des VPS als Endpoint verwendet.
- Sobald der Tunnel stand, lief der IPv4-Traffic wieder normal über den VPS.
- Die Latenz steigt durch den Umweg über den VPS.
- Die Funktionsweise ähnelt einem selbst aufgebauten Dual-Stack Lite.
- Der Server war ein Hetzner-VPS, auf dem zuvor mit vps2arch Arch Linux installiert worden war; verwendet wurde das aktuelle Debian-Image von Hetzner als Basis.
- Die WireGuard-Konfiguration basierte auf dem Beispiel für einen spezifischen WireGuard-VPN-Server aus dem ArchWiki, erweitert um IPv6-Traffic.
- Die Server-Konfiguration umfasste unter anderem:
Address = 10.200.200.1/24, fd42:42:42::1/64, 2001:db8:abcd:1234::1/128- Weiterleitung für IPv4 mit
iptables und MASQUERADE
- NAT für IPv6-ULA mit
ip6tables und SNAT --to-source
- aktiviertes IPv4-/IPv6-Forwarding
- zwei Peer-Beispiele:
foo mit direkter globaler IPv6-Unicast-Adresse und bar mit NAT-umgesetzter IPv6-ULA
- Anders als bei Konfigurationen im
.ini-Stil kann man in wg-quick PostUp und PostDown mehrfach angeben; die Befehle werden dann nacheinander ausgeführt.
IPv6-NAT, SNAT und Client-Konfiguration
- IPv6 muss nicht zwingend per NAT umgesetzt werden. Wenn ein VPS wie bei Hetzner einen
/64-IPv6-Block hat, kann man Peers direkt eine Global Unicast Address (GUA) zuweisen.
- Für diesen direkten Adressierungsansatz ersetzt man die Unique Local Addresses (ULA) von Peer und Interface durch öffentliche IPv6-Adressen und entfernt die
ip6tables MASQUERADE-Regel.
- Jeder Peer ist dann mit seiner zugewiesenen IPv6-Adresse direkt aus dem Internet adressierbar.
- Wenn mehrere Geräte eigene Dienste weiterleiten sollen, ist dieser Ansatz geeignet.
- Die VPS-Firewall muss eingehenden Traffic dann korrekt behandeln.
- Wenn sicher ist, dass sich die IP-Adresse des VPS nicht ändert, kann statt
MASQUERADE auch SNAT verwendet werden.
MASQUERADE fragt die Interface-IP zur Laufzeit ab.SNAT gibt die Adresse direkt an und ist daher etwas effizienter.
- In der Client-Konfiguration muss die IPv6-Adresse des Servers in eckige Klammern gesetzt werden, etwa
Endpoint = [2001:db8:abcd:1234::1]:51820.
- Mit
AllowedIPs = 0.0.0.0/0, ::/0 wird der gesamte IPv4-/IPv6-Traffic durch den Tunnel geschickt.
- Nach dem Start auf beiden Seiten funktionierte normales Browsing wieder, und auch SSH-Zugriffe direkt auf den Server über die lokalen IPv4- und IPv6-Tunneladressen waren möglich.
- Auf Linux ließ sich der WireGuard-Client auch schnell auf dem Rechner der Ehefrau einrichten.
Arbeits-VPN per Netzwerk-Namespace isolieren
- Das Arbeits-VPN ließ sich nicht einfach direkt über der WireGuard-Verbindung aufbauen, weil es zu Konflikten kam.
- Mit vopono wurden das Arbeits-VPN und die benötigten Anwendungen in einem Netzwerk-Namespace ausgeführt.
- Entscheidend war, dass die MASQUERADE-Regel den Traffic nicht an ein physisches Netzwerk-Interface, sondern an das laufende WireGuard-Interface (
foo oder bar) weiterleitet.
- Der Traffic innerhalb des Namespace kennt die
nftables-Regeln des WireGuard auf dem Host nicht direkt, wird aber tatsächlich durch den WireGuard-Tunnel geroutet.
wg-quick bevorzugt nftables gegenüber iptables, wenn verfügbar, vermeidet dabei aber Konflikte mit den üblichen iptables-Regeln von Docker.- Ein Beispiel für den Start mit vopono:
$ vopono -v exec --create-netns-only --provider None --protocol None -i bar bash
$ sudo ip netns exec vo_none_none bash
$ (inside netns) ./vpn.sh
/etc/netns/vo_none_none/ wird von ip netns exec als /etc eingehängt, sodass dort ein eigenes resolv.conf nur für diesen Namespace abgelegt werden kann.- Wenn IPv4-DNS-Auflösung bevorzugt werden soll, lässt sich auf dieselbe Weise auch
gai.conf anpassen.
- Diese Einstellung wurde während des Debuggings von Problemen mit IPv6-Tunnel-Traffic verwendet.
- Das Beispiel basiert auf einer AskUbuntu-Antwort.
- Sobald nach dem Aufbau des Arbeits-VPN der interne DNS-Server in
/etc/netns/vo_none_none/resolv.conf eingetragen war, funktionierten auch Anwendungen, die später innerhalb dieses Namespace gestartet wurden, normal.
- Anwendungen wie Chrome lassen sich mit normalen Benutzerrechten innerhalb des Namespace starten.
$ vopono -v exec -i bar --provider None --protocol None google-chrome-stable
Docker im selben Namespace ausführen
- Docker funktioniert nicht, wenn es einfach wie eine normale Anwendung in einem Netzwerk-Namespace gestartet wird.
- Der per systemd aktivierte Docker-Socket wurde außerhalb des Namespace erzeugt.
- Dadurch ist die interne Konnektivität nicht gegeben.
- Auch das Stoppen des externen Docker und ein neuer Start von
dockerd samt Socket innerhalb des Namespace lösten das Problem nicht sofort.
ip netns exec erzeugt einen Mount-Namespace und mountet /sys neu.- Dadurch ist
/sys/fs/cgroup vom Host nicht sichtbar.
- In diesem Fall kann folgender Fehler auftreten:
Error: OCI runtime error: runc: runc create failed: no cgroup mount found in mountinfo
- Der Workaround besteht darin, mit
unshare einen Bind-Mount für /sys zu erzeugen und den von ip netns exec erzeugten internen /sys-Mount auszuhängen.
- Diese Methode basiert auf einem Unix-StackExchange-Beitrag.
- Danach ist
/sys innerhalb des Mount-Namespace ein Bind-Mount des Host-/sys.
- Beispielbefehle:
$ sudo systemctl stop docker && sudo systemctl stop docker.socket
$ sudo -E unshare -m sh -c 'mount --bind /sys /sys; exec ip netns exec vo_none_none sudo --user youruser --preserve-env bash'
$ sudo umount /sys
$ sudo dockerd --host=unix:///var/run/docker-netns.sock --data-root=/var/lib/docker-netns
$ DOCKER_OPTS="--dns=YOURDNSHERE" DOCKER_HOST=unix:///var/run/docker-netns.sock sudo --user youruser --preserve-env docker ...
- Wenn
dockerd und Docker-Befehle in derselben Sitzung laufen, teilen sie sich denselben Netzwerk- und Mount-Namespace.
- Die Docker-DNS-Konfiguration kann auch in
/etc/netns/vo_none_none/docker/daemon.json abgelegt werden.
- Für Aufgaben mit Hilfscontainern und Containern, die über Docker-Netzwerke verbunden sind, reichte dieser Ansatz aus; bei komplexeren Docker-Setups mit Bridges und Ähnlichem funktioniert er möglicherweise nicht unverändert.
Debugging des WireGuard-MTU-Problems
- Nach einem Neustart sah die WireGuard-Verbindung zwar intakt aus, aber nur einige Seiten luden, während Websites wie GitHub nicht öffneten.
ping, ping -6 und wg show sahen normal aus, was die Ursachenfindung erschwerte.- Mit Pings unterschiedlicher Größe zeigte sich, dass große Pakete fehlschlugen.
$ ping6 -s 1400 fd42:42:42::1
$ ping6 -s 1200 fd42:42:42::1
$ ping6 -s 800 fd42:42:42::1
- Bei Größe
1400 schlug der Test fehl, 1200 und 800 funktionierten. Damit war klar, dass die MTU-Einstellung die Ursache war.
- Wird die MTU des lokalen WireGuard-Interfaces abgesenkt, erzeugt der IP-Stack des Kernels keine größeren Pakete mehr.
- Dadurch werden auch die endgültigen UDP-Pakete inklusive WireGuard-Kapselungs-Overhead auf Links mit kleinerer MTU unterwegs nicht verworfen.
- Jeder Router entlang des Pfads hat seine eigene MTU; Pakete, die größer als die kleinste MTU sind, können verworfen werden.
- Beim Tunnel-Traffic verschärft sich das Problem durch den zusätzlichen Kapselungs-Overhead von WireGuard von etwa 32 Byte.
- Path-MTU-Discovery-Meldungen können unterwegs per ICMP von Zwischenroutern zugestellt werden, aber Firewalls verwerfen ICMP oft, sodass die automatische Anpassung scheitern kann.
- Die in der IPv6-Spezifikation festgelegte Mindest-MTU beträgt 1280, daher sollte dieser Wert für einen WireGuard-Tunnel über IPv6 immer funktionieren.
Verbleibende Betriebsoptionen nach der Wiederherstellung
- Die resultierende Konfiguration umfasste unter anderem:
- einen WireGuard-VPN-Server auf einem VPS mit IPv4 und IPv6
- Unterstützung sowohl für direktes IPv6 als auch für NAT-umgesetzten IPv6-Traffic
- Ausführung des Arbeits-VPN in einem Netzwerk-Namespace
- Betrieb von Docker im selben Netzwerk-Namespace per
unshare-Workaround
- Debugging des WireGuard-MTU-Problems
- Beim Remote-Arbeiten bleiben Probleme mit der Internetverbindung immer ein Risiko; in diesem Fall ließ sich die Zeit bis zur Wiederherstellung der ISP-Konfiguration mit Linux-Werkzeugen überbrücken.
- Hetzner-VPS unterstützt WireGuard-Tunnel und legale normale Nutzung, erlaubt aber kein Port-Scanning, Traffic-Spoofing oder Kryptowährungs-Mining.
- VPNs wie AirVPN, ProtonVPN oder AzireVPN mit Unterstützung für Port Forwarding können ebenfalls eine Alternative sein, um Ports für einen Homeserver unabhängig vom ISP weiterzuleiten.
- Mit einem OpenWRT-Router wären mehr Router-seitige Debugging-Möglichkeiten vorhanden, und eine solche Umgehungskonfiguration ließe sich direkt auf dem Router per WireGuard umsetzen, statt sie auf jedem einzelnen Gerät separat zu konfigurieren.
1 Kommentare
Meinungen auf Hacker News
Der Titel ist etwas missverständlich. Genauer gesagt geht es um Zugriff auf das IPv4-Internet über einen IPv6-Tunnel via VPS, üblicherweise auch 4in6 genannt.
Interessant ist es trotzdem. Aus Sicht eines ISP unterscheiden sich die Support-Fälle ziemlich deutlich, je nachdem, ob IPv4 oder IPv6 kaputt ist. Ein IPv4-Ausfall ist meist ein klarer „Down“-Zustand: Die Nutzer sind zwar sehr unzufrieden, aber das Problem ist einfach. IPv6-Ausfälle zeigen sich dagegen in seltsamen Formen: Teilausfälle, langsamer Start wegen Fallbacks oder Situationen, in denen das Gateway glaubt, IPv6 sei vorhanden.
Allerdings hatten Leute, bei denen im Router nur IPv4-DNS-Server eingetragen waren, einen Totalausfall. Wenn Microsoft ein paar unfähige Altlasten beseitigt hätte, wäre die größte Sorge vermutlich nur gewesen, sich den mDNS-Hostnamen des Routers zu merken, sich einzuloggen und zu prüfen, ob IPv4 wieder da ist.
Das ist ein seltsames Problem, und ich weiß nicht, ob es eine gute Lösung gibt, außer darauf zu hoffen, dass IPv4 irgendwann verschwindet. Happy Eyeballs sollte dieses Problem eigentlich lösen, aber oft tritt es weit oberhalb der Anwendungsschicht auf, und Anwendungen können nun einmal alles Mögliche tun, sodass es schwer ist, es mit allgemeinen Protokollen ohne leaky abstractions zu lösen. Persönlich fahre ich den Kompromiss, IPv6 im Netzwerk zu aktivieren und in allen Browsern IPv6-DNS zu deaktivieren, aber das ist ziemlich unbefriedigend.
Wenn man IPv6 ausprobieren möchte, der eigene ISP es aber nicht anbietet, stellt Hurricane Electric seit Jahren einen Tunnel-Dienst bereit.
https://tunnelbroker.net
https://ipv6.he.net
Es gibt auch Skripte, die auf dem System oder Router ein
tun-Device hochziehen und Traffic routen: https://fedoraproject.org/wiki/IPv6_tunnel_via_Hurricane_Ele..., https://brandonrozek.com/blog/obtaining-ipv6-address-hurrica..., https://wiki.dd-wrt.com/wiki/index.php/IPv6_setup_Hurricane_..., https://forum.mikrotik.com/t/auto-update-script-for-hurrican..., https://docs.rockylinux.org/guides/network/hurricane_electri...Trotzdem funktioniert es gut. Selbst wenn der Router keinen HE-Tunnel unterstützt, kann man dank RA allen Geräten im Netzwerk IPv6-Adressen geben. Jedes beliebige Gerät, das ein
/64advertised, wird zum IPv6-Router. Voraussetzung ist natürlich, dass der Router RA aus Sicherheitsgründen nicht filtert. Das ist sehr praktisch, wenn man Dienste im Heimnetz hosten will, ohne Port-Forwarding-Regeln anzufassen.Zu viele Websites haben Barrieren aufgebaut oder die Funktion ganz verweigert, sodass ich IPv6 in den meisten Teilen meines Netzwerks abschalten musste.
Konfiguriert wird das nur über OpenBSD-Netzwerkinterface-Dateien wie
/etc/hostname.gif0:tunnel,inet6 128 alias,!route -n add -inet6 default. Diese Verbindung nutze ich, um auf einen absichtlich ohne öffentliche IPv4-Adresse eingerichteten VPS-Cluster bei AWS zuzugreifen. Weil Leute wie Jeff Bezos IPv4-Adressraum aktiv monetarisieren, würde das sonst einen großen Teil der monatlichen Kosten ausmachen.Wenn man in einer wirklich reinen IPv6-Umgebung schnell IPv4-Konnektivität braucht, kann man öffentliche DNS64+NAT64-Gateways nutzen. Eine Liste gibt es unter https://nat64.net/public-providers
Für die normale Nutzung reicht es, nur den DNS-Server zu ändern. DNS64 synthetisiert für Ziele ohne AAAA-Record einen AAAA-DNS-Record, der auf die NAT64-Box zeigt:
$ dig +short @2a00:1098:2c::1 AAAA github.com→2a01:4f8:c2c:123f:64:5:141a:9cd7. NAT64 übernimmt dann für den wegen DNS64 zu ihm geleiteten Traffic die Protokollumsetzung und NAT:$ curl --resolve github.com:443:[2a01:4f8:c2c:123f:64:5:141a:9cd7] [https://github.com/](<https://github.com/>;)Diese mythischen reinen IPv6-Internetnutzer gibt es also tatsächlich :) Sauberes Network Engineering
Früher brauchte ich etwas Ähnliches für den häufiger vorkommenden umgekehrten Zweck, nämlich um über eine reine IPv4-Verbindung an IPv6-Dingen zu arbeiten. Wenn man einen Server vollständig kontrolliert, ist eine eingeschränktere, aber schnelle Lösung, mit
ssh -D 1080 -N myservereinen SOCKS5-Proxy zu erstellen und ihn im Browser einzutragen. Systemweit ließe sich das wohl auch konfigurieren, aber ich frage mich, ob dann die ursprüngliche ssh-Verbindung abreißt und alles zusammenbrichtIch bin in derselben Situation. Seit zwei Wochen höre ich nur, „das Ticket ist offen und ein Techniker wird sich bald darum kümmern“, was ziemlich frustrierend ist
Ich weiß nicht, ob die Priorität niedrig ist, weil IPv6 funktioniert und es daher nicht als vollständiger Ausfall gilt. In Deutschland gibt es ein Gesetz, das in solchen Fällen eine Entschädigung für Verbraucher garantiert, und ich werde demnächst prüfen, ob dieser Fall darunter fällt. Die Lösung aus diesem Blogpost hat das Problem, dass mehrere Endpunkte ganze IP-Bereiche von Rechenzentren blockieren oder mehrere CAPTCHAs verlangen; bei normalen VPN-Anbietern ist es ähnlich. Ich wollte das ganze Heimnetz reparieren, also musste es auf dem Router passieren, und mit einem nicht standardmäßigen Gerät wie einem Ubiquiti EdgeRouter war das Einrichten von Wireguard-Routing und NAT-Regeln vorteilhaft. Ich weiß nicht, wie ich das mit einer FritzBox gemacht hätte. Der Nachteil ist, dass die Routerleistung für viele Verbindungen nicht ausreicht, sodass ich auf IPSec umsteigen muss, das Hardware-Offloading unterstützt
Das größte Problem dürfte sein, herauszufinden, welche IPsec-Verschlüsselungskonfiguration die Gegenseite erwartet. Wireguard kann deutlich einfacher sein, aber dann kann das Problem mit der Hardwarebeschleunigung auftreten. Falls nötig, kann man die FritzBox-Konfigurationsdatei sichern, den Dump bearbeiten, den VPN-Endpunkt manuell setzen, die Prüfsumme neu berechnen und ihn wieder importieren. AVM hat viele Einstellungen, auf die Nutzer nicht direkt zugreifen können und die sich so anpassen lassen, hält den Zugang aber etwas umständlich, damit man den Router nicht versehentlich brickt
Das könnte eine Option sein, nach der man den ISP fragen kann
Eine Sache, die ich an Apples App-Store-Regeln mag, ist die Anforderung, dass alle Apps in reinen IPv6-Netzwerken funktionieren müssen. Diese Regel gibt es schon seit Jahren
Als Entwickler ist man beim ersten Kontakt damit etwas überrascht, aber als Nutzer bin ich froh, dass es sie gibt
Wenn mir dasselbe passieren würde, könnte ich mit
ssh -D 8080 user@hostnamesehr einfach einen ssh-Proxy erstellenSobald die Verbindung steht, stellt man im Browser
localhost:8080als SOCKS-Proxy einDamit diese Funktion funktioniert, muss
AllowTcpForwardinginsshd_configaktiviert seinBeim Abschalten von IPv4 gibt es einige Stellen, an denen man hängen bleibt: Die meisten alternativen Suchmaschinen scheinen keine IPv6-Konnektivität anzubieten, und GitHub hatte beim letzten Nachsehen überhaupt kein IPv6
Von Microsoft sollte man nichts Gutes erwarten, sondern eher das Schlimmste. Kürzlich haben sie in Issues sogar noscript/basic (x)html kaputtgemacht. Ich weiß auch nicht, ob man mit einem noscript/basic-(x)html-Browser und selbst gehosteter E-Mail noch ein Konto erstellen kann, etwa mit einem IP(v6)-Literal wie
mailbox@[ipv6:...]. Steam oder Spiele habe ich in letzter Zeit nicht geprüft, aber viele CDNs/Gameserver oder ein beträchtlicher Teil davon dürften noch IPv4-only sein. Auch bei Mailservern blockieren viele selbst gehostete Mailserver und verwenden häufig schlampige, unangemessene Blocklisten von dubiosen Firmen aus der Schweiz oder Andorra wie Spamhaus. Außerdem nutzen viele Netzwerkanwendungen die Vorteile von IPv6 nicht aus. Client-Server-Anwendungen wie das Web sollten zum Beispiel pro Sitzung eine zufällig erzeugte IPv6-Adresse verwenden, sofern der ISP kein zu kleines Präfix vergibt. Mobile IPv6-ISPs scheinen innerhalb des Präfixes beliebige IPv6-/128-Adressen zu vergeben, sollten aber ein stabiles Präfix bereitstellen, vielleicht etwa 96 Bit, damit Anwendungen auf dem Gerät ohne zentrale Online-Namensauflösung eine „feste“ IPv6-Adresse für direkte Sprach-/Videoanrufe wählen können. Es braucht auch neue OS-Dienste auf Benutzerebene zur Koordination von IPv6-Adressen zwischen Nutzeranwendungen. Allerdings sollte man sich vor der törichten Komplexität hüten, die manche Anbieter und Entwickler erzwingen werden, um Nutzer und App-Entwickler an sich zu binden.Dass ich das nur wegen GitHub tun musste, war wirklich schade. Wegen des Mailservers wäre es irgendwann ohnehin nötig geworden, aber als Grund, so früh NAT64 zu brauchen, war das ziemlich enttäuschend. Für mich ist das einer der vielen Nachteile, wenn Leute GitHub als Mittel zur Softwareverteilung verwenden.
Ich habe keine Ahnung, warum. Auf der Maschine lief nichts, was E-Mails hätte versenden können, und soweit ich weiß, blockiert Digital Ocean auch SMTP, sodass es dieser Maschine buchstäblich unmöglich war, E-Mails zu senden. Spamhaus half bei der Lösung überhaupt nicht, DO ebenso wenig.
https://gitlab.com/miyurusankalpa/IPv6-dns-server
In der Praxis wird man wahrscheinlich weiterhin in irgendeiner Form IPv4-Konnektivität haben; nur wird diese Verbindung immer häufiger über CGNAT laufen. GitHub macht besonders wütend. Sie haben ein paar Wochen getestet, alles schien gut zu funktionieren, und dann sind sie wieder auf IPv4-only zurückgegangen. Mailserver leben ohnehin in einer Welt von vor 10 bis 20 Jahren. Selbst SSL 3.0 oder TLS 1.0 auf Mailservern abzuschalten, ist schwer, ohne Zustellbarkeitsprobleme zu riskieren. Die Unterstützung und die Spamfilter von Microsoft Outlook scheinen IPv6-fähige Mailserver nicht einmal zu erkennen. Und das, obwohl sie den Headern nach intern offenbar schon lange IPv6 verwenden. Es wäre schön, wenn IPv6 stärker genutzt würde, aber die Angst, dass es bei einer kleinen Zahl von Kunden etwas schlechter funktionieren könnte, scheint jeden Versuch einzufrieren, die Technik tatsächlich einzusetzen. Der Grund für das merkwürdige IP-Verhalten bei Mobilfunkanbietern liegt wahrscheinlich darin, wie IP in Mobilfunknetzen funktioniert. Wenn man auf der Autobahn telefoniert oder in einem Hochgeschwindigkeitszug sitzt, führt das Telefon ständig Handover durch, und die IP-Adresse braucht ein gewisses Maß an Stabilität. Selbst beim Grenzübertritt und Wechsel in ein ausländisches Netz muss der gesamte Stack eine unterbrechungsfreie Verbindung aufrechterhalten. Innerhalb von Mobilfunknetzen gibt es spezielle Routing-Systeme, von denen einige IPv6-Funktionen hervorragend nutzen, die es aber schwierig machen, dem Telefon eine „normale“ statische globale Unicast-Adresse bereitzustellen. Man versucht, es so normal wie möglich aussehen zu lassen, aber diese Stabilität wie bei kabelgebundenem Heim-Internet zu erreichen, ist nicht einfach.
Bei der Arbeit betreiben wir einige IPv6-only-VPNs für den Zugriff auf interne Infrastruktur
Das bisher größte Problem ist, dass Windows- und macOS-Clients einen IPv6-DNS-Server benötigen. Andernfalls versuchen sie gar nicht erst,
v6onlyhost.vpn.example.comaufzulösen. Da sich die Clients in einem IPv6-fähigen Netz befinden können oder auch nicht, muss man im VPN einen DNS-Server betreiben und an die Clients pushen; wenn die WireGuard-App nach dem Trennen des VPNs aus irgendeinem Grund DNS nicht wieder zurücksetzt, kann das alle möglichen Probleme verursachen.Die Details weiß ich nicht mehr, aber als ich vor ein paar Jahren nachgeforscht habe, funktionierte macOS auf diese Weise gut, solange es nur eine IPv6-Adresse hatte. Man muss dem Host eine ULA-Adresse geben. Natürlich setzt das voraus, dass der Nutzer weiß, wie das geht. Je nach VPN-Anwendung kann man auch ein Skript einbauen, das beim Wechsel in ein IPv6-only-Netz eine ULA hinzufügt. Wenn man die falsche ULA allerdings dauerhaft stehen lässt, kann das Probleme verursachen, sobald der Nutzer in ein IPv6-fähiges Netz wechselt.
Obwohl so viel Zeit vergangen ist, sehe ich immer noch keinen überzeugenden Grund, mir tagelang die Haare zu raufen, um all meine Maschinen und mein Homelab auf IPv6 umzustellen.
Port-Forwarding und Firewall-Regeln sind für mich intuitiver, als wochenlang alles zu debuggen, die Firewall neu zu konfigurieren und das Netzwerk neu zu nummerieren. Was übersehe ich?
In meinem Netzwerk und bei meinem ISP Comcast reicht es, IPv6 auf dem Router zu aktivieren; dann erhält er vom ISP ein Präfix, kündigt es lokal an, und man fügt eine Firewall-Regel für die Ziele hinzu, die von außen erreichbar sein sollen – fertig.
Ich verwalte etwa 3.500 Geräte, 7 Gebäude, zwei 10-Gigabit-WANs und ein 4-Gigabit-WAN und nutze rund 26 öffentliche IPv4-Adressen plus NAT. Auch heute gibt es keinen starken Grund, IPv6 einzuführen. Eine Dual-Stack-Konfiguration fügt nur unnötigen Traffic und Komplexität hinzu, ohne nennenswerten Nutzen. Es ist immer noch schwierig, einen statischen IPv6-Adressblock zugeteilt zu bekommen; ich habe es zweimal beantragt und wurde abgelehnt. Nicht nur gibt es wenig Aufwärtspotenzial, auch den Block überhaupt zu bekommen, ist noch immer schwierig. Die Voraussetzungen unter https://www.arin.net/resources/guide/ipv6/first_request/ lauten etwa: vorhandene IPv4-Zuteilung, unmittelbar geplantes IPv6-Multihoming, 13 End-Sites innerhalb eines Jahres, Nutzung von 2.000 IPv6-Adressen innerhalb eines Jahres oder Nutzung von 200
/64-Subnetzen innerhalb eines Jahres.Erste Bewegungen gibt es bereits. AWS hat früher nur ungenutzte IPv4 Elastic IP Addresses berechnet, inzwischen fallen Gebühren unabhängig von der Nutzung an. Ehrlich gesagt reicht es, beim nächsten Upgrade des Gateways oder Routers vorbereitet zu sein; aktuell entgeht dir nichts. IPv4 und IPv6 können auch gleichzeitig genutzt werden. Wenn du es am Router aktivierst, funktionieren reine IPv4-Geräte weiterhin problemlos. Ein Punkt, auf den man achten sollte: Die automatische Erkennung bei IPv6 war eine Zeit lang ziemlich chaotisch. Es gab SLAAC, automatische IPv6-Adressierung und DHCPv6, und ursprünglich unterstützte die automatische Adressierung nicht einmal das Beziehen von DNS-Servern. Inzwischen konsolidiert sich das in Richtung SLAAC, aber ISPs werden noch sehr lange DHCPv6 verwenden.