VM у Proxmox без інтернету: помилки містка vmbr0 і швидкі виправлення

Швидкий план діагностики

Якщо ви на чергуванні, вам не потрібна лекція про мережі. Вам потрібен порядок триажу, що швидко знаходить вузьке місце. Ось шлях, який я використовую: гість → місток → аплінк → шлюз → DNS. Не гадати. Вимірювати.

Перший крок: підтвердити домен відмови (тільки гість, тільки хост або апстрім)

• З хоста: чи може він дістатися до шлюзу та інтернету? Якщо так — апстрім імовірно в порядку.
• З VM: чи може вона дістатися свого шлюзу за замовчуванням? Якщо ні — проблема всередині гостя, vNIC, містка, VLAN-тегування або файрволу між гостем і шлюзом.
• З VM: чи може вона дістатися IP в інтернеті (наприклад, відомого резолвера), але не DNS-імен? Якщо так — це DNS або його перехоплення.

Другий крок: перевірте, чи vmbr0 передає правильні кадри

• Чи має vmbr0 правильну IP-конфігурацію (якщо це L3-інтерфейс хоста) і чи правильні порти (фізичний NIC або bond як порт мосту)?
• Чи VLAN-и тегуються там, де ви думаєте? VLAN-aware мости Proxmox не виправлять помилки транкування автоматично.
• Чи ввімкнено Proxmox Firewall на рівні Datacenter / Node / VM з дефолтним DROP, про який ви забули?

Третій крок: перевірте поведінку шлюзу і MTU

• Перевірте ARP і таблиці сусідів: якщо ARP не працює, ви навіть не на рівні L2.
• Перевірте невідповідності MTU: класично, коли хост працює (менші пакети), а трафік гостя зависає (Path MTU Discovery заблокований).
• Перевірте offloads і налаштування bridge netfilter: вони можуть давати симптоми «пінгує, але TCP мертвий».

Перестаньте робити це: випадково перезапускати мережу в надії, що вона «перевчиться». Мости не вчаться; вони переспрямовують. Ваша проблема детермінована, навіть якщо вона дратує.

Як vmbr0 насправді працює (і чому він ламається)

vmbr0 на Proxmox зазвичай — це Linux bridge. Думайте про нього як про віртуальний свіч, що живе в ядрі. Ваші VM підключаються до нього через tap-інтерфейси (наприклад, tap100i0), і місток пересилає кадри між тими tap’ами та фізичним аплінком (наприклад, eno1) або bond’ом (bond0).

Місток — це рівень 2. Маршрутизація — рівень 3. Проблеми мережі Proxmox виникають, коли ці межі розмиваються. Місток може переносити VLAN-тегований трафік, але він не «маршрутує VLAN-и». Якщо ваша VM знаходиться у VLAN 30, а порт верхнього комутатора не є транком VLAN 30, ваша VM не «неправильно налаштована». Вона ізольована за задумом.

Типові схеми мостів Proxmox

• Просте місткове підключення: vmbr0 з bridge-ports eno1. IP хоста знаходиться на vmbr0. VM розділяють той самий L2-домен.
• VLAN-aware місток: vmbr0 з bridge-vlan-aware yes, і кожен NIC VM вказує VLAN-тег.
• Маршрутна або NAT-мережа: окремий місток (наприклад, vmbr1) внутрішній; хост робить NAT через vmbr0. Добре для лабораторій, не мій перший вибір для продакшену, якщо ви не хочете навмисної ізоляції.
• Bonded аплінк: bond0 — порт vmbr0. Неправильна конфігурація bonding mode проти налаштувань комутатора — класичний генератор відмов.

Режими відмов зазвичай нудні

Коли VM не має інтернету, проблема зазвичай одна з цих:

• Неправильний шлюз за замовчуванням (гіст) або неправильний маршрут за замовчуванням (хост), якщо ви робите NAT/маршрутизацію.
• Несумісність VLAN (тег VM vs місток vs транк на комутаторі).
• Правило файрволу, що відкидає трафік пересилання.
• Місток підключений до неправильної фізичної NIC (так, таке буває).
• MAC-фільтрація / портова безпека вище відкидає кілька MAC-адрес на одному порту.
• MTU mismatch або заблокований PMTUD.
• nftables/iptables або bridge-nf-call-iptables, що творять несподівану фільтрацію.

