Proxmox VLAN не працює: trunk-порти, тегування Linux bridge і виправлення «немає мережі»

November 7, 2025 • February 3, 2026 • Читання: 7 хв • Views: 15

Було корисно?

Ви проставили тег у VM. Ви проставили тег у bridge. Ви проставили тег на комутаторі. І гість досі не може пропінгувати свій шлюз — хіба що у п’ятницю, та ще тільки з одного вузла. Ласкаво просимо до налагодження VLAN у Proxmox: наполовину мережі, наполовину археологія, і трохи «чому це ламається лише після перезавантаження?»

Це практичний, орієнтований на продакшн посібник для знаходження реальної зони несправності: trunk-порти, що насправді не trunk; VLAN-фільтрація Linux bridge, що працює напіввключено; PVID, який непомітно переписує кадри; і класичний симптом Proxmox «немає мережі», що насправді приховує ARP або MTU проблему.

Ментальна модель, яка припиняє здогадки

Коли VLAN «не працюють» у Proxmox, це рідко містика. Зазвичай це одне з наступного:

Кадри не теговані там, де ви думаєте. VM відправляє нетеговані кадри, bridge очікує теговані, або навпаки.
Кадри теговані, але відкидаються. Таблиця VLAN bridge, список дозволених VLAN на комутаторі або upstream ACL їх відкидає.
Кадри проходять, але L2/L3 ламається. ARP не відповідає, шлюз знаходиться в іншому VLAN або трапилось асиметричне маршрутування.
Все працює… поки не перестає. Перезавантаження змінює порядок інтерфейсів, VLAN-фільтрація переключається, LACP переобирає канали або шаблон порту комутатора «допомагає» скинути налаштування.

Думайте шарами, а не інтуїцією:

L1: лінк, швидкість/дуплекс, оптика, стан бонду.
L2: VLAN-теги, таблиця VLAN bridge, навчання MAC, стан STP.
L3: IP-адресація, шлюз, ARP/ND, маршрутизація, фаєрвол.

Proxmox ускладнює це тим, що поєднує мережу хосту (керування, сховище) із віртуальним комутуванням гіпервізора (NIC гостьових ОС). Linux bridge — це справжній комутатор з таблицями переадресації. Ставтесь до нього відповідно.

Цитата, яку варто повісити на стіну: «Надія — не стратегія.» — General Gordon R. Sullivan. Мережі не винагороджують оптимізм.

Швидкий план діагностики (перший/другий/третій)

Перший: доведіть, чи є теги на дроті

Ваше перше завдання — припинити теорії й зафіксувати реальність.

На хості Proxmox запустіть tcpdump на фізичному NIC або bond і перевірте наявність vlan у кадрах.
Якщо теги відсутні: це проблема конфігурації Proxmox/bridge/VM.
Якщо теги присутні: це проблема trunk/allowed VLAN/PVID на комутаторі або upstream-політика.

Другий: підтвердьте фільтрацію VLAN та членство bridge

Linux bridge може ігнорувати таблиці VLAN (класичний режим) або застосовувати їх (VLAN-aware). Змішання очікувань тут викликає «немає мережі» при цілком коректній конфігурації.

Перевірте vlan_filtering на bridge і членство VLAN для кожного порту.
Визначте, який порт — uplink, який — tap VM і які VLAN ID дозволені.

Третій: перевірте базові L3 і нудні речі

Коли L2 в порядку, залишкові збої зазвичай пов’язані з:

Неправильним шлюзом або маскою підмережі в гості.
ARP-проблемою через фаєрвол, дубль IP або пристрій upstream відповідає на ARP в іншому VLAN.
Несумісністю MTU — особливо при VLAN + bond + мережах сховища.

Якщо запам’ятати одне: найшвидший шлях — «чи присутній тег?» → «чи дозволено він?» → «чи відповідає ARP?»

Цікаві факти та контекст (так, це важливо)

Це не тривіалітет заради тривіальностей. Кожен пункт відповідає реальному випадку, який я бачив у продакшн.

