jean/docu
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Doku: Migrationsplan Services-VLAN 1000 (pve1+pve2, Horus-NPM).

Browse Source 
Plan-only — Freigabe vor Umsetzung; vmbr1 durch geteiltes VLAN auf vmbr0 ersetzen.

Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
root
2026-06-28 20:18:16 +02:00
parent e5723d8772
commit 8a5da080ea
2 changed files with 298 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
migration/services-vlan-1000-pve1-pve2.md
+297
View File
@@ -0,0 +1,297 @@
# 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](../shared/switch-portplan.md) prüfen/anpassen
- [ ] **pve1** `vmbr0`: `bridge-vlan-aware yes`, VIDs 2–4094 (bereits laut [pve1/02_netzwerk.md](../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](../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](../shared/horus-opnsense-wireguard/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:
```text
# 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:
```bash
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
- [shared/infrastruktur-netzwerk.md](../shared/infrastruktur-netzwerk.md) — vmbr1-Hinweis aktualisieren
- [pve1/02_netzwerk.md](../pve1/02_netzwerk.md), [pve2/](../pve2/) — VLAN 1000
- `vmbr1` auf beiden Hosts: in Doku als „legacy / ungenutzt“ markieren
- npmplus `hassio.apollo` — bewusst lassen oder deprecaten (Apollo-Pfad)
**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](../pve1/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](../shared/infrastruktur-netzwerk.md) | VLANs, vmbr0/vmbr1 |
| [pve1/02_netzwerk.md](../pve1/02_netzwerk.md) | pve1 Bridges |
| [pve1/04_fallback_aktivierung.md](../pve1/04_fallback_aktivierung.md) | CARP, vmbr1 |
| [shared/horus-opnsense-wireguard/opnsense-step-a-nat.md](../shared/horus-opnsense-wireguard/opnsense-step-a-nat.md) | Horus ↔ OPNsense |
| [shared/opnsense-docker-subnet-routing.md](../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.