bf-infra/docs/handoff-20260901-tp16.3-paragraph5-flip-durch.md

Handoff — TP16.3 §5 durch: alle vier Namen auf bf-public, plus ein 10-Sekunden-Fund

2026-08-31/09-01. Nachfolger von handoff-20260831-tp16.3-paragraph2-3-durch.md. Nicht Teil dieser Session: §6 (Abbau).

---

1. Was jetzt steht

Alle vier öffentlichen Namen laufen über bf-public — der öffentliche Verkehr geht damit erstmals über Caddy statt an ihm vorbei.

Name	Nachweis von außen	Origin bewiesen?
gitea	200, i_like_gitea-Cookie = echte Gitea-Antwort	✅
hass	200 + manifest.json 200 + WebSocket 101 Switching Protocols	✅ inkl. Companion-App-Pfad
vw	/, /alive, /api/config je 200; WS-Hub 401 von Vaultwarden	✅
n8n	302 zum Access-Login (vor und nach dem Flip)	❌ — vom User im Browser bestätigt

Antwortzeiten vorher/nachher unverändert ⇒ Caddy im Pfad kostet nichts Messbares. 🚫 Die drei Alttunnel stehen bewusst weiter (bf-mm/bf-nas/bf-pve, je healthy/8) — sie sind die Rückfallebene. Rückweg je Name = ein PATCH auf die alte Tunnel-ID.

Schicht davor, ebenfalls durch: die sechs AP-Drifts sind ins Soll gehoben, Compliance 139/140 (28 Regeln × 5 Geräte). Übrig bleibt genau crs326-core/wifi-security = offene Transaktion TP25-fund-e-ft-over-ds. Neu: ComplianceRule interface-veth + zwei ConfigReplace-Regeln, die die gerätevergebenen veth-MACs normalisieren (nautobot/ingest-veth-rule.py).

---

2. 🔴 Der eigentliche Fund der Nacht: ein 10-Sekunden-Zoll auf drei Diensten

gitea hing bei ~10 % der Anfragen exakt 10,1 s — quer über Web-UI, /api/healthz und den Git-Pfad. Ursache: MariaDB (LXC 302) hatte skip-name-resolve auskommentiert und machte bei jeder neuen Verbindung einen Reverse-Lookup, während ihr /etc/resolv.conf auf den toten 10.40.41.254 zeigte. Gemessen: 10.010 ms je Lookup.

An derselben DB hängen Vaultwarden (.127), Home Assistant (.105) und gitea (.157) — über die Verbindungstabelle belegt.

Fix (User-Freigabe, Wartungsfenster): pct set <id> --nameserver 10.40.20.1 + Reboot für 302 mariadb, 102 mqtt5, 106 influxdb2, 107 redis, 150 iob-exposed. Nachher: Lookup 21–24 ms; gitea 0 von 25 Proben langsam, langsamste 75 ms.

⚠️ Strukturell offen: skip-name-resolve ist weiter aus. Setzen bricht alle Grants, die auf Hostnamen statt IPs lauten ⇒ vorher mysql.user lesen. DB-Zugang fehlt (root@localhost ohne Passwort verweigert) — das ist der nächste konkrete Schritt.

---

3. 🔴 Latenter Fund: vier Container überleben keinen Reboot sauber

networking.service und ifupdown-wait-online.service sind in 101, 102, 106, 107 fehlgeschlagen. Folge: alles mit After=network-online.target startet nach einem Reboot nicht — influxdb2 kam nicht hoch, Unit enabled, kein Startversuch im Journal. Von Hand sofort ok.

🔑 Nicht von dieser Session verursacht: 101 wurde nie angefasst und zeigt dieselben Units. Die Container liefen nur 13+ Tage ohne Neustart. Diese vier sind einen Reboot davon entfernt, still einen Dienst zu verlieren.

---

4. Drei Messfallen, die diese Session Zeit gekostet haben

1. Split-Horizon: der Haus-Resolver liefert für alle vier Namen direkt 10.40.20.40 — ein Test von zuhause sieht Cloudflare nie. Prüfen nur mit curl --resolve <name>:443:188.114.96.10 oder von außerhalb. (Guter Nebeneffekt: ein misslungener Flip bricht intern nichts.)
2. Access antwortet je nach Standort verschieden: n8n aus dem Haus 200 (bf4-Policy), von außen 302. hass/vw/gitea stehen auf bypass — dort nie ein Login. ⚠️ Die App hass, vw, gitea heisst zu Recht so: sie führt alle drei in self_hosted_domains, das Feld domain zeigt nur den ersten. Ein Rename wäre eine Verschlechterung gewesen.
3. 🔴 „Der Host ist ausgefallen" war der eigene Standortwechsel. Ping/SSH/Caddy waren tot, weil die Session-Maschine auf einen Hotspot gewandert war (route -n get default = 172.20.10.1). Daraufhin wurde ein bereits erfolgreicher n8n-Flip grundlos zurückgerollt. Merkregel: vor jeder Ausfallmeldung die eigene Default-Route lesen.

Dazu zwei Werkzeug-Befunde: der Zähler der Blocker-B-Firewallregel taugt nicht als Wegbeweis (cloudflared hält die Origin-Verbindung offen ⇒ kaum neue Verbindungen ⇒ Zähler steht still, obwohl alles läuft; richtig ist die Verbindungstabelle), und Caddy führt gar kein Access-Log ⇒ der alte §5.3-Punkt „Caddy sieht den Request" konnte nie funktionieren.

---

5. Nächste Schritte

1. §6 Abbau — sechs Container + drei Alttunnel. Frühestens nach störungsfreiem Betrieb; Christoph hat den Flip vorgezogen freigegeben, nicht den Abbau. 🚫 terpene-cloudflared (LXC 400) und fm.emsenhuber.net bleiben. Namen lesen, nicht Zeilen zählen.
2. TP39 (angelegt 2026-09-01, User-Okay) fasst die zwei Restpunkte aus §2 und §3 zusammen: skip-name-resolve auf der MariaDB (vorher mysql.user gegen Hostname-Grants prüfen, DB-Zugang fehlt) und das kaputte networking.service in 101/102/106/107. Dazu der Resolver-Sweep als wiederkehrende Kontrolle, auch über die NAS-Container.
3. TP30: die zwei Nautobot-Tokens rotieren (vom User vertagt, weiterhin offen).
4. TP14.4: ohne Service-Token für die Wildcard-App ist n8n von außen nicht bis zum Origin prüfbar.
5. Caddy-Access-Log (TP31/TP34): der öffentliche Reverse Proxy protokolliert keine Requests.
6. mcp/mikromcp/config/routers.yaml meldet weiter rosVersion: "7.24", live ist 7.24.1.