802.1Q VLAN-тег додає 4 байти до Ethernet-кадру. Цей малий заголовок — причина, чому проблеми MTU проявляються «лише на VLAN.»
Linux-бридж існує вже десятиліттями і передував багатьом сучасним «SDN» оболонкам. У Proxmox усе ще ядро Linux виконує комутацію.
Режим VLAN-aware bridge відносно новий у порівнянні з класичним бриджем і поводиться як керований комутатор: якщо VLAN відсутній у таблиці, кадри можуть тихо відкидатися.
Поняття «native VLAN» — це конвенція комутатора, а не характеристика VLAN. Невідповідність native VLAN призводить до того, що нетегований трафік опиняється не там, без будь-яких помилок.
Початкові розгортання VLAN часто робилися для обмеження широкомовлення, а не для безпеки. Сьогодні люди трактують VLAN як зони безпеки — це вірно лише якщо ви контролюєте L3/L4 політику.
LACP не «балансує навантаження» по пакетах за замовчуванням на багатьох системах; він хешує потоки. Ось чому «одна VM повільна, інша в порядку» трапляється на бондах з trunk.
STP і VLAN переплетені: залежно від режиму комутатора (PVST/RPVST/MST) VLAN може бути заблокований, поки інші пересилають, створюючи «тільки VLAN 30 мертвий».
ARP — балакучий і крихкий. Багато інцидентів «VLAN не працює» насправді пов’язані з ARP-відповідями, що фільтруються фаєрволом хоста, upstream безпекою або дублюванням IP.
Історично Proxmox орієнтувався на ifupdown-стиль конфігу; новіші системи використовують ifupdown2 і можуть застосовувати зміни живцем, але не всі зміни безпечні без вікна обслуговування.

Практичні завдання: команди, виводи, рішення (12+)

Ось завдання, які я виконую приблизно в такому порядку, коли VM каже «немає мережі» на VLAN. Кожне включає: команду, що означає типовий вивід і яке рішення прийняти далі.

Завдання 1: Підтвердіть, що хост бачить лінк і який NIC за що відповідає

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp3s0           UP             3c:ec:ef:11:22:33 <BROADCAST,MULTICAST,UP,LOWER_UP>
enp4s0           DOWN           3c:ec:ef:11:22:34 <BROADCAST,MULTICAST>
bond0            UP             3c:ec:ef:aa:bb:cc <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP>
vmbr0            UP             3c:ec:ef:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP>

Значення: bond0 і vmbr0 в UP; один фізичний NIC в DOWN. Якщо ви думали, що маєте два активні лінки — це не так.

Рішення: Виправте здоров’я лінку/бонду перед тим, як чіпати VLAN-конфіг. Дебаг VLAN на не стабільному uplink — це самонавішування.

Завдання 2: Перевірте здоров’я bonding (LACP vs active-backup і який slave активний)

cr0x@server:~$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: enp3s0
MII Status: up
Actor Churn State: churned
Partner Churn State: churned

Slave Interface: enp4s0
MII Status: down

Значення: LACP налаштовано, але один slave down і стан churn вказує на зміну переговорів.

Рішення: Перевірте конфіг LACP на комутаторі та кабелювання. Якщо комутатор очікує статичний trunk, а хост — LACP, ви отримаєте випадкові VLAN-аномалії.

Завдання 3: Перегляньте конфіг мережі Proxmox (джерело істини)

cr0x@server:~$ sed -n '1,200p' /etc/network/interfaces
auto lo
iface lo inet loopback

auto bond0
iface bond0 inet manual
        bond-slaves enp3s0 enp4s0
        bond-miimon 100
        bond-mode 802.3ad
        bond-xmit-hash-policy layer3+4

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

Значення: VLAN-aware bridge увімкнено; uplink — bond0; management IP — нетегований на vmbr0 (тобто знаходиться на тій VLAN, яка відповідає нетегованому/native VLAN trunk).

Рішення: Якщо management мережа має бути тегованою, помістіть її на підінтерфейс (наприклад, vmbr0.10) або встановіть очікування PVID. Нетегований management на trunk — джерело подальших сюрпризів.

Завдання 4: Підтвердіть, що фільтрація VLAN на bridge справді увімкнена

cr0x@server:~$ ip -d link show vmbr0
7: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:aa:bb:cc brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
    bridge forward_delay 0 hello_time 2 max_age 20 ageing_time 300 stp_state 0 priority 32768 vlan_filtering 1 vlan_protocol 802.1Q

Значення: vlan_filtering 1 означає, що bridge застосовуватиме правила членства VLAN.

Рішення: Далі потрібно перевірити таблицю VLAN. У режимі VLAN-aware «підключено до vmbr0» недостатньо.

Завдання 5: Вивантажте членство VLAN по портах bridge

