Сеть в Proxmox: мосты, VLAN и почему пропал доступ

MAATRIX

Вы правите сетевой мост на Proxmox-хосте через веб-интерфейс или прямо в /etc/network/interfaces, нажимаете «применить» — и связь обрывается. SSH не отвечает, веб-панель не грузится, а сервер стоит в другом городе или другой стране, и физически до него не добраться быстро. Это один из самых частых и самых нервных сценариев в администрировании виртуализации. Разберём, как устроены мосты и VLAN в Proxmox, почему именно так рвётся доступ и как настроить сеть так, чтобы этот сценарий вас не касался.

Мост vmbr: программный коммутатор внутри хоста

Сетевой мост в Proxmox (vmbr0, vmbr1 и так далее) — это программный аналог физического коммутатора. Он объединяет в одну логическую сеть физический интерфейс хоста (например, enp3s0 или eno1) и виртуальные интерфейсы (tap, veth) виртуальных машин и контейнеров. Пакет, пришедший на физический порт, мост доставляет всем участникам сегмента так же, как это делает обычный коммутатор — на канальном уровне, по MAC-адресам.

Типичная конфигурация в /etc/network/interfaces выглядит так:

auto enp3s0
iface enp3s0 inet manual

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

Ключевая деталь: сам управляющий IP-адрес хоста (тот, по которому вы заходите по SSH и в веб-интерфейс) в большинстве инсталляций Proxmox назначен именно на интерфейс vmbr0, а не на физический enp3s0. Физический интерфейс переведён в manual и просто отдаёт свой линк мосту. Это значит: если вы правите параметры vmbr0 — меняете bridge-ports, добавляете VLAN-теги, переносите физический порт на другой мост — вы правите тот самый интерфейс, через который прямо сейчас идёт ваша SSH-сессия.

Один физический сервер обычно держит несколько мостов: vmbr0 для управляющей сети и трафика ВМ, vmbr1 для отдельной сети хранения или бэкапов, иногда vmbr2 для внешнего провайдерского VLAN. О том, как выбрать конфигурацию хранилища под эти сценарии, есть отдельный разбор — хранилища в Proxmox.

VLAN: как разделить трафик на одном физическом порту

VLAN (Virtual LAN, IEEE 802.1Q) позволяет логически разделить трафик разных сетей на одном физическом канале — без прокладки отдельного кабеля под каждую сеть. Коммутатор (или в нашем случае программный мост) добавляет к Ethernet-кадру тег с номером VLAN (от 1 до 4094), и все устройства на пути следят за этим тегом, доставляя кадр только участникам той же VLAN.

В Proxmox есть два основных способа работать с VLAN на мосту:

1. VLAN-aware мост — один vmbr0 понимает теги напрямую, а нужный VLAN назначается на уровне сетевой карты виртуальной машины:

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

Дальше в настройках сетевого адаптера ВМ в веб-интерфейсе указывается VLAN Tag = 100 (например) — и эта ВМ окажется в VLAN 100, изолированная от ВМ с тегом 200, хотя обе физически висят на одном vmbr0.

2. Отдельный саб-интерфейс на VLAN — классический способ, когда сам хост должен получить IP именно в конкретной VLAN:

auto vmbr0.100
iface vmbr0.100 inet static
    address 10.10.100.5/24
    gateway 10.10.100.1

Здесь vmbr0.100 — виртуальный интерфейс, привязанный к VLAN 100 поверх моста vmbr0. Трафик с этого интерфейса уходит с тегом 100, и коммутатор на другом конце должен быть настроен принимать тегированный трафик на соответствующем порту (trunk-порт с разрешённым VLAN 100), иначе пакеты просто потеряются на границе.

Именно на стыке этих двух механизмов чаще всего и случаются проблемы: включили bridge-vlan-aware, но забыли добавить нужный VLAN в bridge-vids, или указали тег в настройках ВМ, а порт коммутатора на другой стороне пропускает только untagged-трафик.

Классический сценарий: как правка моста рвёт доступ к хосту

Вот типичный постмортем, который повторяется в разных вариациях практически у каждого, кто администрирует Proxmox дольше года.

Администратор решает добавить второй физический интерфейс в mode active-backup или перенести управляющий IP на VLAN — обычная, в общем-то, рутинная задача. Заходит по SSH, открывает /etc/network/interfaces или веб-интерфейс *Datacenter → Node → System → Network*, редактирует секцию vmbr0: меняет bridge-ports enp3s0 на bridge-ports enp3s0 enp4s0 для бондинга, или добавляет bridge-vlan-aware yes, или правит адрес на vmbr0.100. Нажимает «Apply Configuration» в GUI (это вызывает ifreload -a на сервере) — или, если правил файл руками, сам выполняет ifreload -a или systemctl restart networking.

И вот здесь наступает развилка. Если в новой конфигурации есть ошибка — опечатка в имени интерфейса (enp4s0 вместо реального eno2), неверный VLAN-тег, отсутствующий bridge-ports из-за случайно оставленной пустой строки, конфликт статического адреса — интерфейс управления может подняться неправильно или не подняться вовсе. А поскольку vmbr0 — это именно тот интерфейс, через который вы только что подключены по SSH, обрыв происходит мгновенно и без предупреждения. Текущая SSH-сессия виснет и рвётся, веб-интерфейс перестаёт отвечать. Сервер физически жив, ВМ на нём продолжают работать (если их сеть не завязана на тот же адрес), но сетевого пути до хоста больше нет.

