jean/docu
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Dokumentiere OPNsense-CARP-Failover und vmbr1-Grenzen.

Browse Source 
Erfasst die offline vorbereitete Backup-Rolle auf pve1, den manuellen Failover-Ablauf und dass vmbr1/Services host-lokal ist und nicht Teil von CARP.
This commit is contained in:
root
2026-06-27 20:32:41 +02:00
parent 9a6e966ce3
commit 2177cd3334
3 changed files with 149 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files
pve1/02_netzwerk.md
+35 -10
View File
@@ -4,10 +4,26 @@
| Bridge | Typ | Verwendung | | Bridge | Typ | Verwendung |
|--------|-----|------------| |--------|-----|------------|
| vmbr0 | VLAN-aware, an `nic0` | WAN / Management (192.168.10.3/24) | | vmbr0 | VLAN-aware, an `nic0` | WAN / VLAN-Trunk (192.168.10.3/24 Management des Hosts) |
| vmbr1 | Intern, keine phys. Ports | LAN-Seite des Routers | | 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 auto vmbr1
@@ -17,15 +33,24 @@ iface vmbr1 inet manual
bridge-fd 0 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) ## OPNsense-Fallback (VM 104)
| Interface | Bridge | MAC | | Proxmox | OPNsense | Bridge | MAC |
|-----------|--------|-----| |---------|----------|--------|-----|
| net0 | vmbr0 | BC:24:11:A1:B2:C3 | | net0 | vtnet0 | vmbr0 | BC:24:11:A1:B2:C3 |
| net1 | vmbr1 | BC:24:11:D4:E5:F6 | | 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
pve1/04_fallback_aktivierung.md
+102 -20
View File
@@ -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 ## Rollen
- Netzwerk-Kabel/VLANs sind für pve1 vorbereitet
## 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
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):
```bash ```bash
ssh root@192.168.10.4 "qm stop 104" ssh root@192.168.10.4 "qm stop 104"
``` ```
### 2. Fallback starten 2. **Fallback starten:**
```bash ```bash
qm start 104 qm start 104
``` ```
### 3. Konsole prüfen 3. **Prüfen:**
```bash ```bash
qm terminal 104 qm terminal 104
``` ```
### 4. Netzwerk testen - 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
- Web-UI von OPNsense aufrufen (Standard: LAN-Interface) 4. **Zurück zum Normalbetrieb:**
- Gateway/DHCP/DNS prüfen
## Fallback beenden
```bash ```bash
qm stop 104 qm stop 104
```
Danach Original auf pve2 wieder starten:
```bash
ssh root@192.168.10.4 "qm start 104" ssh root@192.168.10.4 "qm start 104"
``` ```
## Aktualisierung der Fallback-Kopie ## Fallback-Kopie aktualisieren
Bei größeren OPNsense-Änderungen Backup/Restore erneut durchführen (siehe `03_backup_restore.md`). 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.
shared/infrastruktur-netzwerk.md
+4 -4
View File
@@ -22,15 +22,15 @@ Schema: VLAN-ID oft = drittes Oktett (`192.168.40.0/24` = VLAN 40)
| Bridge | Anbindung | Zweck | | Bridge | Anbindung | Zweck |
|--------|-----------|-------| |--------|-----------|-------|
| vmbr0 | nic0, VLAN-aware | WAN / Management | | vmbr0 | nic0, VLAN-aware | WAN / VLAN-Trunk, CARP-Failover |
| vmbr1 | keine phys. Ports | LAN-Seite OPNsense-Fallback | | vmbr1 | keine phys. Ports | Host-lokal, OPNsense SERVICES (10.100.2.0/24) — **nicht** mit pve2 geteilt |
## pve2 — Bridges ## pve2 — Bridges
| Bridge | Zweck | | Bridge | Zweck |
|--------|-------| |--------|-------|
| vmbr0 | VLAN-aware, VMs/CTs Management | | 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/`. 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 ## 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).