jean/docu
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f586b7adadb908a5f67076e50c917ccb4513842e
docu/migration/services-vlan-1000-pve1-pve2.md
T
root 8a5da080ea Doku: Migrationsplan Services-VLAN 1000 (pve1+pve2, Horus-NPM). 
Plan-only — Freigabe vor Umsetzung; vmbr1 durch geteiltes VLAN auf vmbr0 ersetzen.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-28 20:18:16 +02:00

11 KiB
Raw Blame History

Migrationsplan: Services-VLAN 1000 (pve1 + pve2)

Status: 📋 Plan — noch nicht umsetzen (Freigabe durch Betreiber erforderlich)
Erstellt: 2026-06-28
Ziel: Gemeinsames Services-L2 über beide Proxmox-Hosts, erreichbar von Horus-NPM ohne pro VM/Subnetz neue WireGuard-Tunnel.

Kurzfassung

Heute Ziel
L2 Services vmbr1 pro Host isoliert (kein vSwitch pve1↔pve2) VLAN 1000 auf vmbr0-Trunk, beide Hosts + Switch
Subnetz 10.100.2.0/24 (nur pve2 produktiv) Unverändert 10.100.2.0/24 (IPs bleiben)
Gateway OPNsense opt7 vtnet1 → vmbr1 → 10.100.2.1 OPNsense VLAN 1000 auf vtnet0 → 10.100.2.1
Horus-Zugang WG → OPNsense → 10.100.2.0/24 (Firewall unvollständig) Gleicher Pfad, einmalige Firewall für ganzes Subnetz
Neue VM/CT Host-abhängig / extra Routing An vmbr0, Tag 1000 — Horus-NPM forwardet direkt

VLAN-ID Vorschlag: 1000 (bewusst außerhalb des Schemas „VLAN-ID = drittes Oktett“, um Kollision mit VLAN 10/20/… zu vermeiden).

Motivation

  • Horus-NPM braucht pro Dienst nur Forward Host + Port — Engpass ist Routing/Firewall, nicht NPM.
  • Aktuell: 10.100.2.0/24 nur auf pve2-vmbr1; pve1-vmbr1 ist leer/isoliert.
  • Docker-Subnetze (z. B. VM 101 docbr0 10.2.2.0/24) brauchen eigenen VM101↔Horus-Tunnel — soll für Services entfallen.
  • Externer Zugriff über Horus (nicht npmplus pve2 / Apollo-Heim-IP).

Topologie (Ziel)

Internet
    │
Horus (10.1.1.1) — NPM :443
    │  WireGuard wg_horus
    ▼
OPNsense (pve2 VM 104)  vtnet0 + VLAN 1000  →  10.100.2.1/24
    │
    ├── physischer Switch (Trunk VLAN 1000)
    │       ├── pve2 vmbr0.1000  →  VM 106 HA, CT 101 (net1), CT 110, …
    │       └── pve1 vmbr0.1000  →  künftige Service-VMs/CTs
    │
    └── (kein vmbr1 mehr für Services)

Nicht im Scope dieses Plans: Konsolidierung von 10.2.2.0/24 (VM 101 docbr0) — separates Thema.

Betroffene Systeme (Ist)

Gast Host Heute IP
VM 106 homeassistant pve2 vmbr1 (net1) 10.100.2.12
CT 101 docker pve2 vmbr1 (net1) 10.100.2.10
CT 110 AIDEV pve2 Services-Netz 10.100.2.13
VM 104 OPNsense pve2 vtnet1 → opt7 SERVICES 10.100.2.1
VM 104 Fallback pve1 vtnet1 → opt7 (gestoppt) 10.100.2.1 (Config)
Horus NPM Horus Proxy hassio.jeanavril.com → 10.100.2.12:8123
npmplus (CT 101) pve2 hassio.apollo.jeanavril.com → 10.100.2.12 (Apollo/Heim — nicht Horus-Pfad)

Horus-WG (bereits): Peer OPNsense AllowedIPs = 10.1.1.22/32, 10.100.2.0/24 — Subnetz bleibt, keine Horus-Änderung nötig, wenn 10.100.2.0/24 erhalten bleibt.

Design-Entscheidungen (zur Freigabe)

Punkt Vorschlag Alternative
VLAN-ID 1000 z. B. 102 (näher am „100“-Subnetz-Namen)
Subnetz 10.100.2.0/24 behalten Neues Subnetz → Horus/OPNsense/DNS anpassen
Gateway 10.100.2.1 auf OPNsense VLAN 1000 —
CARP auf Services Nein (wie heute) — nur Master routet Services CARP-VIP 10.100.2.1 (mehr Aufwand, Failover-Konsistenz)
DHCP Statische IPs (Status quo) OPNsense DHCP optional
vmbr1 nach Migration Leer lassen / später entfernen —