Похожая механика — в истории с неудачным правилом firewall, где один неверный iptables-вызов также обрывает единственный канал доступа: ошиблись в правиле firewall и потеряли доступ. Разные причины — один и тот же результат: канал, через который вносилось изменение, оказывается первой жертвой этого изменения.

Почему откат «через тот же канал» уже невозможен

Логика ловушки простая, но именно из-за неё сценарий так неприятен: способ исправить ошибку — тот же самый, что и способ, которым вы её внесли, — SSH или веб-интерфейс через vmbr0. Но если vmbr0 только что упал, оба этих способа доступа больше не работают. Получается замкнутый круг: чтобы откатить конфигурацию, нужен сетевой доступ, а сетевого доступа нет именно из-за той конфигурации, которую нужно откатить.

Технически это усугубляется тем, как ifreload -a (Proxmox использует ifupdown2, который умеет применять изменения интерфейсов без полного перезапуска сети) обрабатывает применение: он последовательно приводит состояние интерфейсов в соответствие с файлом конфигурации, и если новое состояние vmbr0 не может поднять адрес (нет такого физического порта, конфликт VLAN, синтаксическая ошибка) — интерфейс просто остаётся недоступным до следующей правки. Никакого автоматического отката к предыдущему рабочему состоянию ifreload сам по себе не делает — он применяет то, что написано в файле, и на этом его работа заканчивается.

Восстановить доступ в такой ситуации можно только тем каналом, который не зависит от только что сломанного vmbr0: IPMI/iKVM, консоль хостинг-провайдера в панели управления, физический доступ с монитором и клавиатурой, либо заранее открытая параллельная сессия. Про сам механизм удалённого управления железом отдельно — IPMI и удалённое управление железом.

Меры предосторожности до того, как вы нажали «применить»

Три практики снимают почти весь риск этого сценария, и все три дешевле, чем разбираться с потерянным доступом постфактум.

1. Никогда не применяйте рискованные сетевые изменения без запасного пути. Перед правкой vmbr0 убедитесь, что у вас есть рабочий IPMI/KVM-over-IP (у многих выделенных серверов это входит в тариф или доступно по запросу), либо консоль хостинг-провайдера в панели, либо физический доступ. Если ничего из этого нет — держите открытой вторую, параллельную SSH-сессию на сервер до того, как начнёте правку в первой. Если после ifreload -a первая сессия обрывается, вторая (открытая до изменения, использующая уже установленное TCP-соединение) может продолжать работать ещё некоторое время и дать шанс откатить файл конфигурации. Это не железная гарантия — если сам интерфейс физически падает, оборвутся обе сессии, — но в доброй половине случаев, когда проблема в статическом IP или VLAN-теге, а не в исчезновении интерфейса, вторая сессия спасает.

2. Там, где есть отложенное применение с автоматическим откатом — используйте его. Идея «safe apply» встречается в разных инструментах управления сетью (в некоторых системах она называется commit-confirm или auto-rollback): новая конфигурация применяется, но откатывается автоматически по таймауту, если администратор не подтвердил её вручную из отдельной сессии. Сам Proxmox такого встроенного механизма для сетевых настроек по умолчанию не предоставляет — веб-интерфейс лишь разделяет «отложенные изменения» (Pending Changes, видны до нажатия Apply) от уже применённых, но после нажатия Apply отката по таймауту нет. Если вам нужна такая страховка, её несложно собрать самостоятельно: сохраните рабочую копию конфигурации (cp /etc/network/interfaces /etc/network/interfaces.bak), поставьте отложенную задачу на откат через at:

echo "cp /etc/network/interfaces.bak /etc/network/interfaces && ifreload -a" | at now + 5 minutes

и, если после применения новой конфигурации доступ сохранился и всё работает как задумано, просто отмените отложенную задачу (atq покажет её номер, atrm <номер> отменит). Если доступ пропал — через 5 минут сервер сам вернётся к рабочей конфигурации, и вам останется только заново подключиться.

3. Тестируйте на некритичном стенде, а не сразу на продакшене. Если конфигурация нетривиальная — бондинг интерфейсов, VLAN-aware мост с несколькими тегами, перенос управляющего IP между VLAN — сначала воспроизведите её на тестовой машине (тестовый Proxmox-узел, вложенная виртуализация, даже временный ВПС с похожей топологией сети) и убедитесь, что синтаксис и логика верны. Команда ifquery --syntax-check vmbr0 (или проверка через ifup --no-act в зависимости от версии ifupdown2) до перезагрузки сети покажет явные синтаксические ошибки, но не гарантирует, что новая топология реально применится на живом хосте так, как вы ожидаете. Разница между «продакшн» и «тест» в этом контексте не про мощность железа, а про цену ошибки: на тестовом сервере обрыв доступа — это перезагрузка через панель провайдера, на боевом — это простой сервисов и, возможно, часы разбирательств с датацентром.

Практический чек-лист перед правкой сети на боевом Proxmox

Перед тем как менять что-либо в vmbr0 на работающем хосте, полезно пройтись по короткому списку:

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

Если вы выбираете между Proxmox и более легковесной виртуализацией именно из-за подобных рисков конфигурации, стоит посмотреть на сравнение подходов: Proxmox или голый KVM — что выбрать.

Частые вопросы