docu/pve1/04_fallback_aktivierung.md

OPNsense-Fallback & CARP

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

Rollen

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

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

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

Manueller Failover (kein automatischer Dry-Run)

Hinweis: Failover manuell ausführen. Bei Fehlern ist ggf. physischer/serieller Zugang nötig — kein automatischer Test empfohlen.

Voraussetzungen

• pve2-OPNsense gestoppt oder pve2 ausgefallen
• Keine parallele Instanz auf pve2 (gleiche CARP-VIPs!)
• VLAN-Trunk auf pve1 (vmbr0) korrekt

Schritte

1. Primary stoppen (falls pve2 erreichbar):

   ssh root@192.168.10.4 "qm stop 104"
   

2. Fallback starten:

   qm start 104
   

3. Prüfen:

   qm terminal 104
   

   • 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:

   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.