cr0x@server:~$ bridge vlan show
port              vlan-id
bond0             1 PVID Egress Untagged
bond0             10
bond0             20
tap100i0          10 PVID Egress Untagged
tap101i0          20 PVID Egress Untagged

Значення: Uplink bond0 має VLAN 10 і 20 тегованими, а VLAN 1 — нетегований (native). Tap-порти VM є нетегованими членами з PVID, встановленим для кожної VM.

Рішення: Якщо VM має сама тегувати трафік (guest VLAN tagging), то її tap-порт зазвичай має пропускати теговані VLAN, а не бути PVID-нетегованим. Визначте, хто робить тегування: хост чи гість. Не робіть обох одночасно.

Завдання 6: Визначте, який tap-пристрій відповідає якій VM

cr0x@server:~$ qm list
      VMID NAME                 STATUS     MEM(MB)    BOOTDISK(GB) PID
       100 app-01               running    4096              32.00 2101
       101 db-01                running    8192             128.00 2255

Значення: VMID 100/101 ймовірно відповідають tap100i0 та tap101i0.

Рішення: Якщо неправильна VM у неправильному VLAN — перевірте апаратну конфігурацію VM у Proxmox: тег на NIC, вибір bridge, прапорець фаєрволу.

Завдання 7: Підтвердьте, що NIC VM теговано як очікувалося в Proxmox

cr0x@server:~$ qm config 100 | sed -n '1,120p'
boot: order=scsi0;net0
memory: 4096
name: app-01
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,tag=10,firewall=0
scsi0: local-lvm:vm-100-disk-0,size=32G

Значення: Proxmox робить тегування для VM 100 (VLAN 10). Гість має бути налаштований як нетегований NIC.

Рішення: Якщо гість також тегує VLAN 10 всередині, ви щойно зробили подвійне тегування. Виправте одну зі сторін.

Завдання 8: Захопіть трафік на uplink і перевірте VLAN-теги

cr0x@server:~$ sudo tcpdump -eni bond0 -c 8 '(arp or icmp) and (vlan 10)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:01:10.112233 DE:AD:BE:EF:10:00 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), vlan 10, ethertype ARP (0x0806), Request who-has 10.10.10.1 tell 10.10.10.50, length 46
12:01:10.113005 00:11:22:33:44:55 > DE:AD:BE:EF:10:00, ethertype 802.1Q (0x8100), vlan 10, ethertype ARP (0x0806), Reply 10.10.10.1 is-at 00:11:22:33:44:55, length 46

Значення: VLAN 10 теги присутні на дроті. ARP відповідає. L2 ймовірно в порядку для цього VLAN.

Рішення: Якщо VM досі не може досягти нічого — перевірте IP-конфіг гостя, фаєрвол хоста або маршрути upstream. Якщо ви бачите ARP-запити, але немає відповідей, перевірте членство VLAN на комутаторі або наявність шлюзу.

Завдання 9: Захопіть трафік на tap, щоб побачити, що «бачить» гість

cr0x@server:~$ sudo tcpdump -eni tap100i0 -c 6 arp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tap100i0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:02:44.000111 DE:AD:BE:EF:10:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), Request who-has 10.10.10.1 tell 10.10.10.50, length 46
12:02:44.000890 00:11:22:33:44:55 > DE:AD:BE:EF:10:00, ethertype ARP (0x0806), Reply 10.10.10.1 is-at 00:11:22:33:44:55, length 46

Значення: Tap, що дивиться на гостя, є нетегованим (очікувано, якщо Proxmox тегує на виході до uplink). ARP працює.

Рішення: Якщо ARP працює тут, але не на bond0 — проблема в тегуванні/правилах VLAN bridge. Якщо ARP працює на обох, зосередьтесь на L3.

Завдання 10: Підтвердіть навчання MAC і FDB по VLAN

cr0x@server:~$ bridge fdb show br vmbr0 | head -n 12
00:11:22:33:44:55 dev bond0 vlan 10 master vmbr0 permanent
de:ad:be:ef:10:00 dev tap100i0 master vmbr0
de:ad:be:ef:20:00 dev tap101i0 master vmbr0

Значення: MAC шлюзу вивчено/зафіксовано на VLAN 10 через bond0. MAC VM вивчено на tap.

Рішення: Якщо MAC шлюзу відсутній — комутатор/шлюз можуть бути недоступні на цьому VLAN. Якщо MAC VM не відображається — VM не передає пакетів або підключена до неправильного bridge.