CARP-Hinweis: Failover betrifft weiterhin nur VLANs auf vmbr0 (10, 20, …). Services-VLAN 1000 hängt am gleichen Trunk — Backup-OPNsense (pve1) braucht dieselbe VLAN-1000-Konfiguration in der synchronisierten Config, damit bei Failover Routing zu 10.100.2.0/24 weiter funktioniert (ohne CARP auf .1 reicht, wenn nur der Master aktiv Services routet und Backup identische Interface-Definition hat).

Voraussetzungen / Checks vor Start

  • Freigabe dieses Plans durch Betreiber
  • Switch: Trunk-Ports zu pve1 + pve2 erlauben VLAN 1000 (tagged) — switch-portplan.md prüfen/anpassen
  • pve1 vmbr0: bridge-vlan-aware yes, VIDs 2–4094 (bereits laut pve1/02_netzwerk.md)
  • pve2 vmbr0: VLAN-aware bestätigen
  • Wartungsfenster für HA / Frigate / npmplus (kurze Unterbrechung pro Gast)
  • ⛔ VM 104 während Migration nicht per Agent stoppen/starten — pve1/04_fallback_aktivierung.md

Phasen

Phase 0 — Dokumentation & Freigabe (jetzt)

  • Plan reviewen (dieses Dokument)
  • VLAN-ID 1000 bestätigen oder ändern
  • Switch-Portplan ergänzen

Aufwand: ~30 min
Risiko: keins

Phase 1 — OPNsense: VLAN 1000 anlegen (ohne Gäste umzuhängen)

Nur GUI, kein VM-Stop.

  1. Interfaces → Other Types → VLAN

    • Parent: vtnet0 (Trunk)
    • Tag: 1000
    • Beschreibung: SERVICES oder SERVICES-VLAN1000

  2. Interfaces → Assignments

    • Neues Interface zuweisen (z. B. opt11 oder ersetzt später opt7)
    • IPv4: 10.100.2.1/24 — erst aktivieren, wenn Phase 2 parallel läuft, sonst Konflikt mit opt7/vmbr1

  3. Firewall (VLAN-1000-Interface + wg_horus) — einmalig für ganzes Subnetz:

    Interface Source Destination Zweck
    wg_horus 10.1.1.0/24 10.100.2.0/24 Horus → Services (Hinweg)
    VLAN 1000 10.100.2.0/24 10.1.1.0/24 Services → Horus (Rückweg; ggf. durch established abgedeckt)
    VLAN 1000 10.1.1.0/24 10.100.2.0/24 falls Pakete so eintreffen
    optional LAN/VLAN10 10.100.2.0/24 Admin aus Management

  4. Kein Outbound-NAT für 10.100.2.0/24 ↔ Horus (wie opnsense-step-a-nat.md).

  5. Static Routes: 10.100.2.0/24 lokal connected — keine Extra-Route nötig.

Test (während opt7 noch aktiv): VLAN 1000 Interface disabled lassen bis Phase 2.

Aufwand: ~1–2 h
Risiko: niedrig (wenn 10.100.2.1 noch nicht auf VLAN 1000 enabled)

Phase 2 — Proxmox: VLAN-aware Bridge für Gäste

Auf pve1 und pve2 (nur Doku / Vorbereitung, keine Gäste ändern):

  • Gäste- NIC künftig: vmbr0, Tag 1000, Modell virtio
  • In Proxmox UI: Netzwerk → vmbr0 → VLAN 1000 erlaubt (bereits vlan-aware)

Optional Proxmox /etc/network/interfaces Kommentar:

# vmbr0.1000 — Services 10.100.2.0/24 (VLAN 1000), siehe migration/services-vlan-1000-pve1-pve2.md

Aufwand: ~30 min
Risiko: keins (nur Vorbereitung)

Phase 3 — Migration Gäste (pve2), einzeln mit Rollback

Reihenfolge empfohlen (niedrigste Abhängigkeit zuerst):

# Gast Aktion Downtime
1 CT 110 AIDEV net auf vmbr0, tag 1000 ~1 min
2 CT 101 docker net1 von vmbr1 → vmbr0 tag 1000; net0 (Mgmt) unverändert ~2–5 min (Frigate/npmplus)
3 VM 106 HA net1 → vmbr0 tag 1000 ~3–5 min

Pro Schritt:

  1. Gast stoppen (CT: pct stop, VM: qm shutdown)
  2. Netzwerk in Proxmox: Bridge vmbr0, VLAN Tag 1000, gleiche MAC wenn möglich
  3. OPNsense: VLAN 1000 mit 10.100.2.1 enable, opt7/vmbr1 disable (nur nach erstem erfolgreichen Gast-Test)
  4. Gast starten
  5. Tests: 
    ping 10.100.2.1
