docu/migration/services-vlan-1000-pve1-pve2.md

# 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.