# 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](ipv6-test-tnix.md)) 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 `. 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](intent/pinix-ipv6-traefik-webserver.md)) 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.