Sieci VLAN w Proxmox: izolacja i segmentacja ruchu

// Spis treści

Jeden kabel, wiele odseparowanych sieci
Tagowanie na mostku, nie na podinterfejsach
Mostek VLAN-aware krok po kroku
Reguły VLAN na switchu Cumulus Linux
O czym pamiętać

// 01 · Jak to działa

Jeden kabel, wiele odseparowanych sieci

VLAN dokłada do ramki ethernetowej 4-bajtowy znacznik 802.1Q z numerem (VLAN ID, 1–4094). Switche i hosty traktują ruch z różnymi tagami tak, jakby płynął przez fizycznie oddzielne sieci — urządzenia w VLAN 10 nie widzą bezpośrednio urządzeń w VLAN 20, nawet jeśli dzielą ten sam przełącznik i ten sam kabel uplink.

Port, który przenosi wiele otagowanych VLAN-ów naraz (np. uplink z hosta Proxmox do switcha), nazywamy trunkiem. Port przypisany na stałe do jednego VLAN-u, oddający ruch nieotagowany do urządzenia końcowego, to port access. Ruch bez znacznika trafia do tzw. native VLAN (PVID) danego portu.

ℹ️

VLAN to separacja w warstwie 2. Aby segmenty mogły się ze sobą komunikować, ruch musi przejść przez router lub firewall (warstwa 3) — to naturalne miejsce na reguły i kontrolę dostępu między strefami.

// 02 · Model VLAN-aware bridge

Tagowanie na mostku, nie na podinterfejsach

Proxmox oferuje dwa podejścia do VLAN-ów. Zalecane i najprostsze w utrzymaniu to VLAN-aware bridge: jeden mostek vmbr0 z włączoną obsługą VLAN obejmuje wszystkie segmenty, a numer VLAN-u przypisujesz per maszyna w konfiguracji karty sieciowej.

VLAN-aware bridge: jeden mostek dla wszystkich VLAN-ów, tag ustawiany w polu „VLAN Tag” karty VM/kontenera. Czyste, skalowalne, łatwe do audytu.
Tradycyjne podinterfejsy: osobne interfejsy eno1.10, eno1.20 i osobne mostki na każdy VLAN. Działa, ale szybko mnoży konfigurację.
Czego unikać: tagowanie wewnątrz gościa przy jednoczesnym tagowaniu na hoście — podwójne znaczniki (QinQ) wprowadzane przez pomyłkę to klasyczne źródło „sieci, która nie działa”.

Po stronie switcha port do hosta musi być trunkiem przepuszczającym wszystkie używane VLAN ID. To najczęstszy punkt, w którym konfiguracja się rozjeżdża: host taguje poprawnie, ale switch odrzuca nieznane VLAN-y.

// 03 · Konfiguracja w praktyce

Mostek VLAN-aware krok po kroku

VLAN-aware bridge włączysz w panelu (Node → System → Network → wybierz vmbr0 → „VLAN aware”) lub bezpośrednio w pliku /etc/network/interfaces:

Element	Konfiguracja
Mostek VLAN-aware	`bridge-vlan-aware yes` + `bridge-vids 2-4094`
VLAN dla VM	Hardware → Network Device → VLAN Tag = np. 10
VLAN dla kontenera LXC	Network → VLAN Tag w konfiguracji interfejsu
Adres zarządzania w VLAN	podinterfejs `vmbr0.99` z adresem IP hosta
Sprawdzenie tagów	`bridge vlan show`

Dla redundancji łącza uplink łączymy w bond (LACP 802.3ad), a VLAN-aware bridge stawiamy na bondzie zamiast na pojedynczej karcie — uzyskujesz jednocześnie odporność na awarię łącza i pełną segmentację VLAN.

💡

Trzymaj sieć zarządzania Proxmox w osobnym VLAN-ie niż ruch maszyn produkcyjnych. To prosta zmiana, która znacząco ogranicza powierzchnię ataku na interfejs hosta i klaster.

// 04 · Switch NVIDIA SN4700 (Cumulus Linux)

Reguły VLAN na switchu Cumulus Linux

Switch NVIDIA SN4700 (Spectrum-3, 32 porty 400 GbE) domyślnie przychodzi z systemem Cumulus Linux. To korzystny scenariusz: Cumulus używa dokładnie tego samego modelu VLAN-aware bridge co Proxmox, więc obie strony trunku konfigurujesz bliźniaczo. W wydaniach 5.x standardem jest CLI NVUE (nv set); starsze wersje korzystały z NCLU (net add), a pod spodem zawsze pracuje ifupdown2 z plikiem /etc/network/interfaces — tym samym, co w Proxmox.

