Christoph Emsenhuber
3ea8d050d2
101 iob-master, 102 mqtt5, 106 influxdb2, 107 redis meldeten networking.service und ifupdown-wait-online.service dauerhaft als failed, bei funktionierendem Netz. Folge: alles mit After=network-online.target startet nach einem Reboot nicht -- influxdb2 kam gestern Nacht nicht hoch (Unit enabled, kein Startversuch im Journal). URSACHE, und es ist dieselbe Altlast wie beim toten Resolver: in /etc/network/interfaces standen noch auto-Stanzas aus dem alten VLAN1-Schema (eth0 -> 10.40.41.x, teils mit gateway 10.40.41.254) sowie aus frueheren Versuchen (veth16, veth24, ein Tippfehler eth01) -- alle auf Interfaces, die es im Container gar nicht gibt. ifup -a scheitert daran, waehrend das echte veth20 sauber hochkommt. Der VLAN-Umzug hat die Container umgehaengt, aber die alten Stanzas nie entfernt. FIX: nur Stanzas entfernt, deren Interface in ip -br link fehlt; lo, veth20 und veth20.2 unangetastet. Backup je Container: /etc/network/interfaces.bak-20260901. ABNAHME war ein echter Reboot, nicht systemctl is-active: 106 neu gestartet, influxdb kam nach 5 s VON SELBST hoch, networking active, null failed units. Endstand ueber alle 13 LXC: dns=10.40.20.1 durchgehend, networking ueberall sauber. Ohne Netzbezug bleiben run-rpc_pipefs.mount (101, 150) und proxmox-regenerate-snakeoil.service (108), beide vorbestehend. MESSFALLE, mit in CLAUDE.md aufgenommen: nc -z meldete waehrenddessen neun Dienste gleichzeitig als "Port zu" -- inklusive des SSH-Ports, ueber den diese Session gerade arbeitete, waehrend curl vom selben Host HTTP 200 in 24 ms bekam. Bei "alles gleichzeitig kaputt" zuerst das eigene Werkzeug verdaechtigen. Es waere um ein Haar die zweite falsche Ausfallmeldung dieser Nacht geworden. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
108 lines
6.5 KiB
Markdown
108 lines
6.5 KiB
Markdown
# 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`](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 — gefunden UND behoben: vier Container überlebten 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 vor dem Fix nie angefasst und zeigte dieselben
|
||
Units. Die Container liefen nur 13+ Tage ohne Neustart, deshalb war es unsichtbar.
|
||
|
||
✅ **Behoben 2026-09-01.** **Ursache — dieselbe Altlast wie beim Resolver:** tote `auto`-Stanzas in
|
||
`/etc/network/interfaces` aus dem **alten VLAN1-Schema** (`eth0` → `10.40.41.x`) und aus früheren
|
||
Versuchen (`veth16`, `veth24`, Tippfehler `eth01`), alle auf **nicht existierende** Interfaces.
|
||
`ifup -a` scheiterte daran, während `veth20` sauber hochkam. Entfernt wurden ausschliesslich Stanzas,
|
||
deren Interface in `ip -br link` fehlt; Backup je Container `/etc/network/interfaces.bak-20260901`.
|
||
🔴 **Abnahme war ein echter Reboot, nicht der Servicestatus:** `106` neu gestartet ⇒ **influxdb kam
|
||
nach 5 s von selbst hoch**, `networking active`, null fehlgeschlagene Units.
|
||
Endstand: **alle 13 LXCs auf `dns=10.40.20.1`, `networking` überall sauber.** Rest ohne Netzbezug:
|
||
`run-rpc_pipefs.mount` (101, 150), `proxmox-regenerate-snakeoil.service` (108).
|
||
|
||
---
|
||
|
||
## 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). **Punkt 2 (`networking.service`) ist am 2026-09-01 bereits erledigt** — offen bleiben
|
||
`skip-name-resolve` und 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`.
|