Жарт №1: Linux-місток — як маркерна дошка в конференц-залі — всі вважають, що вона правильна, поки не прочитають, що на ній написано.

Цікаві факти та історичний контекст (корисне, не тривіальне)

1. Linux-бріджинг у ядрі вже десятиліттями, і ранні дизайни припускали «просте L2-перенаправлення». Сучасні налаштування нашаровують VLAN-и, гачки файрволу та offloads зверху.
2. Мережі Proxmox наслідують Debian-конвенції: те, що ви налаштовуєте в /etc/network/interfaces, досі є джерелом істини для багатьох розгортань, навіть з новішими інструментами.
3. VLAN-теги — це не «метадані», вони — частина Ethernet-кадру. Якщо порт комутатора в режимі access-only, теговані кадри зазвичай відкидаються без церемоній.
4. Режими bonding’у не взаємозамінні. 802.3ad (LACP) вимагає відповідної конфігурації на комутаторі; active-backup — ні. Змішування може виглядати як «хитаючийся інтернет», а не як чиста відмова.
5. За замовчуванням STP мосту має значення. Увімкнення STP може запобігти петлям, але також вводить затримку форвардування, яка виглядає як випадкові DHCP-збої після зміни лінку.
6. «Хост має інтернет» доводить менше, ніж ви думаєте. Хост може бути прокинутим іншим маршрутом (інший VLAN, інший інтерфейс, інша політика файрволу), ніж гості.
7. Портова безпека поширена в корпоративних мережах. Комутатори можуть обмежувати кількість MAC, які навчаються на порту. Віртуалізація порушує це припущення за задумом.
8. MTU mismatch витримує ICMP, але вбиває TCP, коли PMTUD заблоковано. Люди трактують це як «DNS зламався», бо веб-запити зависають.
9. Гачки bridge netfilter були контроверсійними, бо розмивають межі L2/L3. Вони потужні, але роблять потік пакетів неочевидним, якщо не знати, де ці гачки.

Практичні завдання: команди, що означає вивід і яке рішення

Це реальні завдання, які можна виконати на вузлі Proxmox. Кожне дає сигнал. Хитрість — трактувати виводи як точки прийняття рішення, а не як «інформацію».

Завдання 1: Перевірити маршрути хоста (довести, що хост має адекватний маршрут за замовчуванням)

cr0x@server:~$ ip route
default via 192.0.2.1 dev vmbr0 proto static
192.0.2.0/24 dev vmbr0 proto kernel scope link src 192.0.2.10

Що це означає: маршрут за замовчуванням хоста через vmbr0 до 192.0.2.1. Якщо маршрут за замовчуванням вказує в інше місце (неправильний інтерфейс, відсутній), ваш хост може все ще мати певну підключеність через політику маршрутизації, але ваш «нормальний» шлях зламаний.

Рішення: якщо маршрут за замовчуванням відсутній або неправильний, спочатку виправте мережу хоста. Не чіпайте VM поки що.

Завдання 2: Перевірити членство мосту (чи аплінк справді в vmbr0?)

cr0x@server:~$ bridge link
2: eno1 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0
5: tap100i0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0

Що це означає: eno1 підпорядкований vmbr0. Якщо ви не бачите свою фізичну NIC/bond з master vmbr0, ваші VM підключені до нікуди.

Рішення: якщо аплінк не є портом мосту, виправте /etc/network/interfaces (або конфіг мережі вузла) і акуратно перезавантажте мережу.

Завдання 3: Підтвердити конфіг vmbr0 і VLAN-aware

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

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

Що це означає: IP знаходиться на vmbr0, а не на eno1. VLAN-aware увімкнено, що дозволяє проходити тегованому трафіку.