ping 10.100.2.12   # von pve2/pve1
# von Horus:
ping 10.100.2.12
curl -sI http://10.100.2.12:8123

Rollback pro Gast: Interface zurück auf vmbr1, opt7 wieder aktiv, VLAN 1000 disable.

Aufwand: ~2–4 h (inkl. Tests)
Risiko: mittel (Fehlkonfiguration = Services offline)

Phase 4 — OPNsense aufräumen

  • opt7 (vtnet1 / vmbr1) deaktivieren oder entfernen
  • pve2 VM 104: net1 (vtnet1) optional abkoppeln (nur nach stabiler Phase 3)
  • Config-Sync zu pve1-Fallback prüfen (VLAN 1000 in Backup-Config)
  • Horus-Test: https://hassio.jeanavril.com (NPM → 10.100.2.12:8123)

Aufwand: ~1 h
Risiko: niedrig

Phase 5 — pve1 produktiv nutzen

  • Erste Test-CT/VM auf pve1: vmbr0, tag 1000, statische IP aus 10.100.2.0/24
  • Horus-NPM: neuer Proxy-Host → 10.100.2.x:port
  • Kein zusätzlicher WG-Tunnel nötig

Aufwand: ~30 min pro erstem Dienst
Risiko: niedrig

Phase 6 — Doku & Optional Cleanup

Aufwand: ~1 h
Risiko: keins

Horus & NPM (nach Migration)

Komponente Änderung nötig?
Horus WG Peer OPNsense AllowedIPs Nein (Subnetz bleibt 10.100.2.0/24)
Horus wg0-opnsense-routes.sh Nein
Horus NPM Proxy-Hosts Nein für bestehende IPs; neue Dienste nur NPM-Eintrag
Home Assistant trusted_proxies 10.1.1.1 (+ ggf. Horus-NPM-IP) — siehe Betrieb Horus
DNS *.jeanavril.com unverändert (Horus)

Gesamtaufwand (Schätzung)

Phase Aufwand Downtime
0 Freigabe 0,5 h —
1 OPNsense VLAN 1–2 h keins
2 Proxmox Vorbereitung 0,5 h keins
3 Gäste migrieren 2–4 h ~10–15 min gesamt (gestaffelt)
4 OPNsense Cleanup 1 h optional kurz
5 pve1 erster Gast 0,5 h minimal
6 Doku 1 h —
Summe ~1–2 Arbeitstage (inkl. Puffer/Tests) gestaffelt

Risiken & Mitigation

Risiko Mitigation
Switch trunk ohne VLAN 1000 Phase 0 Switch prüfen
Doppel-IP 10.100.2.1 (opt7 + VLAN1000) VLAN 1000 erst enable, wenn erster Gast umgehängt
CARP/Failover Services Backup-OPNsense Config sync; Failover-Test nur manuell
HA/WebSockets über Horus-NPM trusted_proxies, NPM WebSockets (bereits an für hassio)
VM 104 durch Agent gestoppt ⛔ Regel in 04_fallback_aktivierung.md

Abnahme-Checkliste (nach Umsetzung)

  • Von pve1 und pve2: ping 10.100.2.12
  • Von Horus: ping 10.100.2.12, curl http://10.100.2.12:8123
  • hassio.jeanavril.com über Horus-NPM (extern ohne VPN)
  • Frigate / npmplus intern (10.100.2.10) ok
  • Neue Test-VM auf pve1 VLAN 1000 erreichbar von Horus
  • OPNsense: opt7/vmbr1 deaktiviert, VLAN 1000 produktiv
  • Doku aktualisiert

Referenzen

Dokument Inhalt
shared/infrastruktur-netzwerk.md VLANs, vmbr0/vmbr1
pve1/02_netzwerk.md pve1 Bridges
pve1/04_fallback_aktivierung.md CARP, vmbr1
shared/horus-opnsense-wireguard/opnsense-step-a-nat.md Horus ↔ OPNsense
shared/opnsense-docker-subnet-routing.md Analog für Docker-Subnetze (VM 101)

Offene Punkte zur Freigabe

  1. VLAN-ID 1000 — bestätigen?
  2. Subnetz 10.100.2.0/24 beibehalten — ok?
  3. CARP auf 10.100.2.1 — bewusst nein?
  4. Switch-Ports — wer trägt VLAN 1000 ein (Aruba)?
  5. Wartungsfenster für Phase 3 (HA/Frigate)?

Nach Freigabe: Phase 1 starten — nicht vorher Gäste umhängen.

Reference in New Issue View Git Blame Copy Permalink