bf-infra/docs/tp16.3-paragraph5-session-handoff-prompt.md

Übergabeprompt — TP16.3 §5: CNAME-Flip auf bf-public

Zum Einfügen in eine frische Session. Erstellt 2026-08-31, direkt nach §2/§3. Alles unterhalb der Linie ist der Prompt.

---

TP16.3 / TP31 Schritt 5 — §5 CNAME-Flip (Repo ~/dev/bf-infra).

Aufgabe: §5 des Runbooks docs/tp16.3-bf-public-ap-connector-runbook.md ausführen — die vier öffentlichen Namen von den Alttunneln auf bf-public umhängen. §6 (Abbau) gehört NICHT dazu, frühestens 7 Tage nach dem Flip.

PFLICHTLEKTÜRE ZUERST, in dieser Reihenfolge

1. docs/handoff-20260831-tp16.3-paragraph2-3-durch.md — Ergebnis und Funde der Vorsession
2. docs/tp16.3-bf-public-ap-connector-runbook.md §5 (und §7 Rollback)
3. docs/teilprojekte.md (Quick-Index + Ist-Stand + TP16.3-Abschnitt)

AUSGANGSLAGE — nicht nochmal machen

• bf-public ist healthy mit 12 Connectoren (ap1/ap2/ap3, je ein cloudflared 2026.6.1, Container running, start-on-boot=yes). Tunnel-ID 48d3b0b6-7233-4781-a76a-1de4a5e957ce.
• Ingress steht auf https://10.40.20.40:443 mit originServerName je Regel (Blocker A behoben).
• Firewall-Freigabe vlan99 → vlan20:443 auf crs326-core liegt und ist verifiziert (Blocker B).
• Caddy antwortet mit korrektem SNI 200, ohne SNI 000 — gemessen, das ist gesundes Verhalten.
• Rollback-Material: docs/cf-backup/ — Ingress-Configs, CNAMEs inklusive Record-IDs, und für drei Tunnel zusätzlich der ältere Stand als *-vor-hostname-schnitt.json.

🔴 ZUERST ENTSCHEIDEN, BEVOR EIN NAME GEFLIPPT WIRD

Compliance steht auf 128/135. Sechs extra-Drifts, zwei je AP: ip-address (172.17.0.1/24 interface=veth-cf) und ip-firewall-nat (masquerade, Kommentar TP31: cloudflared egress). Sie sind inhaltlich richtig — ohne sie läuft kein Container —, aber sie stehen nicht im Soll, weil Runbook §3.4 Direkt-Writes vorschreibt für Features, die unter Golden-Config-Kontrolle stehen.

Der saubere Weg ist, sie ins Soll zu heben (AP-Template bzw. ConfigContext ap-common). 🔑 Bewusst KEINE Transaktion: gc-transaktion.py ist für befristete Versuche da (so wie TP25-fund-e-ft-over-ds). Das veth/masquerade soll dauerhaft gelten — Dauerzustand gehört ins Template, nicht in eine Transaktion mit Ablaufdatum. 🔴 Kein Re-Baseline (macht die Drift-Erkennung wertlos), kein Rückbau (killt die Tunnel). ⚠️ Dabei mitentscheiden, ob /interface veth überhaupt erfasst sein soll — dafür existiert heute keine ComplianceRule, deshalb erzeugt veth auch keine Drift.

Mit ungeklärter Drift in den Produktivpfad zu gehen ist die eine Sache, die diese Session nicht tun sollte. Christoph entscheidet, nicht die Session.

🔴 Die siebte Drift ist KEINE Drift im Sinne eines Versehens: crs326-core / wifi-security (ft-over-ds=no) ist TP25 Fund E, Hebel 1 — am 2026-08-31 um 08:09 bewusst gesetzt und als offene Transaktion TP25-fund-e-ft-over-ds geführt (Scope wifi-security, Ablauf 2026-09-03). Sie gehört einer anderen, laufenden Session; grün machen würde deren Versuch unsichtbar machen. ⚠️ Merkregel: vor jeder Drift-Bewertung python3 nautobot/gc-transaktion.py status lesen. Drift aus einem laufenden Versuch sieht identisch aus wie ein Versehen — genau dafür gibt es das Werkzeug. (Diese Zeile behauptete zuerst, die Drift käme vom 7.24.1-Upgrade. Falsch: der Core wurde erst um 14:36 gehoben, sechseinhalb Stunden nach dem Hebel.)*

REIHENFOLGE

Erst test-tp163 (§5.1), dann n8n → gitea → hass → vw — steigende Kritikalität, vw zuletzt. Nach jedem Namen die Abnahme aus §5.3, erst dann der nächste.

WICHTIGSTE FALLEN

