# Intent: Traefik und IPv6-Testwebsite auf pinix ## Status und Ziel Geplant am 12.09.2026. Schritte 1 bis 5 sind am selben Tag umgesetzt -- Traefik und Testseite laufen auf pinix, Mangos DNAT zeigt dorthin, das Zertifikat kommt per ACME HTTP-01. Ergebnisse, Messwerte und offene Punkte: [Session-Uebergabe](../session-2026-09-12-pinix-traefik.md). Schritt 6 (Reboot- und Reconnect-Probe) steht aus, ebenso die Entscheidung ueber die Zertifikatskette. Die Abnahmekriterien sind bis auf den Reboot-Nachweis erfuellt. Eine statische Testwebsite läuft auf **pinix**, über **Traefik auf pinix** unter direkt erreichbar: Internet → Telekom `festip.telekom` → Nokia 6300 4G → Mango → pinix. Traefik und Backend sind deklarativ in NixOS eingerichtet, HTTPS wird automatisch erneuert. Der HTTP-Datenpfad benötigt weder blunix noch Cloudflare-Proxy. Der bestehende tnix-Test dient als nachgewiesener Ausgangspunkt und Rückfallmöglichkeit. ## Kontext und zuerst zu lesen - [Session-Übergabe](../session-2026-09-12-ipv6-plattform.md) - [Technischer Istzustand und Rückbau](../ipv6-test-tnix.md) - [Roadmap](../roadmap.md), aktueller IPv6-Nachtrag vor historischen Befunden - `hosts/tnix/localServices/ipv6-web-test.nix` - `scripts/configure-mango-ipv6-web.sh` - Bestehende pinix-Dienste und `hosts/blunix/localServices/traefik/` Der Nutzer bevorzugt langfristig lokal betriebene IPv6-only-Eingänge und akzeptiert Verbindungsabbrüche. Das verlangt keine pauschale Umstellung interner IPv4-Adressen. Domain-/DNS-/Overlay-Alternativen sind noch offen. ## Umfang 1. **Live-Bestand auf pinix und Mango prüfen.** Erreichbarkeit, LAN-Interface, IP-Adressen, Default-Routen, Resolver, Listener auf 80/443 und bestehende Reverse-Proxys ermitteln. Keine pinix-Adresse aus Vermutungen übernehmen. SSH-/Wiederherstellungsweg über LAN sichern, unabhängig von Headscale. tnix' iPhone-Rückhalt bleibt bis zu einem separat verifizierten Ersatz. 2. **Stabile LAN-Zieladresse für pinix einrichten.** Minimalen zum bisherigen NAT66-Aufbau passenden Weg verwenden. Öffentliche Präfixweitergabe ins LAN ist für diesen Meilenstein nicht erforderlich. IPv6-Rückweg explizit prüfen; das bisherige tnix-SNAT dient dessen iPhone-Default-Route und ist nicht automatisch auf pinix nötig. Bei SNAT den Verlust der Client-IP in Logs dokumentieren. Ausgehenden Zugang für ACME und benötigte Downloads prüfen; keine flächendeckende CLAT-/LAN-Migration daraus ableiten. 3. **Traefik und statischen Webserver auf pinix bereitstellen.** Kleine hostlokale Module, keine pauschale Kopie sämtlicher blunix-Routen. Traefik nimmt öffentlich IPv6 an, das Backend darf auf Loopback-IPv4 lauschen. Die Seite nennt eindeutig pinix als Host, damit ein alter tnix- oder VPS-Pfad beim Test auffällt. Kein öffentliches Traefik-Dashboard. Portkonflikte mit bestehenden Diensten gezielt lösen, ohne deren Erreichbarkeit stillschweigend zu verlieren. 4. **Eigenes Zertifikat für die Test-Subdomain.** Vorzugsweise ACME HTTP-01 analog zum bewiesenen tnix-Test, mit automatischer Erneuerung und HTTPS- Weiterleitung. Keine Wildcard-/BIND-Einführung als versteckte Voraussetzung. Kein Kopieren des produktiven Wildcard-Privatschlüssels von blunix. 5. **Nur den Testeingang umschalten.** Aktuelle öffentliche Mango-Adresse erneut prüfen; IPv6-Portweiterleitungen 80/443 und den bisherigen Link auf 8080 gezielt auf pinix ausrichten. Wiederverwendung von `ipv6-test.0ff.space` ist der Standard; damit wandert die öffentliche Testseite von tnix zu pinix. Lokaler tnix-Fallback kann vorerst bestehen. Bei unveränderter öffentlicher Adresse ist kein DNS-Update nötig. Andernfalls ausschließlich diesen AAAA-Eintrag anpassen, DNS-only. Keine Routerverwaltung freigeben. Änderungen persistent und reproduzierbar ablegen, bestehende UCI-Konfiguration vorher sichern. 6. **Stabilität und Rückbau prüfen/dokumentieren.** Aktuell bindet DNS an Mangos SLAAC-Adresse mit USB-MAC-Suffix. Eine wechselnde Interface-ID ist ein offenes Risiko: Persistenz gezielt prüfen oder eine feste öffentliche Adresse im zugewiesenen Präfix mit Außenmessungen absichern. Keine Garantie „neustartfest“ allein aus gespeicherten Configs ableiten. Reboot-/Reconnect-Proben erst mit funktionierendem lokalen Rückweg und abgestimmtem Unterbrechungszeitpunkt; verbleibende ungeprüfte Punkte nennen. ## Abnahmekriterien - Externer IPv6-Abruf von `https://ipv6-test.0ff.space/` liefert HTTP 200, gültiges Zertifikat und eindeutig die pinix-Seite. - HTTP 80 und der bisherige HTTP-8080-Link führen korrekt auf HTTPS. - Listener, Routerzähler und Backend-Konfiguration belegen den Pfad über Traefik auf pinix; keine Website-Abhängigkeit von tnix/blunix/Tailnet. - Dienste und Erneuerung sind persistent eingerichtet. Zertifikatsdateien und ACME-Zustand liegen geschützt außerhalb des Git-Repositories. - Build für pinix-Architektur und passende Flake-Evaluierung erfolgreich; Aktivierung und deren Host/Generation dokumentiert. Für ARM nur passende Builds ausführen, keine fremde Architektur lokal aktivieren. - Bestehende produktive Dienste, VPN und DNS funktionieren weiterhin. - Router-Reload übersteht der Testpfad; Reboot-/Reconnect-Nachweis oder noch ausstehender Test ist ausdrücklich dokumentiert. - Konkreter Rollback auf den bisherigen tnix-Test inklusive gespeicherter Routerregeln; produktive blunix-Dienste bleiben davon unabhängig. ## Explizit nicht Teil dieses Intents - Headscale, AdGuard, LLDAP/Dex, Prosody, GoToSocial oder andere produktive Anwendungen umziehen; blunix/VPS abschalten. - Cloudflare als autoritativen DNS ablösen, BIND/Unbound einführen, Nameserver beim Registrar wechseln, DNSSEC umstellen oder Wildcard-ACME bauen. - Domain aufgeben, bestehende XMPP-/ActivityPub-Identitäten ändern, Yggdrasil/`.v6.alt` oder einen neuen VPN-Ansatz einführen. - Vollständiger Wechsel von tnix weg vom iPhone-Hotspot oder pauschales Abschalten interner IPv4-Adressen. - Unverwandte Flake-Updates, Refactorings oder bestehende Änderungen verwerfen. ## Übergang zur nächsten Planung Nach erfolgreichem Test stehen Netzwerk und öffentlicher Proxy auf pinix. Dann separat internen DNS, LLDAP/Dex und Headscale planen. Eigener öffentlicher DNS und Wildcard-Zertifikate bleiben eine eigene Architekturentscheidung. Der Nutzerwunsch hier ist die Vorbereitung dieses konkreten Meilensteins; diese Datei allein startet keine Implementierung oder Veröffentlichung.