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

TP16.3 — Probe: nautobot aus dem CF-Ingress nehmen (mesh-only)

Stand 2026-08-19 · vorbereitet, nicht ausgeführt. Die Recherche zu TP16.3 ist seit 2026-08-17 durch; offen war nur die Umsetzung. Dieses Runbook macht daraus einen ausführbaren, in einer Minute zurücknehmbaren Schnitt.

---

1. Worum es geht (in drei Sätzen)

Der private Datenpfad läuft seit TP16.1 über natives WireGuard auf dem Core (cf-mesh), nicht über Container — belegt, nicht vermutet: im TP5-Log-Lauf standen 137 Zeilen in:cf-mesh. Für Dienste, die niemand ohne WARP im Browser aufrufen muss, ist cloudflared damit überflüssiger Aufwand: eine Ingress-Zeile, ein Connector-Paar, eine HA-Frage. Diese Probe nimmt einen solchen Dienst heraus und schaut eine Woche zu.

Warum ausgerechnet nautobot

Kriterium	nautobot
Wer nutzt es	nur Christoph — kein Fremdgerät, kein Gast
Braucht es einen Client ohne Access-Login?	nein (das ist das TP16.2-Kriterium, an dem vw hängt)
Wie oft schon per Mesh angefasst	62× im TP5-Log — der Spitzenreiter
Was kostet ein Fehlschlag	nichts Produktives; im Zweifel greift man per IP zu

---

2. 🔴 Die Verwechslungsfalle, die den ganzen TP kippen kann

Mesh-Hostname-Routes sind Egress, nicht Publishing. Cloudflare kennt seit 2026-07-02 auch Hostname-Routes auf dem Mesh — die klingen so, als könnten sie den Ingress ersetzen. Sie können es nicht: sie leiten ausgehenden Verkehr zu diesem Hostname über den Node und egressen mit dessen öffentlicher IP. Sie veröffentlichen nichts.

Wer das verwechselt, baut den öffentlichen Strang ab und wundert sich, warum von außen nichts mehr geht. → Diese Probe ersetzt nichts. Sie entfernt einen Dienst, der öffentlich gar nicht gebraucht wird.

---

3. Vorbedingung — VOR dem Schnitt prüfen (read-only)

Alle drei Punkte müssen erfüllt sein, sonst wird nicht geschnitten:

1. Die Mesh-Route steht. Auf dem Core: die vnet-Route 10.40.0.0/16 zeigt auf bf-core-mesh (TP16.1 §4.4, „Weg A"). Ohne sie ist Mesh-Zugriff auf 10.40.20.30 gar nicht möglich.
2. Der Dienst antwortet über die private IP, mit aktivem WARP — von einem Client, der nicht im BF-LAN steht (das ist der einzige Test, der etwas beweist; im LAN geht es ohnehin):

   http://10.40.20.30:8080
   

3. ⚠️ ICMP nicht als Beweis nehmen, aber auch nicht als Gegenbeweis. Der Mesh kann ICMP (das war der Gewinn von TP16.1). Wenn Ping scheitert, TCP aber geht, ist zuerst zu prüfen, ob lokal noch ein WARP-Client läuft — s. Memory ref_warp_local_icmp_trap. Umgekehrt ist ein erfolgreicher Ping kein Beleg, dass der HTTP-Dienst erreichbar ist.

---

4. Der Schnitt

Was: die nautobot-Zeile aus der Ingress-Config des Tunnels bf-nas entfernen. Die DNS-CNAME-Zeile bleibt zunächst stehen (Rollback bleibt so eine reine Ingress-Operation).

Womit: die Cloudflare-API mit CF_API_TOKEN.

🔴 Nicht über den Cloudflare-MCP. Der ist strikt read-only — Writes gehen ausschließlich über die API mit dem Token (Memory ref_cf_mcp_readonly_token_writes). Das Token ist account-owned, nutzt also einen anderen verify-Endpoint als ein User-Token, und läuft am 2027-01-09 ab.

Wo die Werte stehen: mcp/cloudflare/.env (chmod 600, gitignored) — CF_API_TOKEN, CF_ACCOUNT_ID, CF_BF_TUNNEL_ID.

Ablauf:

1. Ist-Config sichern (das ist der Rollback): GET /accounts/{account_id}/cfd_tunnel/{tunnel_id}/configurations → JSON wegschreiben, mit Datum.
2. Aus dem ingress-Array die nautobot-Zeile entfernen. ⚠️ Die abschließende Catch-all-Regel (service: http_status:404 ohne hostname) muss die letzte bleiben — sonst greift der Ingress für alle übrigen Hostnames nicht mehr.
3. Zurückschreiben: PUT derselben Route mit dem gekürzten Array.
4. Gegenprobe am Gerät, nicht am Statuscode: ein GET der Config liest zurück, was wirklich steht. (Dieselbe Regel wie in TP22/TP23: ein „success" der API ist kein Wirksamkeitsnachweis.)

---

5. Abnahme

Prüfung	Erwartung
Öffentlicher FQDN nautobot.… ohne WARP	nicht mehr erreichbar (das ist der Zweck)
http://10.40.20.30:8080 mit WARP, von außerhalb des LAN	erreichbar
Die übrigen Hostnames auf bf-nas (gitea, grafana, pve-mcp, vw, ds-bf)	unverändert erreichbar
Golden-Config-Deploys (Netmiko aus Nautobot)	laufen weiter

🔴 Der letzte Punkt ist der, den man übersieht: Nautobot ist nicht nur eine Web-UI, sondern die Deploy-Pipeline. Der Netmiko-Deploy kommt von 10.40.20.31 (nautobot-worker), nicht von .20.30 — das war einer der vier TP5-Funde. Der Schnitt betrifft nur den eingehenden öffentlichen Weg, aber nach dem Schnitt gehört ein Job-Lauf zur Abnahme, nicht nur ein Browser-Aufruf.

---

6. Betriebsfenster und Rollback

• Eine Woche fahren, dann entscheiden: bleibt es so, oder kommt es zurück.
• Rollback = die gesicherte Ingress-Config aus Schritt 1 zurückschreiben. Eine Zeile, eine Minute.
• Danach ist zu entscheiden, ob weitere Dienste der rechten Spalte folgen (pve, portainer, grafana, pve-mcp, ha-mcp, gitea-mcp, ds-bf, ccu, iobroker, z2m25).

Was in dieser Probe ausdrücklich NICHT entschieden wird

• vw, hass, n8n bleiben öffentlich — harte Kriterien: Bitwarden-Clients (TP16.2-Constraint), die HA-Companion-App (das 400-Muster), eingehende Webhooks von Dritten.
• gitea ist offen und wird hier nicht mitentschieden: Git-Clients/CI von außen können keinen interaktiven Access-Login. Braucht eine eigene Prüfung, ob es solche Zugriffe real gibt.

---

7. Nebeneffekt, der den Fall stärkt

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.