Завдання 11: Перевірте фаєрвол хоста або сюрпризи bridge netfilter

cr0x@server:~$ sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables net.bridge.bridge-nf-call-arptables
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-arptables = 0

Значення: Трафік через bridge може проходити через правила iptables. Це іноді бажано, іноді — прихований шматок пакету-рубильника.

Рішення: Якщо ви не фільтруєте трафік через bridge навмисно, подумайте про відключення bridge-nf викликів або аудит правил. Якщо фільтруєте, переконайтесь, що правила охоплюють VLAN-інтерфейси/тари коректно.

Завдання 12: Перевірте MTU в кінці кінців (хост, bridge, шлях гостя)

cr0x@server:~$ ip -br link show bond0 vmbr0
bond0            UP             3c:ec:ef:aa:bb:cc <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500
vmbr0            UP             3c:ec:ef:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

Значення: MTU — 1500. Якщо ваш upstream використовує 9000 (jumbo) або гість очікує 1500, але щось проміжне має 1496 через дивні налаштування, ви отримаєте проблеми фрагментації/PMTUD.

Рішення: Вибирайте одне MTU на домен. Для VLAN-trunk, що несе трафік jumbo для сховища, встановіть MTU узгоджено на фізичних NIC, бондах, бриджах і портах комутатора. Інакше тримайте 1500 і спіть спокійніше.

Завдання 13: Перевірте маршрутизацію та таблицю сусідів на хості (для тегованих IP хоста)

Якщо сам Proxmox хост має VLAN-підінтерфейс (поширено для management), перевірте розв’язання сусідів.

cr0x@server:~$ ip neigh show dev vmbr0
10.10.10.1 lladdr 00:11:22:33:44:55 REACHABLE
10.10.10.50 lladdr de:ad:be:ef:10:00 STALE

Значення: ARP-розв’язання працює на vmbr0. Якщо ви бачите FAILED записи — L2 зламається або фільтрується.

Рішення: Якщо сусіди відмовляють лише на певному VLAN, перегляньте таблицю VLAN bridge і дозволені VLAN на комутаторі. Якщо відмови по всій мережі — перевірте лінк/бонд і стан порту комутатора.

Завдання 14: Переконайтесь, що шлях гостя не блокується прапорцями фаєрвола Proxmox

cr0x@server:~$ pvesh get /nodes/server/qemu/100/config | sed -n '1,40p'
boot: order=scsi0;net0
memory: 4096
name: app-01
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,firewall=0,tag=10

Значення: Фаєрвол для NIC VM вимкнено. Якщо він увімкнений, правила можуть відкидати DHCP/ARP/ICMP.

Рішення: Якщо включуєте фаєрвол, явно дозволіть DHCP (67/68), ARP (L2) і потрібні протоколи, інакше ви будете дебажити «проблеми VLAN», що насправді є політикою.

Схеми конфігурації Proxmox, що дійсно працюють

Є два розумні підходи до VLAN для VM у Proxmox. Виберіть один. Змішування їх — це шлях до створення жертів пакетовтрат.

Схема A: Proxmox тегує на рівні NIC VM (рекомендовано для більшості)

Це поле «VLAN tag» у конфігурації NIC VM. Гість бачить нетегований NIC. Proxmox ставить його у VLAN, тегуючи кадри на uplink bridge.

Чому це працює: Ви централізуєте призначення VLAN у гіпервізорі. Гості залишаються простими. Міграції між вузлами передбачувані.

Вимоги до bridge:

bridge-vlan-aware yes на bridge
bridge-vids містить потрібні VLAN ID (або налаштовано через таблицю bridge vlan)
Порт комутатора налаштований як trunk, що несе ці VLAN

Схема B: Гість тегує VLANи (тільки якщо є причина)

Іноді VM — це маршрутизатор, фаєрвол або апарат, який потребує кількох VLAN на одному NIC. Тоді гість сам тегує VLANи (наприклад, eth0.10, eth0.20).

Конфіг хоста: NIC VM не повинен мати тег. Tap-порт повинен пропускати теговані VLANи, і ви керуєте дозволеними VLANами на bridge-порті і trunk на комутаторі.

Правило пальця: Якщо ви не будуєте маршрутизатор/фаєрвол VM, не використовуйте тегування в гості. Це додає зайвої складності й робить інциденти «немає мережі» набагато цікавішими, ніж потрібно.

