TP16.3: nautobot aus dem CF-Ingress geschnitten, Probe laeuft

Runbook ausgefuehrt. Vorbedingungen alle erfuellt, Testclient hing im
Hotspot-Netz 172.20.10.13 mit aktivem WARP -- also nicht im BF-LAN, der
einzige Aufbau der fuer Vorbedingung 2 etwas beweist.

Schnitt: nautobot.emsenhuber.net aus bf-nas (8 -> 7 Regeln), Catch-all
bleibt letzte. Rollback-Sicherung in docs/cf-backup/. Gegenprobe durch
Zuruecklesen der Config, nicht am Statuscode.

Abnahme vollstaendig, inkl. des uebersehenen Punktes: Golden Config lief
durch (Backup -> Intended -> Compliance, 104/104, 0 Drifts). Die uebrigen
fuenf bf-nas-Hostnames unveraendert.

Befund, der die Abnahmetabelle des Runbooks korrigiert: der oeffentliche
FQDN taugt nicht als Test. Er liefert vor UND nach dem Schnitt 302, weil
der von Cloudflare Access kommt, nicht vom Origin -- Access greift vor
dem Tunnel (JWT: auth_status NONE bei is_warp true). Damit auch eine
ehrlichere Erwartung: nautobot war nie ohne Access-Login oeffentlich
erreichbar, der Schnitt entfernt die zweite Tuer, nicht die erste.

Paragraph 7 des Runbooks ist ueberholt -- die HA-Degradierung ist am
selben Tag repariert, der Fall steht auf dem verbliebenen Argument.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/tp16.3-nautobot-mesh-only-runbook.md

@@ -119,3 +119,68 @@ nach dem Schnitt gehört ein Job-Lauf zur Abnahme, nicht nur ein Browser-Aufruf.
 Die **TP16-HA-Degradierung** (`bf-nas` und `bf-pve` haben je nur **einen** Connector, Befund 2026-08-16)
 verliert an Gewicht, je weniger Dienste an cloudflared hängen. Das ersetzt die Reparatur nicht —
 aber es verkleinert, was der SPOF trifft.
+
+---
+
+## 8. ▶️ AUSGEFÜHRT 2026-08-24 — der Schnitt sitzt, Probe läuft
+
+**Vorbedingungen (§3), alle erfüllt:**
+
+| Prüfung | Ergebnis |
+|---|---|
+| vnet-Route `10.40.0.0/16` → `bf-core-mesh` | ✅ vorhanden (CF `teamnet/routes`) |
+| `cf-mesh` am Core | ✅ `R`, last-handshake 33 s, 198 MiB rx / 738 MiB tx |
+| `http://10.40.20.30:8080` **von außerhalb des LAN, WARP aktiv** | ✅ HTTP 302 in 0,18–0,36 s |
+| ICMP zu `10.40.20.30` | ✅ 0 % Loss *(kein Beweis, aber es schließt die WARP-Falle aus)* |
+
+🎯 **Der Testclient war zufällig genau der richtige:** die Session lief auf einem Host im
+**Hotspot-Netz `172.20.10.13`** mit aktivem WARP — also *nicht* im BF-LAN. Das ist der einzige Aufbau,
+der für Vorbedingung 2 etwas beweist; aus dem LAN heraus geht es ohnehin.
+
+**Der Schnitt:** `nautobot.emsenhuber.net` aus dem Ingress von `bf-nas`
+(`220c9958-401b-4111-9451-f3db09bba2d5`) entfernt, **8 → 7 Regeln**, Catch-all weiterhin letzte.
+Rollback-Sicherung: **`docs/cf-backup/bf-nas-ingress-20260824-vor-tp16.3.json`**.
+Gegenprobe **durch Zurücklesen der Config vom Dienst**, nicht am Statuscode: `nautobot noch drin? False`.
+
+**Abnahme (§5):**
+
+| Prüfung | Ergebnis |
+|---|---|
+| `10.40.20.30:8080` mit WARP von außerhalb | ✅ 302 in 0,16–0,17 s |
+| `gitea` / `grafana` / `pve-mcp` / `vw` / `ds-bf` | ✅ je 3 Läufe, unverändert (200/302/302/200/302) |
+| **Golden-Config-Pipeline** | ✅ Backup → Intended → Compliance, **104/104 compliant, 0 Drifts** |
+| Öffentlicher FQDN nicht mehr bedient | ⚠️ **so nicht testbar — s.u.** |
+
+### 🔴 Befund: die erste Abnahmezeile aus §5 ist als Test untauglich
+`https://nautobot.emsenhuber.net/` antwortet **vor und nach** dem Schnitt mit **HTTP 302** — und zwar
+identisch, weil der 302 **nicht vom Origin kommt, sondern von Cloudflare Access**:
+`location: https://emsenhuber.cloudflareaccess.com/cdn-cgi/access/login/nautobot.emsenhuber.net`.
+Access greift **vor** dem Tunnel; der Request erreicht den Ingress gar nicht, solange keine
+Access-Session besteht. Im mitgelieferten JWT steht `"auth_status":"NONE"` bei gleichzeitig
+`"is_warp":true` — **WARP-Identität allein erfüllt die Policy für `nautobot` nicht**, es braucht den
+interaktiven Login.
+
+⇒ **Konsequenzen, beide wichtig:**
+1. **Der Statuscode des öffentlichen FQDN kann diesen Schnitt weder belegen noch widerlegen.** Der
+   gültige Nachweis ist das **Zurücklesen der Ingress-Config** (oben) — dieselbe Regel wie in
+   TP22/TP23: nicht die Antwort des Frontends zählt, sondern der Zustand am Dienst.
+2. **Der öffentliche Weg war schon vorher zu.** Nautobot war nie ohne Access-Login erreichbar; der
+   Schnitt entfernt also die *zweite* von zwei Türen, nicht die erste. Das schmälert den Gewinn nicht
+   (eine Ingress-Zeile und ein Connector-Paar weniger), aber es korrigiert die Erwartung: **hier wurde
+   keine offene Tür geschlossen, sondern eine überflüssige entfernt.**
+
+📌 **Nebenprüfung, die den Schnitt hätte kippen können:** `nautobot/gc-configplan.py` spricht
+`http://10.40.20.30:8080/api` — die **private** IP. Kein Repo-Skript benutzt den öffentlichen Namen
+(`grep` über `*.py`/`*.sh`/`*.yml`/`*.env`: kein Treffer). Die Werkzeugkette hängt also nicht am
+gekappten Weg. **Das gehört vor jeden weiteren Schnitt der rechten Spalte geprüft.**
+
+### ⏳ Offen: das Betriebsfenster
+**Eine Woche fahren (bis ~2026-08-31), dann entscheiden.** Rollback = die gesicherte Config
+zurückschreiben, eine Minute. Danach steht die Frage, ob `pve`, `portainer`, `grafana`, `pve-mcp`,
+`ha-mcp`, `gitea-mcp`, `ds-bf`, `ccu`, `iobroker`, `z2m25` folgen.
+
+### 📌 §7 ist überholt
+Der dort beschriebene Nebeneffekt („die HA-Degradierung verliert an Gewicht") ist gegenstandslos:
+**TP16 ist am selben Tag repariert** — alle drei bf-Tunnel laufen wieder auf 2 Connectoren
+(`cf-tunnel-mapping.md §15`). Der Fall für TP16.3 steht damit auf dem verbliebenen Argument, und das
+ist das eigentliche: **weniger bewegliche Teile für Dienste, die öffentlich nicht gebraucht werden.**