Sieci w Proxmox — bridge, VLAN-y i SDN bez restartu hosta

19 października 2026 · 4 min czytania · Paweł Burzyński

ProxmoxSieciVLANSDN

Domyślna instalacja Proxmoksa daje jeden bridge vmbr0 i wszystkie maszyny w jednej sieci razem z hostem. Działa, dopóki nie trzeba oddzielić biura od serwerów, klienta A od klienta B albo zarządzania od ruchu produkcyjnego. Pokażę, jak zrobić to porządnie: VLAN-aware bridge na pojedynczym hoście i SDN, gdy hostów jest kilka. Każda zmiana wchodzi przez ifreload -a, bez restartu.

Punkt wyjścia: co masz teraz

cat /etc/network/interfaces
ip -br link
bridge link

Typowy wynik po instalacji z ISO: fizyczna karta eno1 bez adresu, bridge vmbr0 z adresem hosta i bridge-ports eno1. VM-y wpinają się w vmbr0 i widzą dokładnie to, co widzi port switcha. Jeśli port jest access w jednym VLAN-ie, VLAN-y po stronie Proxmoksa nic nie dadzą. Najpierw ustaw na switchu port jako trunk z listą dozwolonych VLAN-ów, dopiero potem rób resztę.

Krok 1: bridge VLAN-aware

Jeden bridge obsługujący wszystkie VLAN-y to najprostszy i najczęściej wystarczający wariant. Edytuj /etc/network/interfaces:

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet manual
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

Zwróć uwagę: vmbr0 nie ma już adresu IP. Adres zarządzania przenosimy na osobny VLAN w kroku 3. Jeśli na razie chcesz zostawić hosta tam, gdzie był, zostaw address i gateway na vmbr0 (host pozostanie w VLAN-ie natywnym portu trunk).

Zastosuj bez restartu i sprawdź, czy bridge faktycznie filtruje VLAN-y:

ifreload -a
ip -d link show vmbr0 | grep vlan_filtering
bridge vlan show

vlan_filtering 1 oznacza, że działa. Jeśli ifreload zgłosi błąd składni, nic nie zostanie zmienione, stara konfiguracja zostaje.

Krok 2: VM w konkretnym VLAN-ie

Nie trzeba tworzyć osobnego bridge na każdy VLAN. Tag ustawia się na karcie sieciowej maszyny:

# VM 100 do VLAN 20 (biuro), z firewallem Proxmoksa na porcie
qm set 100 --net0 virtio,bridge=vmbr0,tag=20,firewall=1

# kontener LXC 200 do VLAN 30 (serwery)
pct set 200 --net0 name=eth0,bridge=vmbr0,tag=30,ip=dhcp

# VM, która sama taguje ramki (np. router/firewall w VM) dostaje trunk
qm set 101 --net0 'virtio,bridge=vmbr0,trunks=10;20;30'

Bridge zdejmuje tag przed oddaniem ramki do VM, więc system gościa niczego nie wie o VLAN-ach. Zmiana tag= na działającej maszynie wymaga odpięcia i podpięcia karty (w GUI: Hardware → Network Device → Disconnect/Connect), bez restartu VM.

Weryfikacja na hoście, czy port VM ma właściwy VLAN:

bridge vlan show dev tap100i0
tcpdump -nei eno1 -c 20 vlan 20

Krok 3: zarządzanie Proxmoksem na osobnym VLAN-ie

Interfejs webowy na porcie 8006 i SSH nie powinny być w tej samej sieci co VM-y klientów. Dodaj do /etc/network/interfaces podinterfejs VLAN na bridge:

auto vmbr0.10
iface vmbr0.10 inet static
    address 10.0.10.2/24
    gateway 10.0.10.1

Przed ifreload -a upewnij się, że VLAN 10 jest dozwolony na porcie trunk i że masz dostęp do konsoli (IPMI/KVM) na wypadek pomyłki. Dobry nawyk: najpierw at, które cofnie zmianę, gdy odciąłeś sobie dostęp:

apt install -y at
cp /etc/network/interfaces /root/interfaces.ok
echo "cp /root/interfaces.ok /etc/network/interfaces && ifreload -a" | at now + 5 minutes
ifreload -a
# jeśli działa: atrm $(atq | awk '{print $1}')

W klastrze ten sam VLAN zarządzania musi istnieć na każdym węźle, bo corosync i migracje chodzą po adresach z /etc/pve/corosync.conf.

Krok 4: SDN, gdy hostów jest kilka

Przy jednym hoście VLAN-aware bridge wystarcza. W klastrze z 3 węzłami każdy nowy VLAN trzeba by dodawać w trzech plikach i pilnować spójnych nazw. Do tego jest SDN (Datacenter → SDN), od Proxmoksa 8 instalowany domyślnie. Warunek: w /etc/network/interfaces na każdym węźle ma być linia source /etc/network/interfaces.d/*.

Strefa typu VLAN oparta na vmbr0 i dwie sieci wirtualne, z linii poleceń:

pvesh create /cluster/sdn/zones --type vlan --zone zvlan --bridge vmbr0
pvesh create /cluster/sdn/vnets --vnet biuro   --zone zvlan --tag 20
pvesh create /cluster/sdn/vnets --vnet serwery --zone zvlan --tag 30
# zastosuj (to samo co przycisk Apply w GUI)
pvesh set /cluster/sdn

Po zastosowaniu na każdym węźle pojawia się bridge o nazwie VNet-u. VM podpinasz po nazwie sieci, a nie po numerze VLAN-u:

qm set 100 --net0 virtio,bridge=biuro
pvesh get /cluster/sdn/vnets --output-format yaml

Migracja takiej VM na inny węzeł nie wymaga niczego więcej: nazwa biuro istnieje wszędzie i wszędzie znaczy VLAN 20. Gdy switch między hostami nie przepuszcza VLAN-ów (np. hosty w różnych serwerowniach), zamiast strefy vlan użyj vxlan z listą adresów węzłów jako --peers. Pamiętaj wtedy o MTU: VXLAN zjada 50 bajtów, więc VM dostają MTU 1450, chyba że fizyczna sieć ma jumbo frames.

Najczęstsze pułapki

Port switcha nie jest trunkiem. Tag z VM wychodzi z karty i ginie na switchu. Objaw: VM dostaje DHCP tylko bez tag=.
Brak bridge-vids. Na niektórych wersjach ifupdown2 bez tej linii bridge przepuszcza tylko VLAN 1. Zostaw 2-4094 lub wypisz konkretne.
Dwa adresy hosta w dwóch VLAN-ach z dwiema bramami. Linux użyje jednej domyślnej trasy. Druga sieć zarządzania ma być bez gateway.
Firewall Proxmoksa włączony na porcie, ale wyłączony na datacenter. firewall=1 na karcie nic nie robi, dopóki nie włączysz go w Datacenter → Firewall → Options.

Konfigurację sieci zawsze trzymaj w gicie albo przynajmniej w kopii /root/interfaces.ok. Po zmianie VLAN-ów na switchu i w Proxmoksie zrób bridge vlan show i porównaj z oczekiwaniem. To zajmuje 10 sekund i oszczędza godzinę szukania, dlaczego jedna VM nie pinguje bramy.