d326031f38
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
120 lines
6.5 KiB
Markdown
120 lines
6.5 KiB
Markdown
# 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 <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
|
|
|
|
- [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.
|