Management IP хоста на VLAN: зробіть чисто

Якщо management-мережа Proxmox тегована (поширено у корпоративних середовищах), не покладайтеся на «нетегований trunk = потрібний VLAN». Зробіть це явно підінтерфейсом на bridge. Приклад:

cr0x@server:~$ sed -n '1,120p' /etc/network/interfaces
auto lo
iface lo inet loopback

auto bond0
iface bond0 inet manual
        bond-slaves enp3s0 enp4s0
        bond-miimon 100
        bond-mode 802.3ad

auto vmbr0
iface vmbr0 inet manual
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 10 20 30

auto vmbr0.10
iface vmbr0.10 inet static
        address 10.10.10.11/24
        gateway 10.10.10.1

Операційний бонус: Коли хтось змінює «native VLAN» на комутаторі, ваш хост не телепортується в іншу мережу. Він залишається на VLAN 10, бо тегує трафік.

Короткий жарт #1: Native VLAN — як «тимчасові правила фаєрвола» — ніхто не пам’ятає, що вони існують, поки не зіпсують вам день.

Не ускладнюйте: один bridge на uplink зазвичай достатньо

Люди створюють кілька bridge (vmbr0, vmbr1, vmbr2) для кожного VLAN, бо це виглядає охайно. Це також множить точки відмови, ускладнює розуміння trunk і ускладнює міграції.

Використовуйте один VLAN-aware bridge для uplink і тегуйте на NIC VM. Додайте більше bridge лише коли дійсно маєте окремі фізичні домени або потребуєте окремих MTU чи політик безпеки.

Перевірка стану trunk на боці комутатора

Будьмо чесними: половина тікетів про VLAN в Proxmox — це тікети для комутатора, сховані під Linux-подушкою. Ви можете робити все правильно на хості й усе одно програти, бо trunk насправді не trunk.

Що потрібно від порту комутатора

Режим trunk (або еквівалент): порт має приймати теговані кадри.
Список дозволених VLAN: включіть VLANи, потрібні вашим VM. «Усі VLANи» легко, але іноді заборонено політикою.
Вирівнювання native VLAN: якщо ви використовуєте нетегований трафік, визначте, куди він мапиться. Краще: уникайте нетегованого трафіку, окрім явних причин.
Згодженість LACP: якщо бондите, обидві сторони мають погодити LACP vs статичну агрегацію.
Поведінка STP: trunk-порти можуть бути заблоковані, якщо STP бачить петлі. Слідкуйте за режимами блокування по VLAN у деяких сімействах комутаторів.

Два невідповідності trunk, що витрачають найбільше часу

Невідповідність 1: У списку дозволених VLAN немає вашого VLAN. Хост тегує VLAN 20; комутатор відкидає VLAN 20. На хості ви побачите теги, що йдуть, але немає відповідей. Класика.

Невідповідність 2: Mismatch native VLAN. Хост відправляє нетегований management трафік, очікуючи VLAN 10; комутатор мапить нетегований трафік у VLAN 1. Ваш хост має лінк, але знаходиться на іншій «планеті».

Короткий жарт #2: Невідповідності VLAN — єдине місце, де «в мене працює» означає «на комутаторі зламалося».

Поширені помилки: симптом → причина → виправлення

1) Симптом: VM не отримує DHCP-ліз на VLAN, але статична IP також не пінгує шлюз

Причина: VLAN не дозволено на trunk комутатора або в таблиці VLAN bridge відсутнє членство.

Виправлення: Додайте VLAN до дозволеного списку на комутаторі і переконайтесь, що bridge-vlan-aware yes та VLAN присутній в bridge vlan show. Підтвердіть за допомогою tcpdump -eni bond0 vlan X.

2) Симптом: VM може пінгувати шлюз, але не інші підмережі

Причина: Неправильний шлюз у гості, відсутній маршрут upstream або асиметричне маршрутування через багатогніздові шлюзи/фаєрволи.

Виправлення: Перевірте дефолтний маршрут гостя, потім трасуйте від боку шлюзу. Якщо у вас кілька VLAN-інтерфейсів на фаєрволі, перевірте політики й таблиці маршрутизації для кожного VLAN.

3) Симптом: Працює лише на одному вузлі Proxmox; інші — ні