Рішення: якщо VLAN-aware вимкнено, але ви тегуєте NIC VM, або вмикайте його, або видаляйте теги і використовуйте access VLAN на комутаторі. Виберіть одне. Змішування намірів створює відмови.

Завдання 4: Підтвердити, що NIC VM приєднаний до vmbr0 і має VLAN-тег (вид з Proxmox)

cr0x@server:~$ qm config 100 | sed -n 's/^net0:/net0:/p'
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,tag=30,firewall=1

Що це означає: VM 100 використовує vmbr0, VLAN-тег 30, і для цього NIC увімкнено Proxmox firewall.

Рішення: якщо місток неправильний, виправте його тут. Якщо firewall=1, розгляньте політику файрволу як першу підозру.

Завдання 5: Підтвердити, що гість бачить лінк і має IP (всередині гостя)

cr0x@server:~$ qm guest exec 100 -- ip -br addr
1: lo               UNKNOWN        127.0.0.1/8 ::1/128
2: ens18            UP             192.0.2.50/24 fe80::dcad:beff:feef:1000/64

Що це означає: інтерфейс ens18 UP з IPv4 192.0.2.50/24.

Рішення: якщо IP відсутній, перестаньте звинувачувати vmbr0 і виправте DHCP/static конфіг в гості (або cloud-init).

Завдання 6: Перевірити маршрут за замовчуванням гостя (найпоширеніша причина «немає інтернету»)

cr0x@server:~$ qm guest exec 100 -- ip route
default via 192.0.2.1 dev ens18
192.0.2.0/24 dev ens18 proto kernel scope link src 192.0.2.50

Що це означає: маршрут за замовчуванням вказує на 192.0.2.1.

Рішення: якщо шлюз за замовчуванням неправильний (або відсутній), виправте мережеву конфігурацію гостя або DHCP-діапазон. Не чіпайте місток поки що.

Завдання 7: Швидка перевірка доступності: ARP → пінг шлюз → пінг зовнішній IP → DNS

cr0x@server:~$ qm guest exec 100 -- bash -lc 'ip neigh; ping -c2 -W1 192.0.2.1; ping -c2 -W1 1.1.1.1; getent hosts example.com'
192.0.2.1 dev ens18 lladdr aa:bb:cc:dd:ee:ff REACHABLE
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.421 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.389 ms

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=3.12 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=3.08 ms

93.184.216.34  example.com

Що це означає: VM має L2-resolve, L3 до шлюзу, L3 до інтернету і робоче DNS-резолювання.

Рішення: якщо будь-який крок падає — тепер ви знаєте, який рівень досліджувати. Не пропускайте кроки, бо «DNS не працює» часто означає «немає маршруту».

Завдання 8: Перевірити ARP і базу пересилань на хості (хто чий MAC навчився)

cr0x@server:~$ ip neigh show dev vmbr0 | head
192.0.2.1 lladdr aa:bb:cc:dd:ee:ff REACHABLE
192.0.2.50 lladdr de:ad:be:ef:10:00 STALE

cr0x@server:~$ bridge fdb show br vmbr0 | head
aa:bb:cc:dd:ee:ff dev eno1 master vmbr0
de:ad:be:ef:10:00 dev tap100i0 master vmbr0

Що це означає: місток навчив MAC гостя на tap100i0 і MAC шлюзу на eno1. Якщо ви бачите MAC шлюзу на tap (або взагалі не бачите), у вас петля, неправильне підключення або несумісність VLAN.

Рішення: якщо FDB навчається неправильно, зосередьтесь на VLAN-тегуванні, портах мосту та конфігурації фізичного комутатора.

Завдання 9: Перевірити, чи Proxmox firewall увімкнено і відкидає пересилання

cr0x@server:~$ pve-firewall status
Status: enabled/running

cr0x@server:~$ nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "vmbr0" oifname "vmbr0" accept
  }
}

Що це означає: політика forward — DROP за замовчуванням (поширено), з конкретним дозволом для трафіку всередині мосту. Якщо ви робите NAT (vmbr1 → vmbr0), потрібні явні дозволи.

