6cab1162f2
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
110 lines
6 KiB
Markdown
110 lines
6 KiB
Markdown
# 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](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.
|