Причина: Порти комутатора відрізняються (allowed VLAN, native VLAN, режим LACP), або конфіги хостів розходяться (VLAN-фільтрація bridge увімкнена на одному, а на інших ні).

Виправлення: Зіставте /etc/network/interfaces, ip -d link і bridge vlan show між вузлами. Порти комутатора мають мати однаковий профіль.

4) Симптом: VLAN працює до live-migration VM, потім ламається

Причина: На вузлі-цілі таблиця VLAN bridge не містить VLAN або trunk на uplink відрізняється.

Виправлення: Розглядайте членство VLAN як кластерну інтенцію: стандартизувати конфіг bridge і конфіг комутатора для кожного вузла. Тестуйте міграції з canary VM на кожному VLAN.

5) Симптом: Доступ до management хоста зникає після увімкнення VLAN-aware bridge

Причина: Management IP хоста покладався на нетегований/native VLAN; увімкнення фільтрації змінило обробку, або PVID/нетегований VLAN не такий, як ви думали.

Виправлення: Перенесіть management на явний тегований підінтерфейс (vmbr0.10) і переконайтесь, що trunk комутатора дозволяє VLAN 10. Плануйте вікно обслуговування і майте OOB-доступ.

6) Симптом: Деякий трафік працює (малі пінги), але великі передачі зависають або зависають

Причина: Несумісність MTU з VLAN-накладенням або PMTUD блокується фаєрволом.

Виправлення: Уніфікуйте MTU; дозволіть ICMP fragmentation-needed повідомлення, якщо є маршрутизація. Тестуйте з ping -M do -s з гостя.

7) Симптом: VLAN 1 працює, VLAN 10/20 — ні

Причина: Trunk насправді був access-портом, або список allowed VLAN неправильний.

Виправлення: Перекладіть порт комутатора в режим trunk і дозволіть VLANи. Перевірте теги на дроті за допомогою tcpdump; якщо ніколи не бачите VLAN-тегів, то тегування на хості/bridge налаштовано неправильно.

8) Симптом: ARP-запити відправляються, але ARP-відповіді ніколи не повертаються

Причина: VLAN заблокований на trunk, шлюз не знаходиться на цьому VLAN або upstream-функція безпеки (dynamic ARP inspection, port security) блокує відповіді.

Виправлення: Підтвердіть VLAN інтерфейс шлюзу; перевірте функції безпеки на комутаторі; валідуйте навчання MAC. На хості використайте tcpdump, щоб побачити, чи прибувають відповіді на bond0.

Чеклісти / покроковий план

Крок за кроком: доберіть один VLAN до роботи end-to-end (повторюваний метод)

Оберіть тестовий VLAN (наприклад, VLAN 20) і тестову VM з відомою доброю IP/шлюзом.
Перевірте trunk на комутаторі: режим trunk, VLAN 20 дозволено, коректний native VLAN (або взагалі відмова від нетегованого).
Перевірте uplink на хості: лінк up, бонд коректний, нема флапу.
Перевірте режим bridge: VLAN-aware увімкнено, якщо ви покладаєтеся на теги Proxmox.
Перевірте конфіг NIC VM: tag=20 якщо хост тегує; інакше без тегу, якщо гість тегує.
Перевірте таблицю VLAN bridge, що включає VLAN 20 на uplink і коректну поведінку tap для VM.
Спостерігайте ARP у трьох точках: tap, bridge/uplink та (якщо можливо) на боці комутатора/шлюзу.
Доведіть L3 за допомогою пінгу шлюзу; потім перевірте далі за шлюз.
Тестуйте MTU якщо є вимоги до продуктивності або великих пакетів.
Лише після успіху переходьте до масштабування VLAN і автоматизації.

Чеклист перед змінами (перед тим, як чіпати продакшн VLAN)

Позасіть доступ до консолі поза мережею (IPMI/iDRAC/iLO) і перевірте актуальність облікових даних.
Збережіть конфіг порту комутатора або зробіть дамп (навіть вставлений фрагмент конфігу підходить).
Маєте вікно обслуговування або план відкату: відновлення /etc/network/interfaces і перезапуск мережі може відрізати вас.
Знайте, чи використовуєте тегування Proxmox або тегування в гості. Запишіть це.
Підтвердьте, чи увімкнений фаєрвол Proxmox на рівні датацентру/вузла/VM і чи активний bridge netfilter.

Чеклист після змін (доведіть, що дійсно виправлено)

