Настройка bridge-интерфейсов для виртуализации KVM и LXC

Настройка bridge Linux: где рвётся сеть виртуалок

Типовой сбой при настройке bridge Linux выглядит буднично: виртуальная машина стартует, внутри гостя интерфейс поднят и адрес получен, а снаружи её не видно. Причина почти всегда в мосте — физический порт остался на старом адресе, bridge-интерфейс поднялся позже гостя или в него добавлен не тот порт.

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

Виртуализация KVM LXC чувствительна к этому сильнее прочих схем: у гостя нет собственного физического порта, весь его трафик идёт через мост, и ошибка в нём видна сразу у всех виртуальных машин на узле. Расхождение MTU, лишний протокол защиты от петель, порт, оставшийся в другом режиме, — каждая мелочь даёт потерю связности без внятной записи в логах.

Мы проходим такие конфигурации на уровне KVM и LXC — от сборки моста до момента, когда гость получает первый пакет. Мост проверяется прогоном трафика в обе стороны и перезагрузкой узла, а не «включилось — значит работает». Ниже разбираем, как это закрывается.

Что даёт управляемый мост в контуре виртуализации

Мост в контуре виртуализации — это не разовая команда, а описанное в конфигурации состояние узла. В Linux он поднимается вместе с сетевым стеком: адрес, тег сегмента, размер кадра и параметры очередей берутся из файла конфигурации, а не из ручных правок после перезагрузки.

Отсюда первое измеримое следствие — устойчивость к перезагрузке узла. Гипервизор стартует, мост получает адрес, гостевые интерфейсы подключаются, и виртуальные машины с контейнерами возвращаются в сеть без дежурства администратора. Время от включения до приёма внешнего трафика задаёт порядок юнитов, а не то, кто в этот момент на смене.

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

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

Практическая ценность — минимум ручных действий: конфигурация версионируется, изменения проверяются на стенде, откат сводится к возврату прежнего файла. Узкое место перестаёт зависеть от памяти конкретного инженера и становится частью инфраструктуры как кода.

Режимы сети для виртуалок: macvtap, NAT и мосты

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

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

Этапы работ: от аудита топологии до передачи контура

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

1. Аудит сети и инвентаризация интерфейсов. Собираем реальную картину: физические порты, агрегированные каналы, разметка VLAN, существующие мосты и адреса на них. Отдельно ищем гостей, подключённых напрямую к интерфейсу хоста в обход моста — именно они отваливаются первыми при любой перестройке.
2. Схема подключения. До правок согласуем топологию: какие мосты создаём, что в них включаем, где шлюз, как адресация делится между хостом и машинами, какие сети разводим по VLAN и какие порты остаются служебными.
3. Настройка интерфейсов. Параметры переносим в постоянные файлы конфигурации, а не оставляем командами в сессии — иначе сеть не переживёт перезагрузку. Мост настраиваем с поддержкой тегированного трафика там, где это нужно, и без лишних надстроек, которые не используются в топологии.
4. Изоляция трафика. Разделяем гостей разных назначений на уровне моста, чтобы одна машина не видела чужой сегмент. Проверяем, что политика не блокирует служебный обмен с системой управления.
5. Проверка связности. Прогоняем адресацию, шлюз, внешние направления, обмен между гостями на одном хосте и между хостами. Отдельно смотрим поведение после перезагрузки и после отключения одного канала из агрегации.
6. Передача контура. Отдаём схему, конфигурации под контролем версий с комментариями, порядок отката к прежней топологии и список точек, где изменение затронет другие сервисы.

Что остаётся заказчику: конфигурации, схемы, регламенты

Bridge-интерфейсы не живут в вакууме: за ними разметка VLAN, фильтры трафика и привязка виртуальных машин и контейнеров к сегментам. Поэтому результат мы отдаём не как «хост, где всё работает», а как набор артефактов, по которым ваша команда сможет сопровождать сеть и подключать новые сегменты без нас.

