# Ü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`).
🔴 **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, `crs326-core` / `wifi-security` / `ft-over-ds`, ist die bekannte aus dem
7.24.1-Upgrade und gehört weiterhin nicht in diese Session.)*

## 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`** — bekannte Drift, braucht eigenen Entscheid
   plus CAP-Re-Provisionierung.
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.