nixos-config/docs/ipv6-uplink-tnix-mango.md

tnix am Mango-Uplink: IPv6-only mit NAT64

Stand: 12.09.2026. Ersetzt den iPhone-Hotspot als Internetzugang für tnix.

Der Hotspot war nur Gerüst für die Einwärts-Erreichbarkeitstests (IPv6-Webtest auf tnix) und ist jetzt aus dem Pfad. tnix kann das Mango-WLAN idea oder das Ethernet-Kabel als Uplink nutzen.

Aufbau

tnix (wlan0/idea oder enp0s31f6) → Mango → Nokia 6300 4G → Telekom festip.telekom → Internet

Der Mango-Uplink ist IPv6-only. Ausgehend ins IPv4-Internet gibt es ausschließlich Telekoms NAT64 über 64:ff9b::/96, angesteuert durch die DNS64-Antworten des Mango-Resolvers.

Gemessener Istzustand

Alles am 12.09.2026 auf tnix bzw. dem Mango nachgemessen:

• Mango-WAN (usb0): IPv6 funktioniert (ping6 zu Cloudflare 3/3). IPv4 endet tot — das Nokia vergibt zwar ein LAN 192.168.0.0/24 und antwortet auf 192.168.0.1, aber ping -4 1.1.1.1 bleibt bei 100 % Verlust. Es gibt hinter dem Nokia keine IPv4-Route ins Internet.
• Mango-LAN verteilt per RA SLAAC aus dem ULA-Präfix fdee:3c40:44f0::/64, Default-Route und sich selbst als DNS (dhcp.lan.ra='server', ra_slaac='1', ra_default='1'). NAT66 (firewall.wan6.masq_src) übersetzt das ULA auf die öffentliche Telekom-Adresse. WLAN idea (ra0) liegt in derselben br-lan-Bridge wie das Ethernet, Clients beider Wege sind also gleichgestellt.
• DNS64 ist nachgewiesen: ipv4only.arpa und github.com liefern über 192.168.8.1 bzw. fdee:3c40:44f0::1 Adressen aus 64:ff9b::/96, echte Dual-Stack-Namen dagegen ihre normalen AAAA.
• Der komplette Weg funktioniert von einem LAN-Client aus: github.com (IPv4-only) antwortet mit HTTP 200 über 64:ff9b::8c52:7904, api.anthropic.com und Wikipedia nativ über IPv6.
• Gegenprobe auf dem iPad im WLAN idea: YouTube lädt. Apple-Geräte kommen mit NAT64/DNS64 out of the box zurecht.

Konfiguration auf tnix

In hosts/tnix/configuration.nix:

• wireless.networks.idea aktiv, iPhone auskommentiert.
• Keine IPv4-Default-Route. Der Mango bietet per DHCPv4 192.168.8.1 als Gateway an, das ist hinter dem Nokia ein schwarzes Loch: Pakete verschwinden still, Anwendungen laufen in Timeouts statt sauber auf IPv6 zurückzufallen. nooption routers für wlan0 wirft diese Route weg; die IPv6-Default-Route kommt weiterhin regulär per Router Advertisement.
• enp0s31f6 verwendet ebenfalls nooption routers: IPv4-Default-Route verwerfen, IPv6-Default-Route per RA übernehmen. Das frühere nogateway unterdrückte auch die IPv6-Default-Route und verhinderte Internet über das Kabel. Die ULA-Adressen bleiben davon unberührt.

Fehlerdiagnose am 12.09.2026 (abends)

Mit Mango am Ethernet und iPhone-Hotspot am WLAN hatte tnix ausschließlich eine IPv6-Default-Route über das iPhone. Der Mango selbst erreichte das IPv6-Internet und lieferte DNS64-Antworten. Zwei temporäre Zielrouten über enp0s31f6 und Mangos Link-Local-Gateway belegten den funktionierenden Kabel-Uplink: HTTPS zu Cloudflare (natives IPv6) und GitHub (NAT64) jeweils HTTP 200. Die Testrouten wurden anschließend entfernt. Deshalb ersetzt nooption routers das bisherige nogateway für Ethernet.

Validierung: nix flake check --no-build und tnix-Systembuild erfolgreich; dry-activate kündigte ausschließlich den Neustart von dhcpcd.service an. Anschließend erfolgreich aktiviert mit nixos-rebuild switch --no-reexec --store-path <gebauter Systempfad>. Danach erschien die Ethernet-Default-Route automatisch als proto ra; HTTPS zu GitHub über curl --interface enp0s31f6 -6 lieferte erneut HTTP 200. ChatGPT war beim vorherigen Kabeltest per HTTPS erreichbar (HTTP 403 auf den anonymen curl-Aufruf); ein authentifizierter Codex-Aufruf wurde nicht getestet.

Ein erster Versuch mit einer statisch deklarierten Default-Route (interfaces.wlan0.ipv6.routes) schlug fehl: network-addresses-wlan0 setzt die Route, bevor der Nachbar erreichbar ist, und scheitert mit „No route to host". Deshalb die RA-Route, nicht die statische.

DNS und Tailscale

services.tailscale läuft mit --accept-dns=false. MagicDNS würde AdGuard auf blunix befragen, das echte A-Records ohne DNS64-Synthese liefert — von hier aus nicht routbar. DNS64 stattdessen global in AdGuard zu aktivieren wäre kein Ersatz, weil Tailnet-Clients mit IPv4 dann synthetische AAAA für nativ erreichbare Ziele bekämen.

Ersatz für die verlorenen MagicDNS-Namen ist networking.hosts, gespeist aus config.tailnetIPs — ssh blunix und ssh pinix funktionieren weiterhin.

Tailscale selbst bleibt verbunden, aber nur noch über DERP-Relay: blunix hat keine öffentliche IPv6-Adresse und tnix kein IPv4, ein direkter Tunnel ist damit unmöglich. Beide erreichen den DERP jeweils in ihrer eigenen Familie. tailscale ping blunix antwortet über DERP(nue) in 56–75 ms. Randnotiz: derp4.tailscale.com (Frankfurt) ist über IPv6 nicht erreichbar — auch nicht über den iPhone-Uplink, also ein Problem auf Tailscale-Seite, nicht hier.

Grenzen

• Keine IPv4-Literale. Es läuft kein CLAT. Anwendungen, die Namen auflösen, sind über DNS64 versorgt; eine fest eingetragene IPv4-Adresse ist von tnix aus nicht erreichbar. Falls das stört, wäre clatd der nächste Schritt.
• Die öffentliche Testseite ist aus dem eigenen LAN heraus nicht abrufbar: Die Mango-DNAT-Regeln stehen auf reflection=0, Anfragen an die öffentliche Adresse landen darum auf der Weboberfläche des Routers (TLS-Fehler). Von außen ist sie unverändert erreichbar, nginx liefert eine vollständige Kette (Verify return code: 0 (ok)).
• Wird das Ethernet gezogen, fällt ipv6-test.0ff.space aus — das DNAT zeigt auf die statische Adresse von enp0s31f6. Der geplante Umzug des Eingangs auf pinix (Intent) löst das auf.
• Reboot- und USB-Reconnect-Festigkeit des Gesamtaufbaus sind weiterhin ungetestet, ebenso die Stabilität der öffentlichen Interface-ID.

Rückweg zum Hotspot

In hosts/tnix/configuration.nix die Zeile wireless.networks.iPhone wieder einkommentieren und idea auskommentieren, dann neu bauen. Für vollen IPv4-Betrieb zusätzlich nooption routers entfernen und tailscale set --accept-dns=true setzen.