Как правильно настроить сетевой мост (bridge) для KVM в SolusVM — пошаговое руководство

В мире виртуализации KVM (Kernel-based Virtual Machine) давно зарекомендовал себя как один из самых производительных и надёжных гипервизоров с открытым исходным кодом. Однако даже самый мощный KVM-сервер не сможет выполнять свои функции в полной мере, если не настроить корректное сетевое взаимодействие между физическим хостом и виртуальными машинами. Именно здесь на сцену выходит сетевой мост (network bridge) — ключевой элемент, который обеспечивает полноценный выход VPS в интернет и обратную связь.

Без bridge ваши виртуальные серверы будут “заперты” в изолированном контуре, недоступном для внешнего мира. Они не смогут получать внешние IP-адреса, а значит — не будут видны клиентам, не смогут обновляться, не будут отвечать на ping и HTTP-запросы. В этой статье мы шаг за шагом разберём, как правильно настроить bridge в панели SolusVM, какие подводные камни вас ждут и как избежать ошибок, которые чаще всего совершают новички. Эта инструкция — must-read для хостинг-провайдеров, системных администраторов и DevOps-инженеров, работающих с KVM-инфраструктурой.

Установка и первоначальная настройка SolusVM: отправная точка

Перед тем как углубляться в настройку сетей, убедитесь, что панель управления SolusVM успешно установлена. Для этого вам понадобятся две машины:

• SolusVM Master — сервер, на котором размещается веб-интерфейс панели управления.
• KVM Slave — физический сервер с KVM, на котором будут размещаться виртуальные машины (VPS).

Официальная документация SolusVM подробно описывает процесс установки, но напомним ключевые моменты:

1. Устанавливайте SolusVM Master на отдельный сервер с CentOS 7 или AlmaLinux 8 (предпочтительно).
2. KVM Slave также должен работать на совместимой ОС (чаще всего CentOS 7/8 или Rocky Linux).
3. После установки Slave-ноды добавьте её в панель через веб-интерфейс Master'а.

Важно: не пропускайте этап базовой настройки сети на Slave-ноде, так как именно здесь вы будете создавать bridge-интерфейсы. Если вы пропустите этот шаг и попытаетесь создавать VPS без bridge — они просто не получат доступ к интернету.

Подготовка выделенной подсети: как правильно распределить IP-адреса

Предположим, вы получили от вашего дата-центра или хостинг-провайдера дополнительную подсеть, например /27. Это стандартная практика: провайдеры выдают блоки IP-адресов для размещения VPS.

Подсеть /27 содержит 32 IP-адреса, из которых:

• 1 — сетевой адрес (недоступен для использования),
• 1 — широковещательный адрес,
• 1 — должен быть выделен под gateway (шлюз), то есть под IP-адрес моста,
• оставшиеся 29 адресов — для раздачи VPS-клиентам.

Пример: если вам выдали подсеть 192.168.100.0/27, то диапазон IP-адресов будет:

• Сетевой адрес: 192.168.100.0
• Первый доступный: 192.168.100.1
• Последний доступный: 192.168.100.30
• Широковещательный: 192.168.100.31

В этом случае вы обязательно должны выделить один IP (например, 192.168.100.1) под bridge-интерфейс — это будет шлюзом для всех VPS в этой подсети. Это требование не является рекомендацией — это архитектурная необходимость маршрутизации в Linux-сетях.

Создание основного bridge-интерфейса: конфигурация br0

Теперь перейдём к практической части. На KVM-ноде (то есть на Slave-сервере) необходимо создать конфигурационный файл для моста. В системах на базе RHEL (CentOS, AlmaLinux и т.п.) конфигурации сетевых интерфейсов хранятся в каталоге /etc/sysconfig/network-scripts/.

Создайте файл /etc/sysconfig/network-scripts/ifcfg-br0:

DEVICE=br0
ONBOOT=yes
TYPE=Bridge
BOOTPROTO=none
IPADDR=192.168.100.1
NETMASK=255.255.255.224
STP=off
DELAY=0

Разберём параметры:

• DEVICE=br0 — имя моста.
• ONBOOT=yes — интерфейс будет активен при загрузке системы.
• TYPE=Bridge — указывает, что это не обычный интерфейс, а мост.
• BOOTPROTO=none — статическая настройка, без DHCP.
• IPADDR — IP-адрес моста, он же шлюз для VPS.
• NETMASK — маска подсети (для /27 — 255.255.255.224).
• STP=off — отключаем Spanning Tree Protocol (не нужен в большинстве VPS-сценариев).
• DELAY=0 — ускоряет поднятие интерфейса.

После сохранения этого файла вы ещё не завершили настройку — нужно привязать физический интерфейс к мосту.

Привязка физического интерфейса к мосту: правильная настройка eth0 (или enpXsY)

Физический сетевой интерфейс (обычно называется eth0, но в современных системах может быть enp3s0, ens192 и т.д.) больше не должен иметь IP-адреса. Весь стек передаётся мосту.