Рішення: якщо ruleset відкидає пересилання, або налаштуйте правила PVE firewall, або тимчасово вимкніть firewall, щоб підтвердити причину (потім знову увімкніть з правильною політикою).

Завдання 10: Перевірити sysctl для 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

Що це означає: кадри, що проходять через місток, передаються в хук iptables/nftables. Це може бути коректно, або випадково різати пакети, якщо ви думали «місток = свіч = без файрволу».

Рішення: якщо ви навмисно не фільтруєте містковий трафік, подумайте про відключення цих хукiв. Якщо фільтруєте — ретельно аудитуйте правила і задокументуйте це.

Завдання 11: Перевірити MTU end-to-end (VM, місток, аплінк)

cr0x@server:~$ ip -br link show vmbr0 eno1
vmbr0            UP             00:11:22:33:44:55 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
eno1             UP             00:11:22:33:44:55 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

cr0x@server:~$ qm guest exec 100 -- ip -br link show ens18
ens18            UP             de:ad:be:ef:10:00 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

Що це означає: MTU співпадає — 1500. Якщо MTU гостя 1500, а аплінк 9000 (або навпаки), ви отримаєте дивну часткову підключеність залежно від типу трафіка.

Рішення: оберіть одну стратегію MTU і застосуйте її послідовно: 1500 скрізь або jumbo frames скрізь, включно з upstream-портами. «Пів-джамбо» — чудовий спосіб витратити післяобід.

Завдання 12: Виявити «пінгує, але TCP вмирає» за допомогою DF-пінгу

cr0x@server:~$ qm guest exec 100 -- ping -c2 -M do -s 1472 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
1472 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=3.24 ms
1472 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=3.18 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Що це означає: Path MTU принаймні 1500 працює. Якщо отримаєте «Frag needed and DF set», у вас MTU mismatch або тунель у шляху.

Рішення: якщо DF-пінг падає — виправте MTU або дозволіть PMTUD (ICMP too-big) через файрволи. Не «виправляйте» це зниженням MSS наосліп, якщо тільки ви не контролюєте середовище і не задокументували хак.

Завдання 13: Перевірити симптоми обмеження MAC-адрес / портової безпеки (з погляду хоста)

cr0x@server:~$ journalctl -k --since "30 min ago" | egrep -i 'mac|flood|storm|blocked|bond|link' | tail -n 20
Dec 26 09:21:07 server kernel: vmbr0: port 2(eno1) entered blocking state
Dec 26 09:21:07 server kernel: vmbr0: port 2(eno1) entered forwarding state

Що це означає: журнали ядра не скажуть прямо «ваш комутатор застосував портову безпеку», але часті зміни стану порту або флапи лінку будуть видні.

Рішення: якщо підозрюєте портову безпеку — говоріть із мережевою командою. Ваш Proxmox-хост не є одиночним MAC-ендпоінтом; це фабрика MAC-адрес. Налаштуйте комутатор відповідно.

Завдання 14: Захоплення пакетів на vmbr0 і на tap (довести VLAN-теги і DHCP)

cr0x@server:~$ tcpdump -eni vmbr0 -c 10 '(arp or (udp port 67 or 68) or icmp)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vmbr0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
08:15:11.120001 de:ad:be:ef:10:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
08:15:11.220112 aa:bb:cc:dd:ee:ff > de:ad:be:ef:10:00, ethertype IPv4 (0x0800), length 342: 192.0.2.1.67 > 192.0.2.50.68: BOOTP/DHCP, Reply

Що це означає: ви бачите DHCP-запит і відповідь. Якщо DHCP-запити виходять із VM, але відповіді не повертаються, upstream VLAN, relay або файрвол налаштовано неправильно. Якщо ви бачите теговані кадри, коли очікували нетеговані (або навпаки), ви знайшли невідповідність.

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

Завдання 15: Перевірити NAT-конфіг (якщо ви побудували приватний vmbr1)

cr0x@server:~$ ip -br addr show vmbr1
vmbr1            UP             10.10.10.1/24

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

