# IPv6-Webtest auf tnix mit HTTPS Stand: 12.09.2026, erfolgreicher HTTPS-Abruf um 08:47 UTC. URL: . HTTP auf 80 und 8080 leitet dorthin um. ## Aufbau - Cloudflare DNS-only AAAA, TTL 120: `ipv6-test.0ff.space` → `2a01:598:ec1e:ce00:94dd:42ff:fe9a:627f`. Record-ID: `d4365926627a225a9d38bba316474e61`. - Telekom `festip.telekom` → Nokia 6300 4G → USB-Tethering → Mango `usb0`. - Mango leitet TCP 80, 443 und 8080 dieser öffentlichen IPv6-Adresse auf dieselben Ports von `fdee:3c40:44f0:0:ca5b:76ff:fe96:e24` auf tnix weiter. - SNAT auf Mangos LAN-Adresse `fdee:3c40:44f0::1` sorgt dafür, dass tnix den Rückweg über Ethernet nimmt. Seine Default-Route bleibt am iPhone. Der Testserver sieht dadurch Mango als Client, nicht die externe Adresse. - nginx als systemweiter NixOS-Dienst, IPv6-Listener auf 80/443/8080. Firewallfreigabe für 80/443 nur auf Ethernet; TCP 8080 war bereits global freigegeben. Statische Seite aus dem Nix Store. - Die LAN-Zieladresse ist in NixOS statisch konfiguriert. Let's Encrypt validiert über HTTP-01 direkt durch den Mobilfunkpfad; ein systemd-Timer erneuert das Zertifikat automatisch. Keine DNS-Zugangsdaten erforderlich. Implementierung: `hosts/tnix/localServices/ipv6-web-test.nix`, zugehörige HTML-Datei und `scripts/configure-mango-ipv6-web.sh`. Das Router-Skript prüft auf ungespeicherte Änderungen, sichert die Firewall und prüft das neue Regelwerk vor dem Commit/Reload. `wan` ist jetzt explizit IPv4-only; die bestehenden IPv6-Kontrollregeln gehören zu `wan6`, ebenso die neuen Webweiterleitungen. LAN → wan6 und NAT66 für das lokale ULA-Netz sind gesetzt. Die temporäre User-Unit wurde gestoppt und die nft-Tabelle `tnix_web_test` entfernt. Historische Arbeitsdateien liegen noch unter `/tmp/ipv6-web-test.ERgok6/`; `dns.sh` enthält keine Secrets und nutzte den vorhandenen Cloudflare-Token direkt auf blunix. ## Verifikation und Ursache Vor Änderungen: Ping von tnix über den unabhängigen iPhone-Uplink zur öffentlichen Mango-Adresse: 3/3 Antworten. TCP 8080 erhöhte Mangos Freigabezähler um eins, bekam aber mangels Listener einen Reset. TCP 80 erhöhte `drop_from_wan` von 0 auf 4 und lief in einen Timeout. `usb0` ist sowohl `wan` als auch `wan6` zugeordnet. Die aktive `input`-Chain springt zuerst nach `input_wan`; deren Accept/Drop entscheidet bereits. Freigaben und Null-Zähler in der späteren `wan6`-Chain sagten daher nichts über fehlende Pakete vor dem Mango aus. Die frühere Telekom-Zuschreibung in der Roadmap und Support-Anfrage ist widerlegt. Nach Einrichtung: HTTP 200 samt Testseite über öffentliche IP und danach über den DNS-Namen. curl wählte den iPhone-Uplink; Mango zeigte zwei DNAT/SNAT-Verbindungen und Treffer auf der gezielten Forward-Freigabe. Kein Cloudflare-Proxy, Headscale oder blunix im HTTP-Datenpfad. HTTPS: HTTP/2 200 mit regulärer Zertifikatsprüfung; Aussteller Let's Encrypt YE1, gültig bis 11.12.2026. Alter 8080-Link: 301 → HTTPS → 200. nginx und Erneuerungstimer aktiviert, keine fehlgeschlagenen systemd-Units. NixOS-Build, `nix flake check path:. --no-build`, Dry-Aktivierung und echte Aktivierung erfolgreich. Kein VM-Boot-Test ausgeführt. Beim ersten Switch entfernte der alte dhcpcd-Prozess seine frühere SLAAC- Adresse unmittelbar nach deren statischer Einrichtung. Ein Neustart von `network-addresses-enp0s31f6` stellte sie wieder her; die zweite ACME- Anforderung gelang. Die neue dhcpcd-Konfiguration verwaltet auf Ethernet keine dynamischen IPv6-Adressen mehr. Der alte `nixos-rebuild`-Wrapper scheiterte an seiner NIX_PATH-Auswertung; aktiviert wurde das bereits gebaute System direkt über Systemprofil und `switch-to-configuration`. ## Grenzen und nächste Schritte Clients brauchen IPv6. Dienst und Routerregeln sind persistent eingerichtet, aber ein kompletter Reboot und USB-Reconnect wurden nicht getestet. Insbesondere die öffentliche SLAAC-Adresse hängt weiterhin vom USB-MAC- Suffix ab; falls dieser beim Reconnect wechselt, müssen DNS und die `src_dip`-Werte angepasst oder eine feste öffentliche Interface-ID eingerichtet werden. Die langfristige Präfixstabilität ist nicht getestet; ein altes Consumer-Präfix liegt noch zusätzlich auf `usb0`. Nächste Schritte: Reconnect-/Boot-Stabilität und öffentliche Interface-ID, anschließend Umzug auf pinix. Der vollständige Internetzugang auf tnix über den Mango ist seit dem 12.09.2026 erledigt und in [Mango als Uplink](ipv6-uplink-tnix-mango.md) beschrieben. Öffentliche Präfixweitergabe ins LAN statt NAT66 bleibt eine mögliche separate Architekturentscheidung. IPv4-Befund: Native IPv4-Verbindungen vom Mango scheitern, IPv6 funktioniert. Telekom-DNS `2a01:598:7ff:0:10:74:210:221` und Mangos lokaler DNS liefern für `ipv4only.arpa` synthetische Adressen aus `64:ff9b::/96`. Ein HTTPS-Abruf von `one.one.one.one`, explizit auf `[64:ff9b::101:101]:443` aufgelöst, lieferte HTTP 200. Telekom-NAT64 funktioniert also. tnix nutzt aber weiter Tailscale-DNS und die iPhone-Default-Route; DNS64/CLAT auf dem Client ist noch nicht eingerichtet. Die [Telekom-Dokumentation](https://geschaeftskunden.telekom.de/business/hilfe-und-service/geraete-konfigurationen/internet-festnetz/feste-ip-adresse-einrichten) bestätigt NAT64 für IPv4-Ziele beim festen Mobilfunk-IPv6-Zugang. ## Rückbau 1. NixOS-Modulimport entfernen und tnix neu bauen/aktivieren. 2. Auf Mango nur die UCI-Abschnitte `tnix_web_80`, `tnix_web_443`, `tnix_web_8080` und die drei `tnix_web_return_*` entfernen, Firewall prüfen, committen und neu laden. Die korrigierte Zonenzuordnung kann bleiben. 3. Nur den oben genannten Cloudflare-Testrecord entfernen. Vollständige Firewall-Sicherung vor der Migration auf Mango: `/root/ipv6-web-firewall-backup.nDOaOd/firewall` (auch `mfDOMd` enthält den ursprünglichen Stand). `BJoGgP` ist ein Zwischenstand vor der Korrektur der kopierten ICMP-Listen; für einen vollständigen Rollback den ursprünglichen Stand verwenden und etwaige spätere Änderungen vorher vergleichen. Die IPv6-Kontrollregeln wurden in die richtige Zone verschoben; keine pauschale Freigabe der Routerverwaltung für das Internet.