TP39: networking.service in vier LXCs repariert (Ursache = VLAN1-Altlast)

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>

CLAUDE.md

@@ -222,6 +222,22 @@ GW je VLAN = `.1` (crs326-core L3) · Mgmt VLAN99: core `.99.1`, branch `.99.2`,
   an derselben MariaDB, und die Annahme „Vaultwarden nutzt SQLite" war schlicht falsch;
   (c) **ein toter Resolver ist selten allein** — der Sweep über alle LXCs fand **fünf** Container mit
   `10.40.41.254`. Sweep: `for c in $(pct list|awk 'NR>1{print $1}'); do pct exec $c -- grep ^nameserver /etc/resolv.conf; done`
+- 🔌 **`networking.service` failed bei funktionierendem Netz = tote `auto`-Stanzas in
+  `/etc/network/interfaces`** (Ursache gefunden + behoben 2026-09-01). In vier LXCs standen dort noch
+  Einträge aus dem **alten VLAN1-Schema** (`eth0` → `10.40.41.x`) und aus früheren Versuchen
+  (`veth16`, `veth24`, Tippfehler `eth01`) — auf Interfaces, die es im Container gar nicht gibt.
+  `ifup -a` scheitert daran, das echte `veth20` kommt trotzdem hoch. **Fix:** nur die Stanzas
+  entfernen, deren Interface in `ip -br link` fehlt (`lo` und die echten behalten), Backup daneben.
+  🔴 **Abnahme ist ein echter Reboot, nicht `systemctl is-active`** — der Servicestatus sagt nichts
+  darüber, ob beim nächsten Start etwas hochkommt.
+- 🧪 **Ein Messwerkzeug, das etwas anderes beantwortet als die Frage, kostet mehr Zeit als der Fehler**
+  (zweimal in einer Nacht, 2026-09-01). (a) **`nc -z` lieferte falsch-negative** „Port zu" für neun
+  Dienste gleichzeitig — inklusive des SSH-Ports, über den die Session gerade arbeitete; `curl` bekam
+  von demselben Host **HTTP 200 in 24 ms**. **Bei „alles gleichzeitig kaputt" zuerst das eigene
+  Werkzeug verdächtigen**, dann das Netz: ein Python-Socket oder `curl` entscheidet in Sekunden.
+  (b) **Ein Firewall-Zähler taugt nicht als Wegbeweis**, wenn der Client die Verbindung offenhält
+  (`cloudflared`): er zählt nur NEUE Verbindungen und steht still, obwohl alles läuft — richtig ist
+  die **Verbindungstabelle** (`/ip firewall connection`).
 - 🔌 **`networking.service` kann in einem LXC dauerhaft `failed` sein, ohne dass das Netz fehlt** —
   und dann startet alles mit `After=network-online.target` nach einem Reboot **nicht**
   (Fund 2026-09-01: `101`, `102`, `106`, `107`; **influxdb2 kam nach dem Neustart nicht hoch**,