diff --git a/pve1/02_netzwerk.md b/pve1/02_netzwerk.md index 7290ba9..9f4cf02 100644 --- a/pve1/02_netzwerk.md +++ b/pve1/02_netzwerk.md @@ -4,10 +4,26 @@ | Bridge | Typ | Verwendung | |--------|-----|------------| -| vmbr0 | VLAN-aware, an `nic0` | WAN / Management (192.168.10.3/24) | -| vmbr1 | Intern, keine phys. Ports | LAN-Seite des Routers | +| vmbr0 | VLAN-aware, an `nic0` | WAN / VLAN-Trunk (192.168.10.3/24 Management des Hosts) | +| vmbr1 | Intern, keine phys. Ports | Host-lokales Service-Netz (OPNsense `net1`) | -`vmbr1` wurde für die Fallback-VM angelegt (analog zu pve2): +### vmbr0 + +``` +auto vmbr0 +iface vmbr0 inet static + address 192.168.10.3/24 + gateway 192.168.10.1 + bridge-ports nic0 + bridge-stp off + bridge-fd 0 + bridge-vlan-aware yes + bridge-vids 2-4094 +``` + +Trunk für OPNsense-Fallback: alle VLANs getagged auf `vtnet0` (analog pve2). + +### vmbr1 ``` auto vmbr1 @@ -17,15 +33,24 @@ iface vmbr1 inet manual bridge-fd 0 ``` +**Wichtig:** `vmbr1` ist **nur auf pve1 lokal** — kein vSwitch, keine Verbindung zu pve2-vmbr1. Siehe [04_fallback_aktivierung.md](04_fallback_aktivierung.md#vmbr1--services-nicht-teil-von-carp). + +| Netz | Subnetz | Gateway (OPNsense opt7) | CARP | +|------|---------|-------------------------|------| +| Services | 10.100.2.0/24 | 10.100.2.1 | nein | + +Auf pve1 hängt aktuell nur OPNsense-Fallback `net1` an vmbr1. Dienste auf pve2 (Docker, HA) nutzen **deren eigenes** vmbr1. + ## OPNsense-Fallback (VM 104) -| Interface | Bridge | MAC | -|-----------|--------|-----| -| net0 | vmbr0 | BC:24:11:A1:B2:C3 | -| net1 | vmbr1 | BC:24:11:D4:E5:F6 | +| Proxmox | OPNsense | Bridge | MAC | +|---------|----------|--------|-----| +| net0 | vtnet0 | vmbr0 | BC:24:11:A1:B2:C3 | +| net1 | vtnet1 (opt7 SERVICES) | vmbr1 | BC:24:11:D4:E5:F6 | -MAC-Adressen wurden absichtlich von pve2 abweichend gesetzt, um Konflikte zu vermeiden. +MAC-Adressen absichtlich von pve2 abweichend. -## Hinweis +## Hinweise -pve1 hat nur **eine physische NIC**. Beim Failover ggf. Kabel umstecken oder VLAN-Konfiguration prüfen. +- pve1 hat nur **eine physische NIC** — Failover über VLAN-Trunk auf vmbr0 +- CARP-Failover betrifft **nur** die VLAN-Netze auf vmbr0, nicht vmbr1 diff --git a/pve1/04_fallback_aktivierung.md b/pve1/04_fallback_aktivierung.md index e0f1528..69a4516 100644 --- a/pve1/04_fallback_aktivierung.md +++ b/pve1/04_fallback_aktivierung.md @@ -1,47 +1,129 @@ -# Fallback aktivieren +# OPNsense-Fallback & CARP -## Voraussetzungen +VM **104** (`opnsense-fallback`) auf pve1 ist als **CARP-Backup** vorbereitet. Die Config wurde **offline** auf der Disk angepasst (ZFS-Pool gemountet, VM nicht gestartet). -- pve2-OPNsense ist gestoppt oder pve2 ist ausgefallen -- Netzwerk-Kabel/VLANs sind für pve1 vorbereitet +## Rollen -## Schritte +| Rolle | Host | VM | Mgmt-IP (phys.) | CARP VIP | advskew | +|-------|------|-----|-----------------|----------|---------| +| **Master** | pve2 | 104 `opnsense` | 192.168.10.2 | 192.168.10.1 | 0 | +| **Backup** | pve1 | 104 `opnsense-fallback` | 192.168.10.3 | 192.168.10.1 | 100 | -### 1. Original stoppen (falls noch erreichbar) +Weitere CARP-Gateways (VIP jeweils `.1`, physische Backup-IPs `.3`): + +| Netz | VLAN | CARP VIP | Backup-IP | +|------|------|----------|-----------| +| Management | 10 | 192.168.10.1 | 192.168.10.3 | +| Privat | 20 | 192.168.20.1 | 192.168.20.3 | +| Gäste | 30 | 192.168.30.1 | 192.168.30.3 | +| IoT | 40 | 192.168.40.1 | 192.168.40.3 | +| IPCAM | 50 | 192.168.50.1 | 192.168.50.3 | +| VoIP | 60 | 192.168.60.1 | 192.168.60.3 | + +- **CARP-VHIDs:** 10, 20, 30, 40, 50, 60 (identisch auf beiden Nodes) +- **pfsync/XMLRPC:** Primary-Peer `192.168.10.2`, Backup-Peer `192.168.10.3` +- **Hostname Backup:** `OPNsense-Fallback` + +## Was beim Failover zählt — und was nicht + +### vmbr0 + VLAN-Trunk (relevant) + +- OPNsense `vtnet0` → Proxmox `vmbr0` (VLAN-aware, alle VLANs getagged) +- CARP übernimmt die `.1`-Gateways im gesamten VLAN-Netz +- Das ist der **eigentliche Failover-Pfad** + +### vmbr1 / Services (nicht Teil von CARP) + +`vmbr1` ist auf **jedem Host eine lokale, isolierte Bridge** ohne physischen Port — **kein vSwitch**, kein geteiltes L2 zwischen pve1 und pve2. + +| Host | vmbr1 | Anbindung | +|------|-------|-----------| +| pve2 | lokal | OPNsense `net1`, Docker CT 101, Home Assistant VM 106, … | +| pve1 | lokal | nur OPNsense-Fallback `net1` (keine weiteren Gäste) | + +- OPNsense-Interface **opt7 (SERVICES)** → `vtnet1` → `vmbr1` +- IP auf **beiden** Router-Instanzen: **`10.100.2.1/24`** (Gateway-Rolle, Endung `.1`) +- **Kein CARP** auf `10.100.2.0/24` — bewusst ausgenommen +- Interface bleibt **aktiv**, wird aber **nicht deaktiviert** + +**Konsequenz:** Docker/HA auf pve2 (`10.100.2.10` → Gateway `10.100.2.1`) erreichen beim Router-Failover auf pve1 **nicht** automatisch den Fallback-Router — pve2-vmbr1 und pve1-vmbr1 sind getrennte Netze. Diese Dienste laufen im Failover-Fall weiter über **192.168.10.x** (Management/VLAN 10), solange der VLAN-Trunk erreichbar ist. + +## VM-Netzwerk pve1 (104) + +| Proxmox | OPNsense | Bridge | MAC | +|---------|----------|--------|-----| +| net0 | vtnet0 (VLAN-Trunk) | vmbr0 | BC:24:11:A1:B2:C3 | +| net1 | vtnet1 (SERVICES) | vmbr1 | BC:24:11:D4:E5:F6 | + +MACs bewusst **abweichend** von pve2, um Konflikte zu vermeiden wenn nur eine Instanz läuft. + +## Offline-Vorbereitung (bereits erledigt) + +Config-Änderungen direkt auf `/dev/pve/vm-104-disk-0` (ZFS `zroot`): + +1. Physische VLAN-IPs von `.2` → `.3` (Backup) +2. CARP `advskew` von `0` → `100` +3. HA-Peer auf Primary `192.168.10.2` zeigen lassen +4. **opt7 (SERVICES):** `10.100.2.1` belassen (kein CARP, kein `.2`/`.3`-Schema) + +Referenz altes apollo-Image: `/mnt/nvme1/libvirt/images/router.qcow2` +(dort advskew=100, aber VLAN-Zuordnung damals über `vlan05` statt `lan`/`vtnet0` — **nicht** übernommen) + +Backup der Config vor Änderung: `/tmp/config.xml.bak-failover` + +### Config erneut offline bearbeiten ```bash -ssh root@192.168.10.4 "qm stop 104" +modprobe nbd max_part=8 +qemu-nbd --connect=/dev/nbd1 /dev/pve/vm-104-disk-0 --format=raw +zpool import -f -R /mnt/opnsense-new -d /dev/nbd1p4 15187354659129106435 new-zroot +zfs mount new-zroot/ROOT/default +# /mnt/opnsense-new/conf/config.xml bearbeiten +zfs umount -a -f; zpool export -f new-zroot +qemu-nbd -d /dev/nbd1 ``` -### 2. Fallback starten +## Manueller Failover (kein automatischer Dry-Run) -```bash -qm start 104 -``` +**Hinweis:** Failover manuell ausführen. Bei Fehlern ist ggf. physischer/serieller Zugang nötig — kein automatischer Test empfohlen. -### 3. Konsole prüfen +### Voraussetzungen -```bash -qm terminal 104 -``` +- pve2-OPNsense gestoppt **oder** pve2 ausgefallen +- Keine parallele Instanz auf pve2 (gleiche CARP-VIPs!) +- VLAN-Trunk auf pve1 (`vmbr0`) korrekt -### 4. Netzwerk testen +### Schritte -- Web-UI von OPNsense aufrufen (Standard: LAN-Interface) -- Gateway/DHCP/DNS prüfen +1. **Primary stoppen** (falls pve2 erreichbar): -## Fallback beenden + ```bash + ssh root@192.168.10.4 "qm stop 104" + ``` -```bash -qm stop 104 -``` +2. **Fallback starten:** -Danach Original auf pve2 wieder starten: + ```bash + qm start 104 + ``` -```bash -ssh root@192.168.10.4 "qm start 104" -``` +3. **Prüfen:** -## Aktualisierung der Fallback-Kopie + ```bash + qm terminal 104 + ``` -Bei größeren OPNsense-Änderungen Backup/Restore erneut durchführen (siehe `03_backup_restore.md`). + - CARP-VIPs erreichbar: `192.168.10.1`, `192.168.20.1`, … + - Web-UI über Management-VIP + - **Nicht** erwarten, dass pve2-Dienste über `10.100.2.1` erreichbar sind + +4. **Zurück zum Normalbetrieb:** + + ```bash + qm stop 104 + ssh root@192.168.10.4 "qm start 104" + ``` + +## Fallback-Kopie aktualisieren + +Bei größeren OPNsense-Änderungen auf pve2: Backup/Restore erneut (siehe `03_backup_restore.md`), danach Backup-Rolle (advskew 100, IPs `.3`) wieder offline setzen. diff --git a/shared/infrastruktur-netzwerk.md b/shared/infrastruktur-netzwerk.md index 36732d4..011097d 100644 --- a/shared/infrastruktur-netzwerk.md +++ b/shared/infrastruktur-netzwerk.md @@ -22,15 +22,15 @@ Schema: VLAN-ID oft = drittes Oktett (`192.168.40.0/24` = VLAN 40) | Bridge | Anbindung | Zweck | |--------|-----------|-------| -| vmbr0 | nic0, VLAN-aware | WAN / Management | -| vmbr1 | keine phys. Ports | LAN-Seite OPNsense-Fallback | +| vmbr0 | nic0, VLAN-aware | WAN / VLAN-Trunk, CARP-Failover | +| vmbr1 | keine phys. Ports | Host-lokal, OPNsense SERVICES (10.100.2.0/24) — **nicht** mit pve2 geteilt | ## pve2 — Bridges | Bridge | Zweck | |--------|-------| | vmbr0 | VLAN-aware, VMs/CTs Management | -| vmbr1 | Intern (OPNsense LAN, CT-Netze) | +| vmbr1 | Host-lokal: OPNsense SERVICES, Docker CT 101, HA VM 106 — **nicht** mit pve1 geteilt | Details CT/VM-Netze: siehe Host-Doku unter `pve1/` bzw. `pve2/`. @@ -41,4 +41,4 @@ Details CT/VM-Netze: siehe Host-Doku unter `pve1/` bzw. `pve2/`. ## Failover-Hinweis -OPNsense-Fallback auf pve1 (VM 104) und Original auf pve2 **dürfen nicht parallel** laufen — gleiche IPs/Konfiguration. Siehe [pve1/04_fallback_aktivierung.md](../pve1/04_fallback_aktivierung.md). +OPNsense-Fallback auf pve1 (VM 104) und Original auf pve2 **dürfen nicht parallel** laufen — gleiche CARP-VIPs. Failover betrifft **vmbr0/VLAN/CARP**, nicht das host-lokale Service-Netz `10.100.2.0/24` auf vmbr1. Siehe [pve1/04_fallback_aktivierung.md](../pve1/04_fallback_aktivierung.md).