Archived

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.

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

9.8 KiB

Raw Permalink Blame History

Session 12.09.2026: IPv6-Mobilfunkzugang und Plattformplanung

Übergabe für die nächste Session

Auftraggeber und Agent arbeiteten auf tnix. Ausgangspunkt war die vermeintliche Blockade des eingehenden IPv6-Verkehrs durch Telekom oder Nokia. Diese Diagnose wurde widerlegt. Ein öffentlicher HTTPS-Webserver läuft jetzt auf tnix: https://ipv6-test.0ff.space/.

Nächster angeforderter Schritt: Traefik und eine statische Testwebsite auf pinix über diesen direkten IPv6-Zugang bereitstellen. Der separate Intent beschreibt die Umsetzung. In dieser abschließenden Dokumentationsrunde wurde kein neuer Auftrag im Intent Board gestartet und kein weiterer Dienst umgezogen.

Technische Details, Adressen, Rückbau und Messungen stehen in IPv6-Webtest auf tnix. Die hier genannten Live-Zustände wurden während der Session geprüft, zuletzt für HTTPS um 08:47 UTC; vor weiterer Aktivierung erneut prüfen.

Gesicherte Ergebnisse

Aufbau: Telekom-SIM mit fester IPv6-/64-Option, APN festip.telekom, Nokia 6300 4G, USB-Tethering zum GL.iNet Mango GL-MT300N-V2, Ethernet zu tnix.
Öffentliche Mango-Adresse beim Test: 2a01:598:ec1e:ce00:94dd:42ff:fe9a:627f.
Zentrale Fehlerquelle: usb0 wurde zuerst von der Firewallzone wan behandelt, die noch IPv4 und IPv6 umfasste. Die nachgelagerte Zone wan6 und dortige Freigaben/Zähler wurden für diesen Verkehr nicht erreicht. Ihr Null-Zähler bewies deshalb keine vorgeschaltete Netzblockade.
Gegenprobe vor Änderungen: 3/3 Ping-Antworten; TCP 8080 traf Mangos Freigaberegel, aber ohne Listener; TCP 80 erhöhte drop_from_wan um vier.
Ein temporärer Node-Webserver auf tnix lieferte über diesen Weg HTTP 200. Der Nutzer bestätigte den Abruf auf dem Handy: „sehe hello von tnix“.
Danach nginx als NixOS-Dienst mit eigener statischer Seite, IPv6-Listenern, Let's-Encrypt-HTTP-01 und automatischer Erneuerung aktiviert.
HTTPS extern mit normaler Zertifikatsprüfung: HTTP/2 200. Zertifikat von Let's Encrypt YE1, gültig bis 11.12.2026. HTTP auf 80/8080 → HTTPS.
Cloudflare-AAAA-Eintrag für ipv6-test.0ff.space, DNS-only, TTL 120. Cloudflare dient hier nur als DNS, nicht als Proxy. blunix ist nicht im HTTP-Datenpfad. Der Nutzer hatte die DNS-Einrichtung ausdrücklich übertragen.
Mango-Regeln sind jetzt in UCI gespeichert; wan ist IPv4-only, die bisherigen IPv6-Kontrollregeln liegen in wan6. Gezielt TCP 80/443/8080 zu tnix, mit SNAT für den korrekten Rückweg.

Betrieb und noch offene technische Fragen

Überholt am 12.09.2026, später am Tag: tnix hängt nicht mehr am iPhone-Hotspot, sondern am Mango-WLAN idea. Der Absatz unten beschreibt den Stand davor. Details: Mango als Uplink.

tnix nutzt weiterhin den iPhone-Hotspot als Default-Internetzugang. Der gewünschte vollständige Wechsel zum Mango wurde noch nicht durchgeführt. Die Verbindung zum Mango läuft parallel über enp0s31f6 mit nogateway. Das Handy kann die öffentliche Testseite trotzdem unabhängig über Mobilfunk abrufen, während es tnix den Hotspot bereitstellt.

Native IPv4-Verbindungen vom Mango schlugen fehl. Telekom-DNS und Mangos lokaler DNS liefern aber DNS64-Antworten aus 64:ff9b::/96. HTTPS zu one.one.one.one, explizit über [64:ff9b::101:101], funktionierte. NAT64 ist nachgewiesen; vollständiger DNS64/CLAT-Clientbetrieb noch nicht. tnix verwendet bisher Tailscale-DNS. NAT64 macht die Dienste nicht für eingehende IPv4-only-Besucher erreichbar.

Beim ersten NixOS-Switch entfernte der alte dhcpcd-Prozess seine frühere SLAAC-Adresse nach deren statischer Einrichtung. Dadurch scheiterte der erste ACME-Auftrag. Neustart von network-addresses-enp0s31f6 behob dies; die erneute Ausstellung gelang. Tailscale war nicht die Warteursache.

Build, nix flake check path:. --no-build, Dry-Aktivierung und Aktivierung erfolgreich; nginx und Erneuerungstimer aktiviert, zuletzt keine fehlerhaften systemd-Units. Kein vollständiger Reboot-/USB-Reconnect-/VM-Boot-Test. Aktivierte Generation: /nix/store/dy6vnjz0zqfpgqkgv53ih295zkidfrg3-nixos-system-tnix-26.11.20260902.3ed67ec. Der vorhandene nixos-rebuild --store-path-Wrapper scheiterte an NIX_PATH; verwendet wurden das gebaute System, nix-env für das Systemprofil und switch-to-configuration switch.

