# VLAN1-Rückbau — Howto für die manuellen Schritte > Stand 2026-08-15. Gegenstück zum Plan „VLAN1-Rückbau: `.41.211` (Core), `.41.100` (pve), > Prometheus-Ziele". Hier steht **nur, was du selbst machen musst** — was ich übernehmen kann, > steht unten unter „Was ich mache". --- ## Die eine Regel, die die Reihenfolge bestimmt `10.40.41.100` ist derzeit der **einzige lebende VLAN1-Host**, und Home Assistant erreicht pve heute genau darüber. Dieser Pfad existiert nur, weil der Core noch die Adresse `10.40.41.211` trägt und damit die Route zu `10.40.41.0/24` stellt. ➡️ **Schritt 1 und 2 müssen fertig sein, bevor irgendjemand `.41.100` oder `.41.211` entfernt.** Sonst reißt die laufende pve-Anbindung ab. --- ## Schritt 1 — Home Assistant: pve-Integration auf `10.40.20.100` **Wo:** HA-Weboberfläche → Einstellungen → Geräte & Dienste → **Proxmox VE** (Kachel heißt heute `10.40.41.100`) → ⋮ → **Neu konfigurieren**. Host auf `10.40.20.100` ändern, Port `8006` bleibt. **Warum du und nicht ich:** die Integration hat *keinen* Options-Flow (`supports_options: false`), nur einen Reconfigure-Flow. Der fragt die Proxmox-Zugangsdaten erneut ab — und Passwörter oder API-Token gebe ich grundsätzlich nicht ein. Das ist der Teil, der bei dir bleiben muss. **Das Netz ist nachweislich nicht das Problem** (falls es wieder hakt, such nicht dort): - `pveproxy` lauscht auf `*:8006`, `pve-firewall` ist *disabled*, keine iptables-Regel, kein `/etc/default/pveproxy`. - `https://10.40.20.100:8006` antwortet aus VLAN10 **und** VLAN20 mit HTTP 200 in ~0,06 s. - HA selbst redet längst problemlos mit VLAN20 und VLAN99: `mqtt` → `10.40.20.108`, `influxdb` → `10.40.20.8`, alle vier `mikrotik`-Integrationen auf `.99.x` sind `loaded`. --- ## Schritt 2 — Portainer hängt: `docker system df` auf der NAS ⏳ OFFEN, deine Entscheidung > ⚠️ **Korrektur (2026-08-15):** meine erste Erklärung — die tote Umgebung `odroid-m1` — war > **falsch**. Du hast sie entfernt, die Integration hängt weiter. Alle verbliebenen Endpoints > antworten in 0,01–0,16 s. Die Vermutung ist damit widerlegt, nicht nur unbestätigt. **Die tatsächliche Ursache, aus dem HA-Debug-Log:** ``` pyportainer.exceptions.PortainerTimeoutError: Timeout error while accessing GET https://10.40.20.126:9443/api/endpoints/14/docker/system/df -> UpdateFailed -> ConfigEntryNotReady -> setup_retry ``` Die HA-Integration ruft beim Setup `docker system df` für **jede** Umgebung auf. Gemessen: | Endpoint | `docker system df` | |---|---| | ep2 `pve` | 0,05 s | | **ep14 `nas-bf`** | 🔴 **kam nach 180 s nicht zurück** | | ep20 `macmini` | 0,33 s | | ep21 `nas-fm` | 0,98 s | Direkt auf der NAS gemessen (`sudo /usr/local/bin/docker system df`): der Befehl **gibt die Tabelle aus und beendet sich dann nicht** — Exit-Code 124 nach 120 s, obwohl die Daten längst da waren. Die Mengen sind harmlos (25 Images / 13 GB, 21 Container, 10 Volumes / 79 MB), es ist also **kein Größenproblem**, sondern ein hängender Aufruf im dockerd der Synology. Das Container-Listing auf demselben Endpoint dauert 0,16 s — nur `system df` klemmt. ### Container-Manager-Neustart durchgeführt (2026-08-15) — hat den Hänger behoben, reicht aber nicht `synopkg stop/start ContainerManager` (Binary liegt unter `/usr/syno/bin/synopkg`, **nicht** im sudo-PATH). Ergebnis: - ✅ **Alle 14 Container aus der Baseline sind zurück**, keiner fehlt. Zusätzlich kam `hms-mqtt` hoch, der vorher nicht lief (Restart-Policy) — **prüfen, ob der bleiben soll**. - ✅ `docker system df` **beendet sich wieder** (vorher: gab die Tabelle aus und hing dann; rc=124). - ❌ **Aber es ist weiterhin viel zu langsam und schwankt stark:** 33 s → 92 s → 3× über 120 s. `pyportainer` gibt lange vorher auf, die Integration bleibt auf `setup_retry`. **Wo die Zeit hingeht — gemessen, nicht vermutet:** | Aufruf | Dauer | |---|---| | `docker images -q` | 84 ms | | `docker ps -aq` | 95 ms | | `docker volume ls -q` | 65 ms | | **`docker system df`** | **33–92+ s** | Das Auflisten ist trivial schnell; die Zeit geht **vollständig in die Größenberechnung**, also das `du`-artige Durchlaufen der overlay2-/Volume-Verzeichnisse auf den NAS-Platten. Das ist ein struktureller Nachteil dieser Plattform, kein Defekt — und die HA-Integration ruft `system df` für **jede** Umgebung bei **jedem** Update auf. ### Der aussichtsreichste Weg: eigener Portainer-Benutzer für HA Portainer kann Umgebungszugriff pro Benutzer beschränken. Ein HA-eigener Benutzer mit Zugriff auf **ep2, ep20, ep21 — aber nicht ep14** löst das Problem an der Wurzel: die Integration sieht die langsame NAS-Umgebung dann gar nicht. **Wo:** Portainer → Users → neuen Benutzer anlegen → Environments → Zugriff auf ep14 entziehen → Access-Token erzeugen → in HA die Portainer-Integration mit diesem Token neu anlegen. **Warum du und nicht ich:** Benutzer anlegen und Token erzeugen sind Konto- und Credential-Schritte, die ich grundsätzlich nicht übernehme. **Alternativen, ehrlich bewertet:** - *Nichts tun* — die Integration bleibt auf `setup_retry`, stört sonst nichts. Völlig vertretbar. - *Images aufräumen* (6,98 GB / 53 % sind reclaimable) — verkürzt den Durchlauf, aber ob es unter das `pyportainer`-Limit kommt, ist **offen**. Ich würde nicht darauf setzen. - *ep14 ganz aus Portainer nehmen* — kostet die NAS-Verwaltung, schlechter Tausch. --- ## Schritt 3 — ioBroker: NAS-Ziel korrigieren **Wo:** ioBroker auf `10.40.20.107` (LXC 101 `iob-master`), in der betroffenen Adapter-Instanz. `10.40.41.10:8080` → **`10.40.20.10:8080`** (die NAS unter ihrer aktuellen Adresse). Das steckt in der Adapterkonfiguration, nicht in einer Datei, die ich von außen sicher ändern kann. --- ## Schritt 4 — Entscheidung: die 11 gestoppten VLAN1-LXCs Auf pve stehen 11 **gestoppte** Container mit VLAN1-Adressen und `gw=10.40.41.254` — das ist ap1s abgeschaltete Sekundär-IP, dieses Gateway existiert nicht mehr: | LXC | Name | alte IP | |---|---|---| | 103 | minarca | `.41.114` | | 104 | alpine-grafana | `.41.109` | | 109 | node-red | `.41.119` | | 115 | hms-mqtt-publisher | `.41.124` | | 120 | adguard-bf1 | `.41.116` | | 121 | adguard-bf2 | `.41.117` | | 128 | nginx-proxy-manager | `.41.123` | | 129 | caddy | `.41.118` | | 130 | pihole1 | `.41.16` | | 131 | pihole2 | `.41.131` | | 201 | openproject | `.41.120` | Solange sie stehen, stören sie nichts. **Wer einen davon startet, landet in einem VLAN ohne Gateway.** Je Container zu entscheiden: löschen, oder auf VLAN20 umziehen (`tag=20` + Adresse + `nameserver`). Nichts davon ist dringend — es soll nur nicht aus Versehen passieren. Zusätzlich tragen mehrere *laufende* VLAN20-Gäste noch `nameserver: 10.40.41.254` in der LXC-Config. Das greift erst beim nächsten Start neu, ist also eine stille Zeitbombe für später. --- ## Was ich gemacht habe ✅ (2026-08-15) 1. **pve `10.40.41.100` entfernt.** `/etc/network/interfaces`: Adresszeile raus, `iface vmbr0 inet static` → `inet manual`; Bridge-Parameter unangetastet. Angewendet per `ip addr del` **ohne** `ifreload -a`. Backup `/root/interfaces.bak-tp19-20260815-183045`. Nachher: nur noch `vmbr0.20` trägt eine IP, keine `41.0/24`-Route, **alle 9 Gäste weiter `running`**, `pvesm status` alle aktiv, SSH-Sitzung überlebt. 2. **Core `10.40.41.211` entfernt** über Nautobot GC (`routeros/tp19-core-vlan1-address-remove.rsc`), Backup `core-pre-tp19-vlan1-addr-20260815.backup`. Nachher: keine Adresse auf `bridge`, keine `.41`-Route, Mgmt über `.99.1` **und** `10.40.10.1` intakt. **Compliance 17/17 grün** — der letzte offene Drift auf dem Core ist damit weg. 3. **Prometheus bereinigt.** Der pauschale `41`→`20`-Ersatz hatte 6 Jobs auf Adressen gesetzt, die es nicht gibt. Ist-Zustand gemessen statt angenommen — **nur 2 Jobs liefern echte Metriken**: | Job | Befund | Ergebnis | |---|---|---| | `grafana` `10.40.20.109:3000` | 200, echte Metriken | ✅ aktiv | | `n8n` `10.40.20.167:5678` | 200, echte Metriken | ✅ aktiv | | `gitea` | `.20.157:3000/` gibt 200, aber `/metrics` ist in Gitea **nicht aktiviert** | stillgelegt | | `vaultwarden` | `/metrics` → **404**, exportiert nativ keine Prometheus-Metriken | stillgelegt | | `portainer` | `/api/status` → 200, liefert aber **JSON statt Prometheus-Format** | stillgelegt | | `node`, `alertmanager`, `qdrant` | Container auf der NAS **exited** | stillgelegt | | `pihole` | abgewählt (TP23 = AdGuard); `.20.23` ist ein fremder Dienst | stillgelegt | Alle acht **auskommentiert mit Begründung im File**, dazu der `alerting:`-Block (sonst bliebe ein leerer alertmanagers-Eintrag stehen, der Schärfe vortäuscht). Backup `prometheus.yml.bak-20260815`. Nach Reload: **3 aktive Ziele, alle `up`**. 🔴 **Falle für das nächste Mal — die Datei ist nicht mit dem Login-User schreibbar.** `prometheus.yml` gehört `65534:65534`; das *Verzeichnis* gehört `adm.christoph`. Ein `cat > datei` scheitert an „Permission denied", während ein `cp` daneben klappt — was leicht den Eindruck erweckt, der Schreibvorgang sei durchgegangen. **Schreiben nur per `sudo tee`, und danach per `md5sum` gegen die lokale Fassung prüfen**, nicht der Erfolgsmeldung der Shell trauen. --- ## Abnahme - pve: `ip -4 addr show vmbr0` ohne `.41`, `ip route` ohne `41.0/24`, `pct list` weiter 9× running. - Core: keine `.41`-Adresse, Mgmt über `.99.1` **und** `10.40.10.1` erreichbar. - Prometheus: `http://10.40.20.151:9090/api/v1/targets` — alle aktiven Ziele `up`, kein `10.40.41.x`. - HA: `proxmoxve` und `portainer` beide auf `loaded`. - **Der eigentliche Test:** TP5-Log-Regel kurz einschalten, 5 Minuten laufen lassen, `out:bridge` muss auf **0 Zeilen** stehen. Vorher waren das 76 % des gesamten Inter-VLAN-Verkehrs. Danach ist TP5 Etappe 1 sauber neu startbar. --- ## Nebenbefund Im HA-Log stehen 79 abgelehnte Anmeldeversuche auf `/api/websocket` von `90.146.33.177` — das ist **eure eigene öffentliche IP**, der Verkehr kommt also über den CF-Tunnel herein. Vermutlich der ha-mcp-Server mit einem alten Token vor dem Neustart. Wenn die Zahl jetzt nicht weiter steigt, war es genau das; wenn doch, lohnt ein zweiter Blick.