Załóżmy typowy podział: port swp1 prowadzi do hosta Proxmox i ma być trunkiem przenoszącym VLAN 10 (produkcja), 20 (storage), 30 (DMZ) i 99 (zarządzanie), a porty swp10–swp12 to porty access dla stojącego obok fizycznego serwera storage (blaszaka) w VLAN 20. Dzięki temu maszyny wirtualne na Proxmoxie i fizyczny storage są w tej samej sieci L2 (VLAN 20) i widzą się bezpośrednio — bez routera.

ℹ️

Porty access to opcjonalny przykład dla urządzeń fizycznych w tym samym VLAN-ie (tutaj: storage na blaszaku w VLAN 20). Jeśli w danym VLAN-ie masz wyłącznie maszyny wirtualne na Proxmoxie, nie konfigurujesz żadnych portów access — wystarczy sam trunk swp1, a VLAN „mieszka” w sieci, nie na hoście.

NVUE — Cumulus Linux 5.x
# Zdefiniuj VLAN-y na domyślnym mostku br_default
cumulus@sn4700:~$ nv set bridge domain br_default vlan 10,20,30,99
 
# swp1 → host Proxmox: trunk niosący wszystkie VLAN-y mostka
cumulus@sn4700:~$ nv set interface swp1 bridge domain br_default
 
# swp10–swp12 → porty access dla fizycznego storage w VLAN 20
cumulus@sn4700:~$ nv set interface swp10-12 bridge domain br_default access 20
 
# Zastosuj i zapisz konfigurację na trwałe
cumulus@sn4700:~$ nv config apply
cumulus@sn4700:~$ nv config save

Domyślnie port dodany do br_default staje się trunkiem przepuszczającym wszystkie VLAN-y mostka — dokładnie to, czego potrzebuje host Proxmox z VLAN-aware bridge. Ruch nieotagowany trafia do native VLAN (domyślnie 1); zarządzanie (VLAN 99) jedzie otagowane, bo po stronie hosta odbiera je podinterfejs vmbr0.99.

Dla redundancji zestaw dwa porty w bond LACP i wpuść go do mostka (przy dwóch switchach SN4700 pracujących w MLAG — po stronie Cumulus zwanym CLAG — bond konfigurujesz analogicznie na obu):

NVUE — bond LACP do hosta
# Bond 802.3ad z dwóch portów jako trunk do hosta
cumulus@sn4700:~$ nv set interface bond1 bond member swp1,swp2
cumulus@sn4700:~$ nv set interface bond1 bond mode lacp
cumulus@sn4700:~$ nv set interface bond1 bridge domain br_default
cumulus@sn4700:~$ nv config apply

Wolisz edytować plik wprost? Ten sam trunk w /etc/network/interfaces (składnia ifupdown2, wspólna z Proxmoxem) wygląda tak:

/etc/network/interfaces
auto br_default
iface br_default
    bridge-ports swp1 swp10 swp11 swp12
    bridge-vlan-aware yes
    bridge-vids 10 20 30 99
    bridge-pvid 1
 
auto swp10
iface swp10
    bridge-access 20

Na koniec zweryfikuj tagi po obu stronach łącza. Uniwersalne polecenie bridge vlan show działa i na switchu, i na hoście Proxmox; natywnie w NVUE użyjesz:

weryfikacja VLAN
cumulus@sn4700:~$ nv show interface swp1 bridge domain
cumulus@sn4700:~$ nv show bridge domain br_default vlan

💡

Lista VLAN-ów i native VLAN muszą się zgadzać po obu stronach trunku. Skoro zarządzanie Proxmox odbiera otagowany vmbr0.99, zostaw VLAN 99 w zestawie otagowanych (bridge-vids) — nie ustawiaj go jako untagged/PVID na porcie switcha, bo stracisz dostęp do hosta zaraz po nv config apply.

// 05 · Dobre praktyki i pułapki

O czym pamiętać

