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>

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

@@ -49,15 +49,24 @@ ohne Passwort verweigert) — das ist der nächste konkrete Schritt.
 
 ---
 
-## 3. 🔴 Latenter Fund: vier Container überleben keinen Reboot sauber
+## 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 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.**
+🔑 **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).
 
 ---
 
@@ -89,8 +98,9 @@ alte §5.3-Punkt „Caddy sieht den Request" konnte nie funktionieren.
    🚫 `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.
+   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.