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/intent/pinix-ipv6-traefik-webserver.md
pijukka d326031f38 docs: Session-Uebergabe zu Traefik auf pinix, Intent-Status nachgezogen 
Format wie docs/session-2026-09-12-ipv6-plattform.md, an das diese Session
anschliesst. Haelt fest, was verifiziert ist, was ausdruecklich nicht
getestet wurde (Reboot-/Reconnect-Probe) und welche Entscheidungen offen
beim Nutzer liegen (Zertifikatskette, Wildcard via BIND).

Der Intent sagte noch "noch nicht ausgefuehrt"; Schritte 1 bis 5 sind
erledigt, Schritt 6 nicht.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019jNMZkpvA9QuNEPg9BA6oY
2026-09-12 15:28:26 +02:00

6.5 KiB
Raw Permalink Blame History

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.

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

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.