Trunk na switchu: brak danego VLAN ID na trunku to najczęstsza przyczyna „milczącej” sieci. Najpierw sprawdzaj konfigurację portu na przełączniku.
Native VLAN / PVID: ustal świadomie, co dzieje się z ruchem nieotagowanym. Niedopasowanie native VLAN między hostem a switchem prowadzi do trudnych do wykrycia wycieków ruchu.
MTU: znacznik VLAN dokłada bajty do ramki. Przy jumbo frames (storage, Ceph) upewnij się, że MTU jest spójne na hoście, bondzie, mostku i switchu.
Firewall Proxmox: VLAN izoluje warstwę 2, ale reguły między strefami i tak warto egzekwować na firewallu — Proxmox ma wbudowany, działający per VM/kontener.

⚠️

VLAN to izolacja logiczna, nie szyfrowanie. Dla naprawdę wrażliwych segmentów łącz VLAN-y z firewallem i — tam, gdzie to konieczne — z separacją fizyczną lub szyfrowaniem ruchu.

Zaprojektujemy Twoją sieć w Proxmox

Trunki, VLAN-aware bridge, bondy LACP, segmentacja zarządzania i firewall — przeniesiemy logikę sieciową z VMware do Proxmox VE czysto i bezpiecznie.

⚡ Bezpłatna konsultacja → Kontenery LXC w Proxmox

// Table of Contents

One cable, many separated networks
Tag on the bridge, not on sub-interfaces
A VLAN-aware bridge step by step
VLAN rules on a Cumulus Linux switch
What to keep in mind

// 01 · How it works

One cable, many separated networks

A VLAN adds a 4-byte 802.1Q tag (VLAN ID, 1–4094) to the Ethernet frame. Switches and hosts treat traffic with different tags as if it flowed through physically separate networks — devices in VLAN 10 don't directly see devices in VLAN 20, even though they share the same switch and the same uplink cable.

A port carrying several tagged VLANs at once (e.g. the uplink from a Proxmox host to a switch) is called a trunk. A port permanently assigned to a single VLAN, delivering untagged traffic to an end device, is an access port. Untagged traffic lands in the port's native VLAN (PVID).

ℹ️

A VLAN is layer-2 separation. For segments to communicate, traffic must pass through a router or firewall (layer 3) — the natural place for rules and access control between zones.

// 02 · The VLAN-aware bridge model

Tag on the bridge, not on sub-interfaces

Proxmox offers two approaches to VLANs. The recommended and most maintainable is the VLAN-aware bridge: a single vmbr0 bridge with VLAN support enabled covers all segments, and you assign the VLAN number per machine in the NIC configuration.

VLAN-aware bridge: one bridge for all VLANs, tag set in the "VLAN Tag" field of the VM/container NIC. Clean, scalable and easy to audit.
Traditional sub-interfaces: separate interfaces eno1.10, eno1.20 and a separate bridge per VLAN. It works, but the configuration multiplies quickly.
What to avoid: tagging inside the guest while also tagging on the host — accidental double tags (QinQ) are a classic source of "the network just won't work".

On the switch side, the port to the host must be a trunk passing all the VLAN IDs in use. This is the most common point of failure: the host tags correctly, but the switch drops unknown VLANs.

// 03 · Configuration in practice

A VLAN-aware bridge step by step

Enable the VLAN-aware bridge in the UI (Node → System → Network → select vmbr0 → "VLAN aware") or directly in /etc/network/interfaces:

Element	Configuration
VLAN-aware bridge	`bridge-vlan-aware yes` + `bridge-vids 2-4094`
VLAN for a VM	Hardware → Network Device → VLAN Tag = e.g. 10
VLAN for an LXC container	Network → VLAN Tag in the interface config
Management address in a VLAN	sub-interface `vmbr0.99` with the host IP
Check the tags	`bridge vlan show`

For uplink redundancy, bond the links into a bond (LACP 802.3ad) and put the VLAN-aware bridge on the bond instead of a single NIC — you get both link-failure resilience and full VLAN segmentation at once.

💡

Keep the Proxmox management network in a different VLAN from production VM traffic. It's a simple change that significantly reduces the attack surface on the host interface and the cluster.

// 04 · NVIDIA SN4700 switch (Cumulus Linux)

VLAN rules on a Cumulus Linux switch

The NVIDIA SN4700 switch (Spectrum-3, 32× 400 GbE ports) ships by default with Cumulus Linux. That's a favourable scenario: Cumulus uses the exact same VLAN-aware bridge model as Proxmox, so you configure both ends of the trunk almost identically. On 5.x releases the standard CLI is NVUE (nv set); older versions used NCLU (net add), and underneath it always runs ifupdown2 with the /etc/network/interfaces file — the very same one used by Proxmox.

