Doku: CARP-Verhalten, Agenten-Verbot für Router-Start/Stop.

Erfasst warum ungeplantes Start/Stop die Verbindung killt, dass beide Nodes parallel laufen müssen, und dass Agenten VM 104 niemals eigenmächtig anfassen dürfen.
2026-06-27 20:50:31 +02:00
parent 2177cd3334
commit e33b24997c
5 changed files with 77 additions and 57 deletions
@@ -1,6 +1,19 @@
 # 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).
+## ⛔ 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

@@ -9,6 +22,9 @@ VM **104** (`opnsense-fallback`) auf pve1 ist als **CARP-Backup** vorbereitet. D
 | **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 |
@@ -21,9 +37,31 @@ Weitere CARP-Gateways (VIP jeweils `.1`, physische Backup-IPs `.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)
@@ -34,19 +72,11 @@ Weitere CARP-Gateways (VIP jeweils `.1`, physische Backup-IPs `.3`):

 ### 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.
+`vmbr1` ist auf **jedem Host eine lokale, isolierte Bridge** — 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.
+- 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)

@@ -55,8 +85,6 @@ Weitere CARP-Gateways (VIP jeweils `.1`, physische Backup-IPs `.3`):
 | 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`):
@@ -64,10 +92,7 @@ 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)
+4. **opt7 (SERVICES):** `10.100.2.1` belassen

 Backup der Config vor Änderung: `/tmp/config.xml.bak-failover`

@@ -83,47 +108,36 @@ zfs umount -a -f; zpool export -f new-zroot
 qemu-nbd -d /dev/nbd1
 ```

-## Manueller Failover (kein automatischer Dry-Run)
+## Manueller Failover — nur durch Betreiber

-**Hinweis:** Failover manuell ausführen. Bei Fehlern ist ggf. physischer/serieller Zugang nötig — kein automatischer Test empfohlen.
+**Kein automatischer Test. Kein Agent-Start/Stop.**

 ### Voraussetzungen

- pve2-OPNsense gestoppt **oder** pve2 ausgefallen
- Keine parallele Instanz auf pve2 (gleiche CARP-VIPs!)
- VLAN-Trunk auf pve1 (`vmbr0`) korrekt
+- 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

-### Schritte
+### Prüfliste (Betreiber)

-1. **Primary stoppen** (falls pve2 erreichbar):
+- [ ] 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

-   ```bash
-   ssh root@192.168.10.4 "qm stop 104"
-   ```
+### Befehle (nur Betreiber, nicht Agent)

-2. **Fallback starten:**
+```bash
+# 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

-   ```bash
-   qm start 104
-   ```
-
-3. **Prüfen:**
-
-   ```bash
-   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:**
-
-   ```bash
-   qm stop 104
-   ssh root@192.168.10.4 "qm start 104"
-   ```
+# 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 erneut (siehe `03_backup_restore.md`), danach Backup-Rolle (advskew 100, IPs `.3`) wieder offline setzen.
+Bei größeren OPNsense-Änderungen auf pve2: Backup/Restore (siehe `03_backup_restore.md`), danach Backup-Rolle (advskew 100, IPs `.3`) wieder **offline** setzen.