Отредактируйте файл /etc/sysconfig/network-scripts/ifcfg-eth0 (замените имя на актуальное для вашей системы):

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=none
BRIDGE=br0

Обратите внимание: здесь нет IPADDR и NETMASK — это критически важно. Если вы оставите IP на физическом интерфейсе, мост работать не будет корректно. Это одна из самых частых ошибок!

После внесения изменений перезапустите сеть:

systemctl restart network

Или, если используется NetworkManager:

nmcli connection reload
nmcli connection down eth0 && nmcli connection up eth0

Проверьте, что мост поднялся:

ip a show br0
brctl show

Настройка VPS в панели SolusVM: как указать bridge при создании машины

Теперь, когда bridge настроен на ноде, можно создавать виртуальные машины в веб-интерфейсе SolusVM.

При создании VPS укажите следующие параметры:

• Network Type: routed (рекомендуется для bridge-модели).
• Bridge: br0 — именно то имя, которое вы задали в конфигурационном файле.
• Gateway: 192.168.100.1 — IP-адрес вашего моста.
• Netmask: 255.255.255.224.
• IP Address: любой свободный IP из подсети (например, 192.168.100.2).

После создания VPS убедитесь, что в её ОС правильно настроен сетевой интерфейс. Например, в CentOS 7:

DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.100.2
NETMASK=255.255.255.224
GATEWAY=192.168.100.1

Перезапустите сеть внутри VPS и проверьте подключение:

ping 8.8.8.8

Второй bridge для выделенных внешних IP: когда один мост — недостаточно

Часто у провайдеров есть сценарии, когда клиенту выдаётся единичный внешний IP, не входящий в подсеть. Например, у вас есть основной IP-адрес сервера 203.0.113.10, и дополнительно вы купили 5 одиночных IP: 198.51.100.1, 198.51.100.2 и т.д.

Для таких IP-адресов нельзя использовать тот же bridge, что и для подсети. Нужно создать отдельный мост, например br1.

Конфигурация /etc/sysconfig/network-scripts/ifcfg-br1:

DEVICE=br1
TYPE=Bridge
BOOTPROTO=static
IPADDR=203.0.113.10
NETMASK=255.255.255.255
ONBOOT=yes
STP=off
DELAY=0

Обратите внимание: маска /32 (255.255.255.255), так как это один IP-адрес. Также важно, чтобы физический интерфейс был привязан к br0, а не к br1. В этом случае br1 используется только как “виртуальный шлюз” — физическая привязка не требуется. Такая схема называется NAT-less routed networking или MAC-based routing, и поддерживается большинством дата-центров.

Для VPS, использующих такие IP, в SolusVM укажите:

• Bridge: br1
• Gateway: 203.0.113.10
• Netmask: 255.255.255.255

Внутри VPS также нужно настроить статический IP и шлюз, но без маршрута по умолчанию — вместо этого добавляется маршрут на шлюз через ARP.

Популярные схемы настройки bridge в KVM: сравнение и применение

В зависимости от бизнес-требований и инфраструктуры дата-центра вы можете использовать разные схемы. Вот три наиболее распространённые:

Сценарий 1: VPS на общей выделенной подсети
Bridge: br0
Gateway: IP моста (например, 192.168.100.1)
Маска: /27
Комментарий: Идеально подходит для массового хостинга VPS. Все машины находятся в одной подсети, легко масштабируются и управляются.

Сценарий 2: VPS с индивидуальными внешними IP
Bridge: br1
Gateway: основной IP сервера (например, 203.0.113.10)
Маска: /32
Комментарий: Используется, когда клиенту выдаётся один внешний IP. Требует поддержки со стороны дата-центра (обычно через proxy ARP или MAC-биндинг).

Сценарий 3: Изолированная внутренняя сеть
Bridge: br-int
Gateway: не требуется
Маска: /24
Комментарий: Применяется для тестовых сред, баз данных, внутренних сервисов. Такие VPS не имеют выхода в интернет, общаются только между собой.

Выбор схемы зависит от того, какие IP-адреса вы получили и какую архитектуру предпочитает ваш хостинг-провайдер. Уточняйте у поддержки дата-центра, поддерживают ли они routed-модель с bridge.

Заключение: стабильность сети начинается с правильного bridge

Настройка сетевого моста — это не просто техническая формальность, а фундамент всей KVM-инфраструктуры. Один неверно указанный параметр в конфигурации ifcfg-br0 может привести к полной недоступности сотен VPS. Именно поэтому подход к настройке bridge должен быть максимально вдумчивым и проверенным.

Напомним ключевые правила:

• Всегда выделяйте отдельный IP из подсети под gateway (мост).
• Никогда не оставляйте IP-адрес на физическом интерфейсе при использовании bridge.
• Для одиночных IP создавайте отдельный bridge с маской /32.
• Проверяйте конфигурацию после каждого обновления ОС или перезагрузки сервера.

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

Теперь вы готовы не просто развернуть KVM-ноду, но и обеспечить её стабильной, надёжной и масштабируемой сетевой архитектурой. Удачи в администрировании!