cr0x@server:~$ nft list ruleset | sed -n '1,200p' | egrep -n 'nat|masquerade|postrouting|forward' | head -n 20
42: table ip nat {
55:   chain postrouting {
58:     oifname "vmbr0" ip saddr 10.10.10.0/24 masquerade

Що це означає: vmbr1 існує, пересилання увімкнено, і є правило masquerade для виходу через vmbr0.

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

Завдання 16: Перевірити специфічні для Proxmox імена мережевих пристроїв та bonding

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
Active Aggregator Info:
        Aggregator ID: 1
        Number of ports: 2
Slave Interface: eno1
MII Status: up
Slave Interface: eno2
MII Status: up

Що це означає: bond — LACP і обидва слейви UP. Якщо bond показує «Number of ports: 1» несподівано або слейви флапають, ймовірно, конфігурація LACP на комутаторі не збігається з вашою.

Рішення: якщо режим bonding і конфіг на комутаторі не узгоджені, не «налаштовуйте на око». Узгодьте. Для продакшену або робіть правильний LACP з обох боків, або використовуйте active-backup для простоти.

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

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

1) Симптом: Хост має інтернет, VM не можуть дістатися шлюзу

Корінь: VM приєднана до неправильного містка, або місток не має фізичного аплінку, або невідповідність VLAN блокує L2 суміжність.

Виправлення: перевірте, що qm config NIC використовує bridge=vmbr0; перевірте bridge link показує фізичну NIC як master vmbr0; перевірте кінцево-до-кінця конфіг VLAN (тег VM, bridge VLAN-aware, switch trunk/access).

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

Корінь: відсутній маршрут за межі шлюзу (неправильний шлюз у гості), upstream ACL або помилкова NAT/маршрутизація, якщо VM у приватному мосту.

Виправлення: перевірте маршрут гостя; якщо дизайн з NAT — перевірте ip_forward і masquerade; підтвердьте, що upstream-шлюз повертає маршрут до підмережі VM (якщо вона маршрутується).

3) Симптом: VM може пінгувати 1.1.1.1, але DNS не працює

Корінь: DNS-сервери недоступні, неправильний resolv.conf, systemd-resolved вказує на stub, або корпоративне перехоплення DNS + правила файрволу.

Виправлення: перевірте getent hosts, подивіться /etc/resolv.conf в гості, переконайтесь, що UDP/TCP 53 дозволено, і що DHCP роздає правильні резолвери для цього VLAN.

4) Симптом: DHCP таймаутить у VM, статична IP працює

Корінь: транк VLAN, що не включає цей VLAN, затримка STP при підключенні лінку, проблема DHCP snooping/relay або файрвол блокує DHCP broadcast.

Виправлення: tcpdump на vmbr0 для DHCP; увімкніть bridge-fd 0, якщо вам не потрібен STP; координуйтеся з мережею щодо snooping/relay; переконайтеся, що файрвол гостя не блокує DHCP.

5) Симптом: Деякі VM працюють, інші — ні, на одному хості

Корінь: різні VLAN-теги для різних VM; різні налаштування файрволу; конфлікт MAC; дубльований IP; або одна VM на іншому містку.

Виправлення: порівняйте qm config між VM; перевірте дублікати IP за допомогою arping або таблиці neighbor; аудит файрвол налаштувань на рівні VM.

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

Корінь: MTU mismatch або блокований PMTUD; іноді проблеми з checksum offload на певних драйверах/прошивках NIC.

Виправлення: DF-пінг тест; узгодьте MTU; дозволіть ICMP too-big; якщо все ще дивно — спробуйте вимкнути GRO/LRO/TSO на хості як діагностику.

7) Симптом: З’єднання вмирає після увімкнення Proxmox Firewall

Корінь: політика forward = drop за замовчуванням, відсутні дозволи, або увімкнені bridge netfilter гачки з несподіваними правилами.

Виправлення: перегляньте nftables rules; налаштуйте PVE firewall правила; тримайте мінімум «allow established + allow vmbrX forwarding» і будуйте політику від цього базису.

8) Симптом: VM втрачають підключення, коли інший хост підключається або під час міграції