Die öffentliche SLAAC-Interface-ID hängt noch vom USB-MAC-Suffix ab. Präfix- und Suffixstabilität beim Reconnect sind unbewiesen. Statische öffentliche Interface-ID oder DNS-Nachführung sind noch zu entscheiden. Ein altes Consumer-Präfix liegt zusätzlich auf Mango usb0.

Nutzerpräferenzen und Architekturgespräch

Der Nutzer bevorzugt ausdrücklich IPv6-only als öffentlichen Zugang, um externe Abhängigkeiten zu reduzieren. Er bevorzugt konsequent lokalen Betrieb und nimmt Verbindungsabbrüche in Kauf. Langfristiges Ziel ist die Plattform auf pinix, einschließlich Traefik, Headscale, LLDAP/Dex, Prosody und GoToSocial. Das ist die Zielrichtung, keine bereits erfolgte Migration.

Gemeinsam geklärt:

Öffentlicher IPv6-Zugang erfordert nicht das Abschalten sämtlicher interner IPv4-Verbindungen. Traefik kann IPv6 entgegennehmen und lokal über IPv4 mit Anwendungen sprechen; auch VPN-Adressen können zunächst bleiben.
NAT66 im Mango-Test übersetzt IPv6-Adressen untereinander. Telekom-NAT64 ermöglicht ausgehenden Verkehr zu IPv4-Zielen. CLAT kann für reine IPv4- Anwendungen nötig sein. Diese Mechanismen sind nicht austauschbar.
IPv4-only-Besucher erreichen einen IPv6-only-Eingang nicht. DNS/BIND/ Namecheap können keine fehlende IPv4-Verbindung herstellen. VPS/Proxy oder ein anderer Anschluss wären mögliche zusätzliche Eingänge, wurden aber nicht als Ziel gewählt. Cloudflare-Proxy wurde nur diskutiert.
Prosody unterstützt IPv6. Grenzen betreffen auch fremde XMPP-Server, ActivityPub-Föderation, Webhooks und die Erreichbarkeit von Headscale. Ein Kontakt mit IPv4-Handy kann über seinen IPv6-fähigen XMPP-Anbieter kommunizieren. Eine IPv6-Webseite allein beweist keine vollständige Föderation.
Headscale hängt heute an Traefik, Dex/LLDAP und AdGuard auf blunix. Für den späteren Gesamtumzug wurde Netzwerk → Traefik → interner DNS → LLDAP/Dex → Headscale als sinnvolle Reihenfolge vorgeschlagen.

DNS, Zertifikate und radikalere Varianten: noch nicht entschieden

BIND könnte autoritativen DNS und DNS-01-Prüfungen via RFC2136/TSIG übernehmen. Das Wildcard-Zertifikat stellt weiterhin eine CA wie Let's Encrypt aus. Als Zwischenstufe wurde die Delegation von _acme-challenge.0ff.space diskutiert. Interner AdGuard-DNS, öffentlicher autoritativer DNS und Zertifikatsausstellung sind getrennte Aufgaben.

Cloudflare-Abschied ist ein Interesse, noch keine umgesetzte oder abschließend gewählte DNS-Architektur. Nur lokal über IPv6 erreichbarer autoritativer DNS schließt auch Resolver ohne IPv6 aus; ein IPv6-fähiger Besucher allein genügt dann nicht. Externe sekundäre Nameserver wären ein möglicher Kompromiss, wurden aber nicht beauftragt.

Für 0ff.space im normalen öffentlichen DNS bleibt ein Registrar nötig; Namecheap ist austauschbar, die Registrierungsfunktion nicht lokal ersetzbar. Diskutierte Alternativen ohne registrierte Domain:

Direkte IPv6-URLs; öffentliche IP-Zertifikate sind bei Let's Encrypt verfügbar, aber kurzlebig und weiter CA-abhängig. Die Identität hängt dann stärker an der Anschlussadresse.
Eigenes WireGuard-Netz mit lokalen Namen/DNS und eigener CA. Teilnehmende Geräte benötigen Einrichtung; Headscale wäre dafür nicht zwingend nötig.
Experimentelles Yggdrasil mit schlüsselabgeleiteten, innerhalb des Netzes ortsunabhängigen IPv6-Adressen. Verbindungen/Peers bleiben erforderlich; das ist keine garantierte Erreichbarkeit ohne physische Verbindung.
Prosody-Alpha-Modul mod_s2s_v6mesh für .v6.alt ohne öffentliche DNS- Infrastruktur. Beide Server benötigen das Modul; Clients brauchen manuelle Serveradressen. Das TLS-Vertrauensmodell muss gesondert abgesichert werden.

Keine dieser Alternativen wurde zur Implementierung ausgewählt. Die Frage „eigener eingerichteter Personenkreis oder Fremde ohne Einrichtung?“ blieb offen. Bestehende GoToSocial-/XMPP-Identitäten nicht vorschnell ändern oder die Domain auslaufen lassen; Identitätswechsel ist mehr als ein Ausfall.

Dateien und Arbeitsstand

Implementierung: hosts/tnix/localServices/ipv6-web-test.nix, ipv6-web-test.html, Import in default.nix, scripts/configure-mango-ipv6-web.sh. Dokumentation: docs/roadmap.md, docs/ipv6-test-tnix.md, überholter Support-Entwurf ausdrücklich markiert. Router-Backups und Rückbau stehen im technischen Bericht.

Die Session-Änderungen sind noch nicht committed. Änderungen an flake.nix und flake.lock lagen bereits vor Beginn vor (separater Codex- Input/Overlay); nicht dieser Arbeit zuschreiben oder zurücksetzen. Der Systembuild verwendete den vorhandenen Worktree einschließlich dieser Änderungen. memory/ wurde nicht geändert.

9.8 KiB Raw Permalink Blame History