• Файлы конфигурации — рабочие конфиги бриджей, VLAN и маршрутов с комментариями: назначение интерфейса, какой сегмент обслуживает, почему выбран такой режим.
• Схема сети — логическая топология с адресацией, точками выхода и привязкой виртуальных машин и контейнеров к бриджам.
• Правила доступа — где сегменты изолированы, где обмен разрешён, как выдаются адреса и как закрыт доступ к управляющим интерфейсам.
• Регламент изменений — порядок правок: согласование, окно работ, проверка после применения, кто и что фиксирует в истории.
• Порядок отката — пошаговый возврат к предыдущему состоянию: где лежат резервные копии конфигов, как переключиться и что проверить после.
• Документация — карта интерфейсов и зависимостей, известные ограничения и типовые сбои с описанием реакции на них.
• Перечень приёмочных проверок — связность, изоляция сегментов, поведение после перезагрузки гипервизора и контейнеров.

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

Кейс: перевод контура виртуализации на мост без простоя

Контур виртуализации заказчика — четырнадцать узлов под KVM и LXC — держался на отдельных физических интерфейсах: каждый хост выходил в сеть своим портом, маршрутизацию правили руками. Отказ одного порта уносил связность у целой группы машин, и вывод из этого состояния занимал от восьми до пятнадцати минут: поднять линк, сверить таблицы, перезапустить гостей, потерявших сетевые накопители. За квартал набралось одиннадцать таких эпизодов, семь из них — в нерабочие часы, с вызовом инженера.

Что сделали

Физические адаптеры объединили в агрегированный канал, поверх него — мост, к которому подключены гостевые машины. Топологию описали декларативно и версионировали: все узлы получили одинаковую конфигурацию, а расхождения между ними стало видно до применения. На Proxmox VE это укладывается в штатные средства платформы, без сторонних надстроек.

Миграцию провели без простоя: переводили по одному узлу, гостей уносили живой миграцией в окна низкой нагрузки, обратный откат держали готовым до подтверждения связности на новом мосту.

Результат в цифрах

Было: ручная маршрутизация на каждом узле, одиннадцать отказов связности за квартал, время восстановления восемь–пятнадцать минут, вмешательство инженера обязательно.

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

Чем bridge отличается от NAT и macvtap на практике

Короткий ответ: bridge отдаёт виртуалке собственный адрес в том же сегменте, что и хост, NAT оставляет её за трансляцией адресов, а macvtap даёт прямой адрес, но разрывает обмен между хостом и гостем. Поэтому режим выбирают не по вкусу, а по тому, кто должен видеть виртуалку — соседний сервер, внешний балансировщик или только сам хост.

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

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

Технические сомнения перед внедрением мостов

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

Какой будет простой при переключении?

Разрыв приходится на перестройку таблицы адресов: доли секунды при локальной правке и до нескольких секунд при смене аплинка. Поэтому изменения идут в согласованное окно, а резервный путь строится на агрегации портов с автоматическим переключением.

Как откатывается неудачная конфигурация?

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

Как разделить трафик по сегментам?

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

Можно ли включить в мост несколько физических интерфейсов?

Да, их объединяют в агрегированный канал и в мост включают уже его — получается отказоустойчивый аплинк с одной точкой настройки. Режим на коммутаторе должен совпадать с режимом на хосте, иначе канал поднимется частично.

Обсудим вашу топологию и вернёмся с планом работ

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

• Схема сети: какие интерфейсы физические, где агрегация каналов, какие подсети и VLAN должны быть видны гостям.
• Перечень узлов: сколько хостов виртуализации, виртуальных машин и контейнеров, как они сгруппированы по назначению.
• Требования к изоляции: какие группы машин и контейнеров не должны видеть друг друга и какой трафик между ними разрешён.
• Адресация и имена: кто выдаёт адреса, нужна ли фиксированная привязка по MAC, как устроено разрешение имён внутри сети.
• Текущие настройки: как настроены bridge сейчас, что уже пробовали и к какому результату это привело.
• Окно изменений: когда допустим короткий перерыв в работе сервисов, есть ли резервный канал управления узлами.
• Точка отката: сохранились ли исходные конфигурации и есть ли доступ к консоли, если сеть на узле перестанет подниматься.

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