Корінь: upstream портова безпека обмежує кількість MAC, або комутатор не очікує кілька MAC за одним портом, або проблеми з хешуванням LACP при асиметричних потоках.

Виправлення: налаштуйте порт комутатора для віртуалізації (дозвольте кілька MAC, вимкніть строгу портову безпеку або підніміть ліміт), перевірте LACP з обох кінців, розгляньте active-backup, якщо мережева команда не підтримає LACP.

Три корпоративні міні-історії (анонімізовані, правдоподібні, технічно точні)

Міні-історія 1: Відмова через хибне припущення

Команда отримала у спадок невеликий кластер Proxmox з проєкту, що «ніколи не пішов у продакшен». Вони перемістили його в продакшн-стойку, підключили два 10GbE порти до пар топ-оф-рейк комутаторів і налаштували bond0 в 802.3ad, бо «це професійно». Комутатори мали порти, налаштовані як незалежні access-порти з однією стандартною VLAN. Ніхто з команди віртуалізації не попередив мережеву команду. Ніхто не сказав, бо всі вважали це очевидним.

Сам хост мав переривчасте підключення. VM — гірше: інколи вони могли резолвити DNS, але не завантажувати пакунки; іноді пінг шлюзу працював; іноді ARP здавався stale. Пахло, ніби в інтернеті проблеми у провайдера — зручна відмовка, бо це дозволяє припинити думати.

Поворотною точкою став пакетний захват на аплінку, який показав сплески ретрансляцій, а потім тишу, що корелювалося з LACP-повідомленнями, які ніколи не стабілізувалися. На хості /proc/net/bonding/bond0 показував «up» інтерфейс з одним активним слейвом, потім він змінювався. Неправильним припущенням було те, що LACP нешкідливий, якщо комутатор його не підтримує. Це не нешкідливо; це протокол переговорів, що очікує партнера.

Вони виправили це, тимчасово перемкнувши bond на active-backup, відновивши стабільність за хвилини, а потім запланували зміни з мережею для правильної LACP-конфігурації. Постінцидентий огляд був коротким і трохи болючим: система поводилась рівно так, як її налаштовано. Люди були непередбачуваною частиною.

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

Інженер, що дбав про продуктивність, помітив підвищене навантаження CPU на вузлах Proxmox у пікові години. Преривання мережі росли. Були також латентні стрибки на завантаженому API-VM. Він вирішив «оптимізувати мережу», увімкнувши jumbo frames на аплінку гіпервізора і vmbr0. Мережа зберігала jumbo для storage, тож це здавалось узгодженим.

Він змінив MTU на 9000 на vmbr0 і фізичних NIC. Хост виглядав нормально. VM почали відчувати дивну поведінку: ICMP пінги працювали, але TLS-рукопотискання зависали. Моніторинг показував сучасну інсталяцію часткових відмов. Інженер припустив, що MTU не може бути винним, бо «більші пакети зменшують накладні витрати». Це правда лише якщо весь шлях узгоджений.

Upstream-порти комутатора були ще на 1500. Гірше, мережевий файрвол на шляху відкидав ICMP fragmentation-needed. PMTUD не змогло виконати свою роботу, тому TCP-сесії зависали при спробі відправити більші сегменти. DNS виглядав нестабільним, бо клієнтські повтори відкладалися й помилково атрибутувалися.

Виправлення було не героїчним: повернули MTU до 1500 на vmbr0 і vNIC VM, потім запланували jumbo правильно з перевіркою end-to-end і узгодженням ICMP-політик. Урок старий: оптимізація без вимірювань — просто зміна. Іноді дорога.

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

Інша організація запускала Proxmox вузли в кількох сайтах, кожен з різними виробниками комутаторів і VLAN-розкладками. У них була проста політика: кожен Proxmox вузол повинен мати один «відомо добрий» мережевий management на нетегованому vmbr0, а мережі VM повинні бути теговані VLAN-ами на VLAN-aware мосту. Жодних винятків, жодних «тимчасових» access-портів.