• 🔴 healthy beweist nichts über das Origin. Der Tunnelstatus sagt nur, dass der Connector mit Cloudflare redet. Die Wildcard-Access-App *.emsenhuber.net liefert für jeden Namen ein sauberes 302 — ein toter Dienst sieht so monatelang gesund aus (der grafana-Fall). Der einzige Streckenbeweis ist §5.1 gegen einen Testnamen.
• 🔴 WARP muss AUS sein. Mit aktivem WARP läuft der Test über den Mesh und beweist den öffentlichen Weg nicht — dieselbe Fehldiagnose-Klasse wie der ICMP-Fall 2026-08-13. Testen von außerhalb des LAN, über Mobilfunk.
• 🔴 vw = Bitwarden läuft auf Access-Bypass. Vor dem Flip prüfen, dass die Bypass-Policy für vw.emsenhuber.net steht — sonst sperrt der Flip alle Bitwarden-Clients aus.
• 🔴 gitea: Access gilt nur der Web-UI, Git-/API-Pfade laufen daran vorbei. Push von außen vor und nach dem Flip testen, nicht nur die UI.
• 🔴 hass: die Companion-App kann kein Access-Login. Nach dem Flip die App auf dem Handy über Mobilfunk prüfen, nicht nur den Browser.
• ⚠️ ERR_TOO_MANY_REDIRECTS nach einem Flip = Blocker A ist zurück (Ingress auf :80 statt :443, oder originServerName fehlt). Sofort zurückflippen, nicht debuggen während der Name tot ist.
• ⚠️ ~/.secrets/credentials.env lässt sich in zsh nicht sourcen (rohe WireGuard-Zeilen ab ~Zeile 69) — Variablen bleiben still leer, das sieht aus wie ein ungültiger Token. Immer bash -c.
• 🔴 Maskierung: Muster auf den Schlüsselnamen ankern, nie auf ein Trennzeichen. grep -n "TOKEN" datei | sed 's/:.*TOKEN/…/' maskiert nicht — grep -n stellt <zeile>: voran, und das matcht das Muster. So sind in der Vorsession zwei Nautobot-Tokens ins Transkript geraten. Sicher ist nur sed -E 's/(TOKEN|PASSWORD|SECRET|KEY|PASS)=.*/\1=<redacted>/'.

GOVERNANCE

• Config-Änderungen an MikroTik-Geräten ausschließlich über Nautobot Golden Config (nautobot/gc-manual-plan.py), nicht per Direkt-Write. Nautobot: http://10.40.20.30:8080 (Port 8080, nicht 80 — der Runbook-Stand nannte lange nur den Host), Token in docs/nas-vlan20/stacks/210-nautobot.yml (gitignored, nur im Haupt-Checkout).
• Cloudflare-Änderungen sind outward-facing: DNS-Flip und Ingress-Edits vor der Ausführung mit Christoph bestätigen, einer nach dem anderen.
• MCP-Lifecycle aktiv melden, falls sich daran etwas ändert.

OFFENE PUNKTE, DIE NICHT IN DIESE SESSION GEHÖREN

1. Rotation zweier Nautobot-Tokens (NAUTOBOT_SUPERUSER_API_TOKEN, NAUTOBOT_GITEA_TOKEN) — in der Vorsession ins Transkript geraten, als verbrannt zu behandeln. Gehört zu TP30.
2. crs326-core / wifi-security / ft-over-ds — offene Transaktion TP25-fund-e-ft-over-ds einer laufenden TP25-Session. Nicht anfassen, nicht grün machen, Ablauf 2026-09-03.
3. mcp/mikromcp/config/routers.yaml meldet rosVersion: "7.24" für alle fünf, live ist 7.24.1 — kosmetisch, gehört auf main.
4. §6 Abbau (sechs Container, drei Alttunnel) — frühestens 7 Tage nach dem Flip. 🚫 terpene-cloudflared (LXC 400) und fm.emsenhuber.net bleiben, sie stehen im docker ps direkt neben den zu löschenden. Namen lesen, nicht Zeilen zählen.

ABNAHME DIESER SESSION

• Entscheidung zu den sechs Drifts getroffen und umgesetzt (Compliance erklärt oder bereinigt)
• test-tp163 von außerhalb des LAN ohne WARP: Access-Login, keine Redirect-Schleife
• Testname und Testregel danach wieder entfernt
• Alle vier Namen geflippt, je einzeln mit 15 min Beobachtung, kein 530/1033
• gitea-Push von außen funktioniert nach dem Flip
• hass-Companion-App über Mobilfunk funktioniert nach dem Flip
• vw Bitwarden-Clients funktionieren nach dem Flip
• Caddy-Log zeigt die Requests (ssh root@10.40.20.100 'pct exec 130 -- journalctl -u caddy -n 20')

ARBEITSWEISE

Bestandsaufnahme vor Plan. Eine große Fragenrunde statt vieler kleiner. Bei Abweichungen zwischen Doku und Live-Stand: Drift melden, nicht stillschweigend korrigieren. Vor jedem Flip den Rollback-Weg (§7, Record-IDs in docs/cf-backup/cnames-tunnel-*.json) parat haben.