lukas/nixos-config
Archived
1
0
Fork 1
Code Issues Pull requests Releases Wiki Activity
This repository has been archived on 2026-09-17. You can view files and clone it, but you cannot make any changes to its state, such as pushing and creating new issues, pull requests or comments.
nixos-config/docs/ipv6-test-tnix.md
pijukka 6cab1162f2 host(tnix): serve ipv6-test.0ff.space over the mobile IPv6 uplink 
Widerlegt die bisherige Annahme, Telekom oder das Nokia blockierten
eingehendes IPv6. Ursache war die Firewallzone auf dem Mango: usb0 wurde
von `wan` behandelt, das noch IPv4 und IPv6 umfasste, sodass die Regeln in
`wan6` gar nicht erreicht wurden. Deren Null-Zähler bewiesen deshalb
nichts.

nginx auf tnix mit IPv6-Listenern und ACME HTTP-01; der Mango leitet
TCP 80/443/8080 der öffentlichen Adresse auf die statische ULA-Adresse
von enp0s31f6 weiter. Kein Cloudflare-Proxy, kein blunix im Datenpfad.

scripts/configure-mango-ipv6-web.sh legt die UCI-Regeln persistent an,
mit Backup und `fw4 check` vor dem Commit.

Arbeit der Vormittagssitzung vom 12.09.2026, hier erstmals committet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ML1tzf3RKWwetud5S4TRAn
2026-09-12 13:24:08 +02:00

6 KiB
Raw Permalink Blame History

IPv6-Webtest auf tnix mit HTTPS

Stand: 12.09.2026, erfolgreicher HTTPS-Abruf um 08:47 UTC.

URL: https://ipv6-test.0ff.space/. 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 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 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.