Це звучить педантично. Воно також означало, що коли сайт повідомив «VM не мають інтернету», команда одразу перевірила транки й теги VLAN замість переписування мережевих конфігів. IP управління хоста залишався доступним, бо він не їхав поверх тієї ж тегованої плутанини, що мережі орендарів.

Під час заміни комутатора один транк-порт випадково налаштували як access VLAN 10 замість trunk. Симптом з’явився миттєво: всі VM на VLAN 30 на тому вузлі втратили зв’язок, але вузол управління залишився доступним. Захват пакетів показав, як теговані кадри виходять з vmbr0 і зникають у access-порті. Діагностика зайняла хвилини, а не години.

Нудна практика — відокремлення відповідальностей: стабільний management, явні VLAN-и для гостей і стандартний чеклист після змін мережі. Це не гламурно. Це спосіб уникнути викликів усієї команди через чиюсь помилку з шаблоном комутатора.

Жарт №2: Єдина річ більш наполеглива, ніж неправильно тегований VLAN — це запрошення на нараду про неправильно тегований VLAN.

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

Покроково: Виправити «VM немає інтернету», не погіршуючи ситуацію

1. Виберіть одну уражену VM і використовуйте її як канарку. Не міняйте налаштування на всіх гостях одночасно.
2. Усередині VM: перевірте IP, мережу, шлюз, DNS. Підтвердьте ip route і getent hosts.
3. З VM: пінгуйте шлюз, зовнішній IP, виконайте резолюцію DNS. Запишіть точно, що падає.
4. На хості: підтвердіть, що vmbr0 має аплінк-порт і правильні VLAN-настройки.
5. Перевірте стан файрволу: статус Proxmox firewall, прапор файрволу NIC VM, політика forward в nftables.
6. Підтвердьте L2 суміжність: таблиця neighbor хоста і bridge FDB записи для MAC VM і MAC шлюзу.
7. Запустіть таргетований захват: tcpdump на vmbr0 щоб побачити ARP/DHCP/ICMP потік; підтвердьте теги, якщо релевантно.
8. Перевірте MTU: узгодьте MTU; виконайте DF-пінг до інтернету.
9. Тільки потім міняйте конфіг, по одній вимірній зміні: VLAN, правило файрволу, маршрут, NAT, MTU.
10. Підтвердіть і задокументуйте кінцевий робочий стан: конфіг мосту, очікування для switchport, політика тегування VM.

Мінімальні «відомо хороші» шаблони vmbr0

Шаблон A: Просте нетеговане access-мережеве для хоста і VM (добре для малих лабораторій; обмежено для мультенантності):

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

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

Шаблон B: VLAN-aware місток з тегованими мережами VM (рекомендую для реальної мережі):

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

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

Шаблон C: Приватна мережа VM з NAT (використовуйте обережно, документуйте ретельно):

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

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

auto vmbr1
iface vmbr1 inet static
  address 10.10.10.1/24
  bridge-ports none
  bridge-stp off
  bridge-fd 0

Для Шаблону C вам все ще потрібні forwarding і NAT правила. Якщо ви не зможете пояснити їх наступному інженеру на чергуванні за хвилину — ви створюєте відмову, а не мережу.

Операційний чеклист після змін (той, який люди пропускають)

• Чи може хост дістатися шлюзу, резолвити DNS і завантажувати пакунки?
• Чи може VM на кожному VLAN дістатися свого шлюзу, зовнішнього IP і резолвити DNS?
• Чи ARP-записи стабільні (не постійно incomplete)?
• Чи DF-пінг на 1472 байти працює до зовнішнього IP?
• Чи політика Proxmox firewall задокументована (що дозволено, який дефолтний drop)?
• Чи конфіг switchport записано (access vs trunk, allowed VLANs, MAC limits, LACP)?

Цитата про надійність (перефразована думка)

Перефразована ідея, приписана W. Edwards Deming: «Ви не можете покращити те, що не вимірюєте.»

Питання й відповіді

1) Чому хост має інтернет, але VM — ні?

Тому що хост і VM можуть не ділити той самий мережевий шлях. Хост може бути нетегованим на vmbr0, а VM — теговані, або правила файрволу можуть по-іншому трактувати пересланий трафік, ніж локальний трафік хоста.