VM отримує DHCP (якщо застосовується) і може обновити ліз.
VM може пінгувати шлюз і принаймні одну адресу за межами шлюзу.
Тест міграції: live-migrate VM на інший вузол і повторно перевірте зв’язність.
Тест перезавантаження (якщо дозволено): підтвердьте, що VLAN переживає перезавантаження вузла.
Зробіть доказ: фрагмент tcpdump, що показує наявність VLAN-тегу і отримані ARP-відповіді.

Три корпоративні міні-історії з практики

Міні-історія 1: Інцидент через неправильне припущення

Вони переносили кілька «низькоризикових» VM до нового Proxmox-кластера. Мережна команда надала по два порти на хост, об’єднані як LACP, і сказала магічні слова: «це trunk». Віртуалізаційна команда кивнула, увімкнула VLAN-aware bridge, призначила теги по VM і пішла далі.

Через дві години почалась перша хвиля міграцій. Половина VM піднялись нормально. Решта показала «немає мережі» в гості. Команда, що діяла під тиском, зробила те, що роблять команди: змінила три речі одночасно — перезавантажила VM, перезавантажила мережеві сервіси, переключила прапорці фаєрвола — і зробила докази ще гіршими.

Хибне припущення було тонким: «trunk» значило «усі VLAN» для віртуалізаційної команди, але на боці комутатора дозволено лише підмножина. Працюючі VM випадково жили у дозволених VLAN; зламані — ні. На хості нічого не виглядало «down». Лінк був up, бонди були up, бриджі були up. Це найчистіша помилка мережі: мовчазне відкинення неавторизованих VLAN-тегів.

Виправлення було нудне й негайне: узгодити списки дозволених VLAN на кожному порт-чанелі хоста, а потім стандартизувати чекліст: коли з’являється новий VLAN — оновлювати одночасно Proxmox bridge VLAN allowance і switch trunk allowed VLANs.

Вони також додали canary VM для кожного VLAN, що постійно тестує ARP і доступ до шлюзу. Це не гламурно, але робить наступне хибне припущення голосним, а не дорогим.

Міні-історія 2: Оптимізація, що обернулась проти

Інженер, орієнтований на продуктивність, вирішив «спростити й пришвидшити» шляхом створення окремого Linux bridge для кожного VLAN, кожен прив’язаний до того ж bond uplink, і потім прив’язав VM до конкретного bridge. Ідея здавалася охайною: менше правил VLAN, менше складності, чистіші діаграми. Вона також ускладнила експлуатацію.

Перша проблема з’явилась під час обслуговування. Зміна на комутаторі тимчасово змінила native VLAN на trunk. Один з цих bridge ніс management нетеговано — бо «management не потребує тегів, він на native VLAN». IP management хоста опинився в іншому VLAN, і вузол зник з моніторингу. Не впав. Просто… переїхав.

Друга проблема прийшла з міграціями. Декілька вузлів мали трохи різні визначення bridge, і VM, що мігрувала з вузла A на вузол B, опинялась прив’язаною до bridge, що існував, але не був так само спланований. Зв’язність стала рисою персональності кожного вузла.

У відновлені вони злили назад до одного VLAN-aware bridge на uplink і використали per-VM тегі Proxmox. Management перенесли на явний тегований підінтерфейс. Продуктивність не постраждала. Операційна зрозумілість значно покращилась.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Інша організація мала звичку, що здавалася майже старомодною: кожен Proxmox вузол мав ідентичний блок мережевої конфігурації, збережений у системі управління конфігурацією, а порти комутаторів провижонувалися через стандартний шаблон. Інциденти у них теж траплялись — у кого їх немає — але зона ураження була меншою.

Одного дня з’явився новий VLAN для бізнес-додатку. VLAN додали у фаєрвол і в ядрові комутатори, але забули додати у access layer порти, які підгодовували дві з чотирьох гіпервізорів. VM на тих двох вузлах не могли досягти шлюзу; VM на інших вузлах могли.

Ось де нудна практика врятувала: on-call виконав швидкий план, порівняв allowed VLANи між портами і знайшов невідповідність за кілька хвилин. Жодних тривалих дебатів про те, «чи підтримує Proxmox цей VLAN» або чи «драйвер гостя поводиться дивно». Докази були чистими, бо базова лінія була консистентною.

Виправлення — оновлення шаблону порту комутатора і застосування. Потім вони додали до чекліста змін пункт: «Додати VLAN до trunk гіпервізорів» як явний крок. Це не хитро, але саме така нудна дисципліна зберігає сон.

