docu/pve1/04_fallback_aktivierung.md

OPNsense-Fallback & CARP

⛔ Regeln für Agenten / KI — STRIKT

NIEMALS eigenmächtig VM 104 (OPNsense) auf pve1 oder pve2 starten, stoppen, neustarten oder suspenden.

• Kein qm start 104, kein qm stop 104, kein qm reboot 104, kein qm shutdown 104
• Nur der Betreiber führt Router-Start/Stop aus — explizit, manuell, bewusst
• Agenten dürfen: Doku schreiben, Config offline auf Disk bearbeiten (wenn beauftragt), beraten
• Agenten dürfen nicht: Router zur „Prüfung“, zum „Testen“ oder „weil es so aussieht“ anfassen

Hintergrund: CARP-Gateway ist 192.168.10.1. Jeder ungeplante Start/Stop kann VIPs flappen → gesamtes Netz/internet weg. Das ist bereits passiert (2026-06-27).

---

VM 104 (opnsense-fallback) auf pve1 ist als CARP-Backup vorbereitet. Die Config wurde offline auf der Disk angepasst (ZFS-Pool gemountet).

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

• advbase: 1 (beide)
• Regel: niedrigerer advskew = höhere Priorität → Master (0) hält VIPs, solange 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)
• CARP-Passwort: identisch auf beiden Nodes
• pfsync/XMLRPC: Primary-Peer 192.168.10.2, Backup-Peer 192.168.10.3
• Hostname Backup: OPNsense-Fallback

Beide Router laufen parallel

Bei CARP müssen Master (pve2) und Backup (pve1) gleichzeitig laufen. CARP regelt, wer die .1-VIPs hält — nicht Start/Stop als Normalbetrieb.

Warum ungeplanter Start/Stop die Verbindung killt

Das Gateway im gesamten Netz ist die CARP-VIP 192.168.10.1 (und analog .1 in anderen VLANs) — keine feste physische IP.

Beim Start oder Stop eines Router-Knotens passiert:

1. CARP-Neuverhandlung — wer hält .1?
2. VIP flapped — kurz weg, doppelt, oder falsche MAC
3. Clients verlieren Gateway → Internet/Management weg

Besonders kritisch:

• Start + Stop hintereinander = zwei CARP-Transitions → doppelter Ausfall
• Backup hört Master nicht (kein sauberes L2 auf dem VLAN-Trunk zwischen pve1 und pve2): Backup denkt „kein Master“, übernimmt .1 trotz advskew 100 → Split-Brain mit laufendem Master → ARP-Chaos

advskew 0/100 schützt nur, wenn beide Nodes sich gegenseitig am Trunk sehen.

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 — kein vSwitch, kein geteiltes L2 zwischen pve1 und pve2.

• OPNsense opt7 (SERVICES) → vtnet1 → vmbr1
• IP auf beiden Router-Instanzen: 10.100.2.1/24
• Kein CARP auf 10.100.2.0/24

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

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

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 — nur durch Betreiber

Kein automatischer Test. Kein Agent-Start/Stop.

Voraussetzungen

• Beide Nodes normalerweise parallel im CARP-Betrieb
• Echter Failover-Test: bewusst geplant, physischer Zugang als Fallback
• VLAN-Trunk: pve1 und pve2 müssen sich CARP-seitig am Trunk sehen

Prüfliste (Betreiber)

• pve2 Master läuft, VIP .1 antwortet
• pve1 Backup läuft parallel, hält keine VIPs (skew 100)
• pve1 pingt 192.168.10.2, pve2 pingt 192.168.10.3
• Erst bei geplantem Test: Master stoppen → Backup übernimmt VIPs

Befehle (nur Betreiber, nicht Agent)

# Failover-Test (Beispiel — nur manuell!)
ssh root@192.168.10.4 "qm stop 104"   # Master stoppen
# Backup auf pve1 sollte VIPs übernehmen
qm terminal 104                        # Konsole prüfen

# Zurück
qm stop 104                            # Backup stoppen
ssh root@192.168.10.4 "qm start 104"  # Master wieder

Fallback-Kopie aktualisieren

Bei größeren OPNsense-Änderungen auf pve2: Backup/Restore (siehe 03_backup_restore.md), danach Backup-Rolle (advskew 100, IPs .3) wieder offline setzen.