Dokumentiere OPNsense-CARP-Failover und vmbr1-Grenzen.

Erfasst die offline vorbereitete Backup-Rolle auf pve1, den manuellen Failover-Ablauf und dass vmbr1/Services host-lokal ist und nicht Teil von CARP.
2026-06-27 20:32:41 +02:00
parent 9a6e966ce3
commit 2177cd3334
3 changed files with 149 additions and 42 deletions
@@ -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.