Част 5: Мрежа — Bridges, VLANs и Bonding | Федя Серафиев

Bridge е виртуален switch, не рутер. vmbrX в Proxmox е Linux bridge — свързва физическа мрежова карта с виртуалните интерфейси на VMs и LXC контейнери на ниво layer 2, точно както физически switch би свързал устройства.

1. vmbr0 — bridge-ът, който вече имам от инсталацията

При инсталация (Част 2), инсталаторът автоматично създава vmbr0, свързан с основната физическа мрежова карта. Всяка VM или LXC, която добавям с bridge=vmbr0, се включва към същия виртуален switch — виждат се взаимно на layer 2, точно както устройства на един физически switch.

/etc/network/interfaces

auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

Важна подробност: Proxmox не записва промени директно в /etc/network/interfaces. Записва ги в /etc/network/interfaces.new и ги прилага при натискане на Apply Configuration в UI, или веднага през CLI с ifupdown2 — без задължителен reboot. Пазя си локален console/IPMI достъп, преди да пипам management интерфейса, защото грешна конфигурация може да остави host-а недостъпен по мрежа.

2. VLAN-aware bridge — сегментация без десетки vmbr интерфейси

Вместо да създавам отделен vmbrX за всяка VLAN, правя vmbr0 VLAN-aware — той пренася множество VLAN-и през един и същ физически uplink, а тагирането се случва на ниво VM/LXC мрежов интерфейс.

/etc/network/interfaces — VLAN-aware bridge

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

След това, конкретна VLAN за конкретна VM се задава директно в мрежовия ѝ интерфейс — не се нуждае от отделен bridge:

ПРИМЕР — VM В VLAN 20

qm set 101 --net0 virtio,bridge=vmbr0,tag=20

За LXC контейнер аналогично:

ПРИМЕР — LXC В VLAN 20

pct set 200 --net0 name=eth0,bridge=vmbr0,tag=20,ip=dhcp

Физическият switch трябва да носи същите VLAN-и по trunk порта към Proxmox host-а. Ако тагирам VM в VLAN 20, а switch портът не пропуска VLAN 20 като trunk, трафикът просто изчезва — не получавам грешка, получавам мълчание, което е по-трудно за диагностика.

3. Практическа сегментация — как я подреждам аз

VLAN 1 (untagged) — Management
Proxmox host IP, Web UI достъп

VLAN 20 — VMs / Services
работни VMs и LXC контейнери

VLAN 30 — Storage
NFS/iSCSI трафик, изолиран от общата мрежа

Не е задължително да имам физически отделни мрежови карти за всяка VLAN — с VLAN-aware bridge трафикът се разделя логически през същия физически uplink. Отделни физически интерфейси имат смисъл само когато искам реална пропускателна изолация, не само broadcast domain разделяне.

4. Bonding — редундантност или пропускателна способност

Bond комбинира два или повече физически интерфейса в едно логическо устройство. Изборът на режим зависи основно от възможностите на switch-а насреща:

Bond режим	Кога го използвам
`active-backup`	Switch без поддръжка на link aggregation. Единствен активен интерфейс, вторият поема при отказ на първия. Само redundancy, не добавя throughput.
`802.3ad` (LACP)	Switch с LACP поддръжка, конфигуриран за същия port-channel. И redundancy, и увеличен агрегиран throughput.

/etc/network/interfaces — BOND С LACP

auto bond0
iface bond0 inet manual
    bond-slaves eno1 eno2
    bond-miimon 100
    bond-mode 802.3ad
    bond-xmit-hash-policy layer2+3

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

LACP изисква конфигурация от двете страни. Ако включа 802.3ad на host-а, но switch портовете не са конфигурирани в port-channel, връзката най-често изобщо не тръгва, вместо тихо да деградира до единичен линк. Ако не съм сигурен в switch конфигурацията, active-backup е по-безопасната отправна точка.

5. Кратко за вградения firewall

Proxmox има вграден firewall на три нива — Datacenter, Node и VM/LXC — реализиран върху iptables/nftables отдолу. Не навлизам в детайли тук, защото темата заслужава собствено внимание, но правилото, което пазя във всеки случай: firewall правилата се тестват от конзолен/IPMI достъп, не само през Web UI — грешно правило на ниво Datacenter може да отреже собствения ми достъп до самия UI.

6. Типични грешки

Промяна на management мрежовата конфигурация без наличен console/IPMI достъп „за всеки случай“.
Тагиране на VM в VLAN, който switch trunk портът не пропуска — трафик изчезва без ясна грешка.
Включване на LACP bond без съответна конфигурация от страна на switch-а.
Смесване на storage трафик и обикновен VM трафик на една и съща необременена мрежа при по-натоварени сценарии.
Забравяне на bridge-vlan-aware yes при опит да се използва tag= на VM интерфейс — тагирането просто не се прилага.

7. Най-важното от тази част

vmbrX е Linux bridge — виртуален switch, свързващ физическа карта с VMs/LXC.
VLAN-aware bridge (bridge-vlan-aware yes + bridge-vids) сегментира трафика без нужда от отделен bridge за всяка VLAN.
VLAN на конкретна VM/LXC се задава с tag= директно на мрежовия интерфейс.
active-backup за redundancy без switch поддръжка, 802.3ad/LACP за redundancy + throughput с поддържащ switch.
Proxmox прилага мрежови промени през ifupdown2 без reboot, но записва първо в interfaces.new — пазя си локален достъп при промяна на management интерфейса.

Заключение

Мрежата е слоят, който повечето хора конфигурират веднъж при инсталация и после забравят — докато не потрябва да изолират storage трафик, да добавят нова VLAN за гости, или да си позволят отказ на един мрежов кабел без downtime. VLAN-aware bridge и bonding не са екзотични функции — те са разликата между „работи, докато не се счупи нещо“ и мрежа, която очаквано се държи и при проблем.

В следващата част минавам към backup и Proxmox Backup Server — retention политики, как реално тествам restore (не само правя backup), и защо backup, който никога не е бил тестван за възстановяване, на практика не е backup.