2) Де має бути IP хоста — на eno1 чи на vmbr0?

На vmbr0, у звичайному мостовому дизайні. Поставте eno1 в режим manual і зробіть його портом мосту. Призначення IP на eno1, коли ви одночасно бріджите його, — класична «якось працює, поки не перестане» ситуація.

3) Чи потрібен «bridge-vlan-aware yes», якщо я не використовую VLAN-теги?

Ні. Якщо все нетеговано і порт комутатора — access VLAN, тримайте простоту. Увімкніть VLAN-awareness тільки тоді, коли ви дійсно тегуєте NIC гостя або потребуєте транків.

4) У VM є IP, але немає виходу. Яка найшвидша одиночна перевірка?

Перевірте маршрут за замовчуванням у VM: ip route. Якщо шлюз за замовчуванням неправильний або відсутній — нічого іншого не має значення, поки це не виправлено.

5) Чи безпечно вмикати Proxmox Firewall?

Так, якщо ви розумієте його політики за замовчуванням і де він застосовується (Datacenter, Node, VM/NIC). Він небезпечний, коли хтось вмикає його з дефолтним DROP і без правил пересилання, а потім іде на вихідні.

6) Коли мені використовувати NAT для доступу VM до інтернету?

Коли ви навмисно хочете приватну, нерутовану мережу VM і ви приймаєте, що хост Proxmox стає маршрутизатором/фаєрволом. Для продакшену з багатьма VM зазвичай краще використовувати VLAN-и і належну маршрутизацію — це простіше для діагностики.

7) Чому я бачу DHCP-запити в tcpdump, але немає відповідей?

Зазвичай це проблеми транкування VLAN (неправильний дозволений VLAN), DHCP snooping/relay або файрвол, що блокує широкомовні UDP. Якщо запит виходить з VM і показаний на vmbr0 — сторона гостя в порядку.

8) Чи може MTU mismatch реально спричинити «немає інтернету»?

Так, обманним чином. Малий трафік (пінги, деякий DNS) може працювати, а TCP — зависати. Використовуйте DF-пінги і узгодьте MTU end-to-end, або дозвольте ICMP для PMTUD.

9) Чи варто вимикати offloads (GRO/LRO/TSO) на NIC?

Не за замовчуванням. Але як діагностика це може виявити дивну взаємодію драйвера/прошивки. Якщо вимкнення offloads «вирішує» проблему, вважайте це за підказку: оновіть прошивку/драйвери і перевірте фічі комутатора замість постійного обходу.

10) Який найчистіший спосіб працювати з кількома мережами на Proxmox?

Одна стабільна management-мережа (зазвичай нетегована), плюс VLAN-aware мости для мереж гостей з явними тегами на кожному NIC VM. Зберігайте документацію про конфіг trunk-портів і уніфікуйте налаштування між вузлами.

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

Коли VM Proxmox не мають інтернету, це майже ніколи не «містична віртуалізація». Це передбачувана невідповідність між тим, що VM відправляє, що vmbr0 пересилає і що приймає upstream-мережа. Найшвидший шлях до вирішення — перестати ставитись до цього як до магії і почати ставитись як до конвеєра.

Зробіть наступне:

• Стандартизуйте шаблон мосту: оберіть або лише нетеговані, або VLAN-aware із тегуванням. Не поєднуйте випадково обидва підходи.
• Запишіть очікування для комутатора: trunk/access, allowed VLANs, обмеження MAC, режим LACP. Якщо це не записано — це фольклор.
• Тримайте канарну VM з відомо доброю мережею і простим скриптом тестів (пінг шлюзу, пінг зовнішнього IP, DNS lookup, DF-ping).
• Аудитуйте позицію файрволу: знайте, де є дефолтний DROP, і забезпечте, що правила пересилання відповідають дизайну (містковий, маршрутизований або NAT).
• Зробіть MTU політикою, а не ручкою. 1500 скрізь — добре. Jumbo frames скрізь — добре. «Десь посередині» — місце для інцидентів.

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