Assume a typical layout: port swp1 goes to the Proxmox host and should be a trunk carrying VLAN 10 (production), 20 (storage), 30 (DMZ) and 99 (management), while ports swp10–swp12 are access ports for a physical storage server (bare metal) sitting next to it, in VLAN 20. That way the VMs on Proxmox and the physical storage sit on the same L2 network (VLAN 20) and reach each other directly — without a router.

ℹ️

The access ports are an optional example for physical devices in the same VLAN (here: bare-metal storage in VLAN 20). If a given VLAN holds only virtual machines on Proxmox, you don't configure any access ports — the swp1 trunk alone is enough, since a VLAN "lives" on the network, not on the host.

NVUE — Cumulus Linux 5.x
# Define the VLANs on the default br_default bridge
cumulus@sn4700:~$ nv set bridge domain br_default vlan 10,20,30,99
 
# swp1 → Proxmox host: a trunk carrying all bridge VLANs
cumulus@sn4700:~$ nv set interface swp1 bridge domain br_default
 
# swp10–swp12 → access ports for physical storage in VLAN 20
cumulus@sn4700:~$ nv set interface swp10-12 bridge domain br_default access 20
 
# Apply and persist the configuration
cumulus@sn4700:~$ nv config apply
cumulus@sn4700:~$ nv config save

By default, a port added to br_default becomes a trunk passing every VLAN on the bridge — exactly what a Proxmox host with a VLAN-aware bridge needs. Untagged traffic lands in the native VLAN (1 by default); management (VLAN 99) travels tagged, because on the host side it is received by the vmbr0.99 sub-interface.

For redundancy, bundle two ports into an LACP bond and add it to the bridge (with two SN4700 switches in MLAG — called CLAG on Cumulus — you configure the bond the same way on both):

NVUE — LACP bond to the host
# An 802.3ad bond of two ports as a trunk to the host
cumulus@sn4700:~$ nv set interface bond1 bond member swp1,swp2
cumulus@sn4700:~$ nv set interface bond1 bond mode lacp
cumulus@sn4700:~$ nv set interface bond1 bridge domain br_default
cumulus@sn4700:~$ nv config apply

Prefer editing the file directly? The same trunk in /etc/network/interfaces (ifupdown2 syntax, shared with Proxmox) looks like this:

/etc/network/interfaces
auto br_default
iface br_default
    bridge-ports swp1 swp10 swp11 swp12
    bridge-vlan-aware yes
    bridge-vids 10 20 30 99
    bridge-pvid 1
 
auto swp10
iface swp10
    bridge-access 20

Finally, verify the tags on both ends of the link. The universal bridge vlan show command works on both the switch and the Proxmox host; natively in NVUE you'd use:

VLAN verification
cumulus@sn4700:~$ nv show interface swp1 bridge domain
cumulus@sn4700:~$ nv show bridge domain br_default vlan

💡

The VLAN list and native VLAN must match on both ends of the trunk. Since Proxmox management arrives on the tagged vmbr0.99, keep VLAN 99 in the tagged set (bridge-vids) — don't set it as the untagged/PVID on the switch port, or you'll lose access to the host right after nv config apply.

// 05 · Best practices and pitfalls

What to keep in mind

Switch trunk: a missing VLAN ID on the trunk is the most common cause of a "silent" network. Check the switch port configuration first.
Native VLAN / PVID: decide deliberately what happens to untagged traffic. A native-VLAN mismatch between host and switch leads to hard-to-spot traffic leaks.
MTU: the VLAN tag adds bytes to the frame. With jumbo frames (storage, Ceph) make sure the MTU is consistent across host, bond, bridge and switch.
Proxmox firewall: a VLAN isolates layer 2, but rules between zones are still worth enforcing on the firewall — Proxmox has a built-in one that works per VM/container.

⚠️

A VLAN is logical isolation, not encryption. For truly sensitive segments combine VLANs with a firewall and — where necessary — with physical separation or traffic encryption.

We'll design your Proxmox network

Trunks, VLAN-aware bridges, LACP bonds, management segmentation and the firewall — we'll move your network logic from VMware to Proxmox VE cleanly and safely.

⚡ Free consultation → LXC containers in Proxmox