FAQ

1) Чи варто використовувати VLAN-aware bridge у Proxmox?

Так, якщо ви використовуєте Proxmox для тегування трафіку VM (поширений випадок). VLAN-aware bridge робить Linux bridge схожим на реальний комутатор з членством VLAN, що запобігає випадковим витокам і робить тегування детермінованим.

2) Моя VM тегована в Proxmox. Чи має гостьовий NIC теж створювати підінтерфейси VLAN?

Ні. Якщо Proxmox застосовує tag=10 на NIC VM, гість повинен трактувати цей NIC як нетегований. Гостьові підінтерфейси VLAN потрібні лише якщо VM має нести кілька VLAN або виконувати роль маршрутизатора/фаєрвола.

3) Чому включення VLAN-фільтрації зламало management мережу хоста?

Бо ваш management IP ймовірно покладався на нетегований/native VLAN. Коли фільтрація увімкнена, bridge може по-іншому застосовувати членство VLAN, або PVID/нетегована обробка змінилась. Виправте це, перенісши management на явний тегований інтерфейс, як vmbr0.10.

4) Як дізнатися, чи комутатор відкидає мій VLAN?

Запустіть tcpdump -eni bond0 vlan X. Якщо бачите теговані ARP-запити, що виходять, але немає відповідей, скоріше за все VLAN не дозволено на trunk або шлюз не присутній на тому VLAN.

5) Чи потрібно вручну налаштовувати таблиці VLAN bridge?

Частково Proxmox керує багатьма речами, коли ви вказуєте теги на NIC VM і увімкнено VLAN-aware режим. Але вам все одно потрібно перевіряти bridge vlan show, особливо при комбінуванні guest-tagged trunks, bond-ів або нестандартних uplink-дизайнів.

6) У чому різниця між «bridge-vids» і «allowed VLANs» на комутаторі?

bridge-vids визначає, які VLAN ID Linux bridge вважає допустимими/дозволеними (залежно від конфіг). «Allowed VLANs» на комутаторі визначає, які VLAN комутатор буде пропускати на цьому trunk. Обидва мають включати VLAN, інакше трафік помре.

7) VLAN працює на одному вузлі, але після міграції — ні. Що стандартизувати?

Стандартизувати: конфіг trunk на комутаторі для кожного вузла, режим bonding, налаштування bridge VLAN-aware і дозволи VLAN. Тестуйте міграції як частину приймання. Збої під час міграції майже завжди через дрейф конфігів.

8) Чи можуть SDN-функції Proxmox викликати плутанину з VLAN?

Можуть, головно через абстрагування поведінки Linux bridge. Якщо щось ламається, опустіться до фундаментів: перегляньте bridge vlan show, ip -d link і підтвердьте теги за допомогою tcpdump. Ядро усе ще виконує пересилання.

9) Чому ARP працює, але TCP не працює?

Бо ARP доводить лише L2 сусідство. TCP може падати через MTU/PMTUD, правила фаєрволу, асиметричне маршрутування або upstream ACL. Після успіху ARP перевірте MTU і трасування маршрутів/політик.

10) Чи нормально трункати «усі VLAN» до Proxmox?

Технічно так. Операційно — залежить від вашої моделі безпеки. У багатьох середовищах обмеження allowed VLAN зменшує зону ураження. Якщо ви обмежуєте, ставте це як контракт: новий VLAN вимагає одночасного оновлення на комутаторі і в Proxmox.

Висновок: кроки, що запобігають повторенню

Якщо ваш Proxmox VLAN не працює, не клікайте по UI в надії, що всесвіт вам пробачить. Виконуйте вимірювані кроки:

Доведіть тегування за допомогою tcpdump на uplink.
Доведіть дозвіл за допомогою bridge vlan show і списків allowed VLAN на комутаторі.
Доведіть L3 за допомогою ARP/neighbor і доступності шлюзу.
Стандартизуйте конфіги по вузлах, щоб міграція не перетворилась на рулетку.
Зробіть management явним (тегований підінтерфейс) і перестаньте покластись на native VLAN, якщо ви цього щиро не маєте на увазі.

Потім запишіть обрану модель (host tags vs guest tags), створіть шаблони портів комутатора і тримайте одного canary VM на кожному VLAN. Це не круто, але це працює. А в продакшні «працює» — це функція.